Advances in Computers, Volume 49

Advances in COMPUTERS VOLUME 49 This Page Intentionally Left Blank Advances in COMPUTERS EDITED BY MARVIN V. ZEL...

70 downloads 1240 Views 20MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Advances

in COMPUTERS VOLUME 49

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 49

ACADEMIC PRESS A Harcourt Science and Technology Company

San Diego San Francisco New York London Sydney Tokyo

Boston

This book is printed on acid-free paper. Copyright 0 1999 by ACADEMIC PRESS All Rights Reserved. No part of this publication may be reproduced or transmitted in any form or by any means electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Academic Press A Hurcourt Science and Technology Cornpany 525 B Street, Suite 1900, San Diego, California 92101-4495, USA http://www.apnet.com Academic Press 24-28 Oval Road, London NWI 7DX, UK http://www.hbuk.co.uk/ap/ ISBN 0-12-012149-2 A catalogue for this book is available from the British Library

Typeset by Mathematical Composition Setters Ltd, Salisbury, UK Printed in Great Britain by Redwood Books, Trowbridge, Wiltshire 9 9 00 0 1 0 2 03 0 4 R B 9 8 7 6 5 4 3 2 1

Contents CONTRIBUTORS ........................................... PREFACE ................................................

ix

...

xi11

A Survey of Current Paradigms in Machine Translation

.

.

Bonnie J Dorr. Pamela W . Jordan and John W Benoit

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. The History of MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 . Translation Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 . Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . Paradigms of MT Research Systems . . . . . . . . . . . . . . . . . . . . . . . . 6. Evaluation of MT Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 5 14 20 40 54 56

Formality in Specification and Modeling: Developments in Software Engineering Practice

.

J. S Fitzgerald

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Modeling. Abstraction and Formality ....................... 3 . An Example of a Model-oriented Specification . . . . . . . . . . . . . . . 4 . Analysis Techniques for Formal Models . . . . . . . . . . . . . . . . . . . . . 5 . Lessons from Industrial Applications ....................... References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69 71 72 79 88 91

3-D Visualization of Software Structure Mathew L. Staples and James M. Bieman

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Software Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

96 98

vi

CONTENTS

3. Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Scalability of Software Visualization . . . . . . . . . . . . . . . . . . . . . . . 5 . Change Impact Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Evaluation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Conclusions and Future Work ............................. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107 114 119 128 138 140

Using Domain Models for System Testing

.

.

A von Mayrhauser and R Mraz

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. System Testing Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Industrial Application-Robot Tape Library . . . . . . . . . . . . . . . . . 4 . Building the Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . Test Generation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Sleuth Test Generation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Reuse Scenarios and Experiences . . . . . . . . . . . . . . . . . . . . . . . . . . 8 . Conclusions and Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

144 145 153 155 173 176 180 186 188

Exception-handling Design Patterns

.

William G Bail

1. 2. 3. 4. 5.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exception-handling Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exception-handling Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exception-handling Design Strategies . . . . . . . . . . . . . . . . . . . . . . . Ineffective Exception-handling Design Patterns . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Managing Control Asynchrony on SIMD Machines-a

.

191 193 195

197 221 237

Survey

.

Nael8 Abu-Ghazaleh and Phillp A Wilsey

1. 2. 3. 4.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Evolution of the SIMD Paradigm . . . . . . . . . . . . . . . . . . . . . . . Beyond the SIMD Control Organization. ....................

240 243 253 262

CONTENTS

5 . The Concurrent-interpretation Model . . . . . . . . . . . . . . . . . . . . . . . 6 . Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

278 293 295

A Taxonomy of Distributed Real-time Control Systems

.

J. R Agre. L. P. Clare and S. Sastry

1. Introduction ........................................... 2. Trends Affecting Control System Architectures . . . . . . . . . . . . . . . 3. Taxonomies for DRCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 . DRCS Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . Benefits and Limitations of a DRCS . . . . . . . . . . . . . . . . . . . . . . . . 6 . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AppendixA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

304 304 316 322 343 344 346 346 348

AUTHORINDEX ...........................................

353

SUBJECTINDEX ...........................................

365

OF VOLUMES IN THIS SERIES ........................ CONTENTS

375

This Page Intentionally Left Blank

Contributors Nael Abu-Ghazaleh is an Assistant Professor in the Computer Science Department at the State University of New York-Binghamton. He received his PhD and MS in computer engineering from the University of Cincinnati and his BSc in Electrical Engineering from the University of Jordan. His current research interests include parallel processing, computer architecture, networks, distributed algorithms, and parallel discrete event simulation. Jonathan Agre is a Senior Scientist at the Rockwell Science Center where he is doing research in the general areas of distributed systems and communications. He received his PhD in computer science from the University of Maryland in 1981. Since that time he has worked on distributed simulation, signal processing and distributed sensor networks. William Bail works for The MITRE Corporation in McLean VA as a computer scientist in the Software Engineering Center. His technical areas of focus include dependable software design and assessment, techniques for software specification development, design methodologies, metric definition and application, and verification and validation. Dr Bail is also an Adjunct Associate Professor of Computer Science at the University of Maryland University College where he develops instructional materials and teaches courses in software engineering. Dr Bail received a BS in mathematics from Camegie Institute of Technology, and an MS and PhD in computer science from the University of Maryland. John Benoit has been with the MITRE Corporation for the last 27 years where he is currently a Principal Scientist. He is also an Adjunct Professor at the George Washington University where he teaches courses in Natural Language Processing and Artificial Intelligence. He has a PhD in theoretical physics from Princeton, an MS in nuclear engineering from North Carolina State University, and a BS in electrical engineering from the University of Washington. His current research interests are in developing tools to produce machine translation systems using machine readable bilingual dictionaries and machine learning techniques. James M. Bieman is an Associate Professor in the Computer Science Department at Colorado State University. He is Chair of the Steering

ix

X

CONTRIBUTORS

Committee for the IEEE-CS International Symposium on Software Metrics, and was General Chair of the Metrics '97 and Metrics '93 Symposiums. Research results include methods to quantify software reuse, cohesion, and attributes of object-oriented software. He has conducted collaborative research projects with engineers at CTA, Hewlett-Packard, Lockheed Martin, Reliable Software Technologies, Storage Technology, and other companies. He is currently studying how to identify object-oriented design patterns in object models and source code, and the interface between design patterns and the measurement of software design structure.

Loren Clare is a Senior Scientist at the Rockwell Science Center. He obtained a PhD in system science (communication systems) from University of California Los Angeles in 1983. He is currently conducting research and development of wireless sensor networks. His research interests include communications network protocols, distributed control systems, and complex adaptive systems theory.

Bonnie Dorr graduated from Massachusetts Institute of Technology in 1990 with a PhD in computer science. She is an associate professor in the computer science department and Institute for Advanced Computer Studies at the University of Maryland. She is founder and co-director of the Computational Linguistics and Information Processing (CLIP) Laboratory. Her research focuses on large-scale interlingual machine translation (MT), i.e. automatic translation of diverse languages such as English, Spanish, Arabic, and Korean. She has developed a general framework for computerized translation of multiple languages. Recent research addresses the problem of automatic extraction of verb meanings from machine-readable resources for the construction of large-scale knowledge resources. Dr Doir received a NSF Presidential Faculty Fellowship (1996), Maryland's Distinguished Young Scientist Award (1996), the Alfred P. Sloan Research Award (1994), and a NSF Young Investigator Award (1993).

John Fitzgerald is a member of the Centre for Software Reliability, a research and technology transfer group in the University of Newcastle upon Tyne, England. His current work is aimed at developing enhanced formal modeling and analysis techniques, including test generation and proof, that may be applied in commercial practice, particularly in the aerospace industry. A research leader in the British Aerospace Dependable Computing Systems Centre, Dr Fitzgerald has co-authored two recent books: one on proof in VDM and a new introductory text stressing the development of modeling skills, utilizing tool support and examples inspired by industrial applications of formal methods. He holds the BSc and PhD in computing

CONTRIBUTORS

xi

from the University of Manchester, England. He is a member and former Programme co-Chair of Formal Methods Europe, a member of the ACM and of the IEEE Computer Society.

Pamela W. Jordan is a predoctoral graduate student in the Intelligent Systems Program at the University of Pittsburgh. She is currently completing her dissertation work on object descriptions and overloading of goals in natural language dialogue in a collaborative problem solving setting. Prior to this she completed her MS in Computational Linguistics at Carnegie Mellon University where she worked on the Caterpillar project in the Center for Machine Translation. Before returning to school full-time, Ms Jordan worked at the Mitre Corporation for five years in the Artificial Intelligence Technical Center where in the later years she concentrated on Natural Language Processing and Machine Translation research. During this time she completed here MS in computer science with an emphasis in natural language processing at George Mason University. She spent seven years at ESystems after completing here BS in computer science at the University of Virginia. Shivakumar Sastry is an Advisory Software Developer at Rockwell Software, Inc. He holds Master’s degrees in Electrical Engineering, and Computer Science. He obtained a Ph.D. in Computer Science from Case Western Reserve University. His research interests include algorithms, code generation, modeling, architectures for distributed control systems, and control systems programming. Mathew L. Staples is a Senior Software Engineer with Millivision, LLC where he develops image processing and user interface software for a variety of imaging systems. He received his BS in computer science from Syracuse University in 1993 and his MS in computer science from Colorado State University in 1996. His Master’s thesis described the use of 3-D graphics for the creation of scaleable, hierarchical visualizations of software entities. As part of his current work, he has made use of 3-D visualization for the simulation and study of radar data. Most recently he has been developing algorithms for combining multi-frame information from image sequences.

Anneliese von Mayrhauser is a Professor at Colorado State University. She is also Director of the Colorado Advanced Software Institute, a consortium of businesses and Colorado research universities that supports collaborative Technology Transfer Research projects. Dr von Mayrhauser is the author of a textbook and numerous articles in the area of software engineering, particularly software testing and maintenance. She received a PhD from Duke

xii

CONTRIBUTORS

University. She serves on several editorial boards including the IEEE Transactions on Reliability, the Empirical Software Engineering Journal and the Journal of Software Maintenance.

Richard Mraz is a Major in the US Airforce. He has been a faculty member at the US Airforce Academy in Colorado Springs. He holds a Ph.D. from Colorado State University. Philip A. Wilsey is an assistant professor at the University of Cincinnati. He received PhD and MS degrees in computer science from the University of Southwestern Louisiana and a BS degree in mathematics from Illinois State University. His current research interests are parallel and distributed processing, parallel discrete event driven simulation, computer-aided design, formal methods and design verification, and computer architecture.

Preface With this volume, we close out the 1990s. Without getting into the semantic discussion of whether the twenty-first century begins on 1 January 2000 or 1 January 2001, suffice it to say that the 1990s end with profound changes in the computing environment since the series began in 1960. Advances in Computers is the longest running anthology chronicling the changes in the computing environment since 1960. From large mainframe computers housed in “glass houses,” tended by professionals in white coats, we now see the computer as ubiquitous as pens and paper clips, littering every desktop in the industrialized, and not so industrialized, world. Terms like “cyberspace,” “surfing the net,” and “email” have entered our lexicon and the sight of a world wide web URL on advertising no longer surprises anyone. In this present volume we offer seven chapters describing several new developments in this rapidly changing landscape. The first chapter, “A survey of current paradigms in machine translation” by B. Dorr, P. Jordan, and J. Benoit, updates a theme that appeared in volume 1 of Advances. What is the current status of machine translation research in the US, Europe, and Japan? From the earliest days of computing, the calculations necessary for military applications and the desire to translate from one language to another have remained central themes for much computing research. Many advances have been made and this chapter summarizes 10 different approaches to the problem. Chapters 2 through 4 present various aspects on system verification and validation-showing that a system has the behavior that it was intended to have. The second chapter, “Formality in specification and modeling: developments in software engineering practice” by J. S. Fitzgerald, discusses formal verification in commercial software systems. Formal program verification, proving that a software product must meet its requirements, has always been extremely difficult to achieve, and when it can be achieved it is done so at an extremely high cost. This chapter discusses the problems and promises of using formal verification in a commercial environment. In Chapter 3, “3-D visualization of software structure,” M. Staples and J. Bieman describe a process for understanding the structure of a software product using visualization techniques. The concept is that maintenance of the product will be much easier if the relationships among the procedures making up the product can be viewed as a 3-D graph. One problem with this approach, however, is that as systems get larger, it is hard to visualize 500

xiii

xiv

PREFACE

to 1000 different procedures on one graph. This chapter describes how to address this scalability problem. Chapter 4, “Using domain models for system testing” by A. von Mayrhauser and R. Mraz, describes another approach toward developing correct systems. In this case, the authors develop an application domain based testing approach for generating test data in the domain of the software application. This provides a basis for more realistic test data generation than random testing since the data is relevant to the problem being solved. Chapter 5 , “Exception-handling design patterns” by W. Bail, explores the role of exception handling in program design. Most programming is sequential. That is, execution proceeds from one statement to the next. When an error condition occurs, a branch is made to an exception handler that addresses the problem before execution proceeds. This branch, however, can often be unpredictable. How one designs a program to best use such features is often omitted from educational programs. In this chapter Dr Bail addresses some rules that can be used to make sure such exception handling is done effectively and correctly. Chapter 6, “Managing control asynchrony on SIMD machines-a survey” by N. Abu-Ghazaleh and P. Wilsey, presents some new ideas on how machines can solve problems faster. Although machines are constantly being developed to run faster, 450 MHz being the top of the line as this is being written, most are still sequential in execution. One way to speed up this process is to have a single instruction operate on multiple data objects, i.e. the Single Instruction, Multiple Data or SIMD machine. This chapter presents a survey of such research projects. The final chapter in this volume, “A taxonomy of distributed real-time control systems” by J. Agre, L. Clare and S. Sastry, discusses the use of machines in industrial environments. The processor being embedded within a physical device rather than sitting on a desktop, with real-time requirements for quick response characterizes such environments. This is a quite different scenario from the word-processing PC on most desktops. This chapter discusses the developments that allow such real-time systems to be built. I hope that you find this volume of interest to you. If you would like to see any other topic discussed, or if you believe you can contribute a chapter of relevance to the computing community, please contact me at [email protected] or [email protected]. MARVINV. ZELKOWITZ College Park, Maryland

A Survey of Current Paradigms in Machine Translation BONNIE J. DORR Computer Science Department University of Maryland A. V. Williams Building College Park, Maryland 20742 USA bonnie@urniacs. umd.edu

PAMELA W. JORDAN Intelligent Systems Program University of Pittsburgh 907 Cathedral of Learning Pittsburgh, Pennsylvania 75260 USA [email protected]

JOHN W. BENOIT Mitre Corporation Artificial Intelligence Center 7525 Colshire Drive McLean, Virginia 22702 USA benoit@starbase. mitre.org

Abstract This paper is a survey of the current machine translation research in the US, Europe and Japan. A short history of machine translation is presented first, followed by an overview of the current research work. Representative examples of a wide range of different approaches adopted by machine translation researchers are presented. These are described in detail along with a discussion of the practicalities of scaling up these approaches for operational environments. In support of this discussion, issues in, and techniques for, evaluating machine translation systems are addressed. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. TheHistoryofMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVANCES IN COMPUTERS, VOL. 49 ISBN 0-12-012149-2

1

2

3

Copyright 01999 by Academic Press All rights of reproduction in any form reserved.

2

BONNIE J. DORR ETAL.

3. Translation Challenges . ............................................ 3.1 Linguistic Consider s ......................................... 3.2 Operational Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Direct Architecture .......................... 4.2 Transfer Architectures. . . . . . . . . . . . ............................ 4.3 Interlingual Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5. Paradigms of MT Research Systems. . . . . . . . . . . . . . . . . . . . 5.1 Linguistic-based Paradigms. . . . . . . . . . . . . . . . . . . . . . . 5.2 Non-linguistic-based Paradigms . . . . ......................... 5.3 Hybrid Paradigms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Evaluation of MT Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Evaluation Challenges. .......................... 6.2 Evaluation Approaches . . . . . . . . . . . ......... 6.3 Evaluation Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Examples of Machine Translation Evaluations. . . . . . . . 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

54 55 56

1. Introduction Machine translation (MT), that is, translation from one natural language into another by means of a computerized system, has been a particularly difficult problem in the area of artificial intelligence (AI) for over four decades. Early approaches to translation failed in part because the interactive effects of complex phenomena made translation appear to be unmanageable. Later approaches to the problem have achieved varying degrees of success. In general, most MT systems do not attempt to achieve fully automatic, highquality translations, but instead strive for a level of translation that suits the basic needs of the user, perhaps requiring controlled input or revisions (post-editing) or both to arrive at the final result. This paper is a survey of the current MT research in the US, Europe and Japan. While a number of MT surveys have been written (see e.g. [IOO, 101, 119,135,139,153, 155,198,2001) this one discusses a wide range of current research issues in light of results obtained from a survey and evaluation project conducted by Mitre [26,27, 1121. During this project we evaluated 16 systems (10 operational and 6 under development) and also studied 7 US research systems. Because a number of innovative MT approaches have come about since the completion of the Mitre study, we also include some discussion about more recent research paradigms. However, we do not attempt to describe all MT research in detail. Rather, we present approaches as representative examples of a wide range of different approaches adopted by MT researchers. The next section provides a brief description of the history of MT. In

CURRENT PARADIGMS IN MACHINE TRANSLATION

3

section 3, we discuss the types of challenges (both linguistic and operational) that one must consider in developing an MT system. Section 4 describes three architectural designs that are used for MT. Following this, we compare translation systems along the axis of research paradigms (section 5 ) ; these include linguistic, non-linguistic, and hybrid approaches. We then discuss the difficult task of evaluating an MT system in section 6. Finally, we conclude with a discussion about what results we should expect to see in the future and where more effort needs to be placed.

2. The History of MT Numerous attempts have been made in the past, both in the United States and Europe, to automate various steps in the translation process. These attempts range from simple on-line bilingual dictionaries, terminology data banks, and other translation aids to complete MT systems. Much work was done in the 1950s and 1960s toward achieving MT. However, the 1966 Automatic Language Processing Advisory Committee (ALPAC) report [5] condemned those efforts, citing poor-quality technology and the availability of inexpensive manual labor as negative-cost factors. These early efforts failed for several reasons, not the least of which was the unreasonably high expectation for perfect translation without having the basic theoretical foundation to achieve this. The ALPAC report caused a major reduction in US research and development (R&D) efforts in the area of MT in favor of some related areas, such as computational linguistics and artificial intelligence, that subsequently provided a better theoretical foundation for current MT R&D. Nevertheless, reduced but still significant MT research did continue at such places as the University of Texas/Austin, Brigham Young University, and Georgetown University. The ALPAC report also affected the R&D effort in Europe, but again, significant research continued in Western Europe and the USSR. An important side-effect of the reduced R&D funding for MT was the stimulation of a number of commercial MT endeavors by those displaced from the research centers. This resulted in most of our current operational MT systems, including Systran and Logos. In the late 1960s, MT R&D was initiated in Canada, driven by the bilingual status of the country. In the late 1970s and the 1980s, two significant events occurred. The first was the formation of the EUROTRA project by the European Communities (EC) to provide MT of all the member nations’ languages. The second was the realization of both Japanese government and industry that MT of Japanese to and from European languages first, and later to and from other Asian languages, was important to their economic progress. Thus far the EUROTRA project has failed to meet its goal of

4

BONNIE J. DORR ETAL.

complete intertranslation of all the member languages; however, it has initiated important new research in MT and computational linguistics, and augmented existing MT research. Commercial MT systems supporting limited language pairs are now beginning to emerge from this effort. The EUROTRA project continues with somewhat narrowed goals in that a large single system is not being attempted. The Japanese efforts have produced a plethora of prototypes and commercially available operational systems, most based on established technology. Japanese research in MT, while never extensive, has been increasing both in quality and funding. A small effort is also under way in the former Soviet Union. In the United States, research and commercial development have expanded considerably since the mid- 1980s. In part, this expansion has been stimulated by the desire for more foreign markets. Government funding has increased, and MT research has evolved out of computational linguistics work at such places as New Mexico State University, Carnegie Mellon University, and University of Maryland. Several commercial systems have been developed, providing translation capabilities that are limited but effective for some applications. Several small companies are developing and marketing more complete MT systems based on more recent technology. The US Government, through its civil, military, and intelligence branches, is showing increased interest in using and supporting MT systems. A market for MT is developing among international and domestic corporations that are competing in the world market. In summary, work on MT has been under way for over four decades, with various ups and downs. The ALPAC report of the mid-1960s was a serious, but by no means devastating, setback to the effort, and the current trend is

ALPAC

$$ Activity

/iSR Europe

1958

1966

us

us

Europe Canada USSR

Europe Canada Japan USSR

I977

FIG. 1. A history of MT.

1991

5

CURRENT PARADIGMS IN MACHINE TRANSLATION

toward increased support. This history is illustrated by Fig. 1 adapted from a chart by Wilks [225].

3. Translation Challenges This section discusses the types of challenges that one must consider in developing an MT system. We examine these challenges along two dimensions, the first pertaining to different types of linguistic considerations (e.g. syntactic word order and semantic ambiguity) and the second pertaining to different types of operational considerations (e.g. extensibility, maintainability, and user interface).

3.1 Linguistic Considerations There are three main categories into which the linguistic considerations fall; language understanding, language generation, and the mapping between language pairs. Roughly, these are related as shown in Fig. 2. Regarding the first category, there have been many arguments in the past both for, and against, the idea that a complete understanding of the source text is necessary for adequate MT (see [18, 45, 134, 155, 1571, among others). In more recent years, however, researchers have started to concentrate on the issue of whether it is possible to achieve a satisfactory translation with a minimal amount of understanding[25]. With respect to this issue, the areas to consider are: syntactic ambiguity, lexical ambiguity, semantic ambiguity, and contextual ambiguity. Each is addressed below. In English, syntactic ambiguity arises in many contexts including the attachment of prepositional phrases, coordination, and noun compounding. For other languages the types of syntactic ambiguities will vary. The difficulty of prepositional phrase attachment is illustrated in the following English sentence.

Source

Language

Language Understanding

Language Generation

' Source-to-Target Mapping I

Information

\ - - , - - -

I I

,

FIG.2 . Three categories of linguistic considerations.

Target Language

6

BONNIE J. DORR ETAL.

Example 1 Syntactic Ambiguity I saw the man on the hill with the telescope Here, we have no way to determine whether the telescope belongs to the man or the hill. However, in such cases, particularly for similar languages, it may not be necessary to resolve such an ambiguity since a particular source-language syntactic ambiguity may transfer to the target language and still be understandable to human readers. In the case of lexical ambiguity, the choice between two possible meanings of a source-language lexical item is often easily resolved if enough syntactic context is available. Consider the following example:

'

Example 2 Lexical Ambiguity

E: book S: libro, reservar The English word book would be translated to the Spanish noun libro if it appeared after the word the or to the verb reservar if it appeared before the phrase theflight. A more formidable problem is semantic ambiguity; the resolution of this type of ambiguity falls outside of the realm of syntactic and lexical knowledge as in the following examples.

Example 3 Semantic Ambiguity (i) Homography: E: ball S: pelota, baile (ii) Polysemy: E: kill S: matar, acabar Many words, such as ball, have distinctly different meanings (homography);

MT systems are forced to choose the correct meaning of the sourcelanguage constituent in these cases (e.g. whether ball corresponds to a spherical object (pelota) or a formal dance (baile)). Other problems arise for words like kill which have subtle related meanings (polysemy) in different contexts (e.g. kill a man (matar) v. kill a process (acabar)) and are frequently represented by distinct words in the target language.

'

Throughout this paper, the abbreviations C, D, E, G, and S will be used to stand for Chinese, Dutch, English, German, and Spanish, respectively. (Literal translations are included for the non-English cases.)

CURRENT PARADIGMS IN MACHINE TRANSLATION

7

Semantic ambiguity has often been considered an area in which it would be too difficult to provide an adequate translation without access to some form of “deeper” understanding, at least of the sentence, if not the entire context surrounding the sentence [ 18,451. The following well-known examples illustrate the difficulty of semantic ambiguity.

Example 4 Complex Semantic Ambiguity (i) Homography: E: The box was in the pen. S: La caja estaba en el corral/*la pluma “The box was in the pen (enclosure)/*pen (writing)” (ii) Metonymy: E: While driving, John swerved and hit a tree. S: Mientras que John estaba manejando, se desvib y golpeb con un arbol. “While John was driving, (itself) swerved and hit with a tree” In Example 4(i), the system must determine that the pen is not a writing implement but some sort of enclosed space (i.e. a play pen or a pig pen) (homography resolution). In (ii), the system must determine that it is John who is driving but John’s car that hit the tree (metonymy resolution). However, according to Bennett [25], the sort of ambiguity represented by these examples rarely arises in texts to which MT is typically applied; he argues that contextual ambiguity occurring in routinely translated texts (e.g. computer manuals) is often easily resolved by means of a simple featurebased approach. Consider the following examples.

Example 5 Contextual Ambiguity (i) E: The computer outputs the data; it is fast S: La computadora imprime 10s datos; es ripida “The computer outputs the data; (it) is rapid” (ii) E: The computer outputs the data; it is stored in ascii S: La computadora imprime 10s datos; e s t h almacenados en ascii “The computer outputs the data; (they) are stored in ascii” In the context of a computer manual, determining the appropriate antecedent for the word it can be solved by distinguishing between storable objects and non-storable objects (storable *) and between objects with a speed attribute and those without (speed fast/slow). Note that, although a computer is a storable object in other contexts, we can view it as a non-storable object in the limited domain of a computer manual. More difficult ambiguities arise in translations that are truly ambiguous without extensive contextual cues, i.e. those that require discourse or prag-

a

BONNIE J. DORR ETAL.

matic knowledge for correct interpretation. An effective discourse analysis would recognize themes and theme shifts in the text surrounding a sentence. As a simple example, consider the ambiguity in the following sentence.

Example 6 Complex Contextual Ambiguity E: John hit the dog with a stick S: John golped el perro con el palo / que tenia el palo “John hit the dog with the stick / that had the stick” This ambiguity could be resolved by remembering from the earlier text that John was carrying a stick to protect himself (and not that there were several dogs, one of which had a stick). Pragmatic analysis deals with the intentions of the author in affecting the audience. This is as important for language generation (to be discussed next) as it is for language understanding. In particular, the author’s intentions affect the choice of words and how they are realized (e.g. the use of active rather than passive voice to emphasize urgency). Together, discourse knowledge and pragmatic knowledge are useful in resolving many types of ambiguities. A second type of linguistic problem for MT is that of language generation. Most MT researchers are of the opinion that generation of the target-language sentence does not require a full language generation capability, i.e. it is not necessary to fully plan the content and organization of the text; this is because the source-language text provides much of the information that will appear on the surface in the target language. However, generation for MT is a non-trivial exercise since it is often difficult to choose the words that adequately convey the conceptual knowledge behind the source-language sentence. This is the lexical selection problem. Some simple examples for Spanish and English are given here.

Example 7 Lexical Selection (i) S: esperar E: wait, hope (ii) G: konnen E: know, understand (iii) E: be S: ser, estar (iv) E: fish S: pez, pescado Assume, for the sake of the current discussion, that an MT generator must select the appropriate target-language words from general notions such as expect, have knowledge of, be, and fish, respectively. In the above example, additional information is required for choosing the relevant term from each

CURRENT PARADIGMS IN MACHINE TRANSLATION

9

target-language pair. A possible scheme would be to use distinguishing features, e.g. +desire, *fact, *permanent, and +edible, respectively. Further problems arise for MT generation in cases where linguistic information required in the target language is not explicit in the source language sentence. Consider the following example.

Example 8 Tense Generation C: W b bki Hingzh6u de fEngjing xiyinzhh le E: I was captivated by the scenery of Hangchow E: I am captivated by the scenery of Hangchow In this example, two different English sentences might be generated from the Chinese. This is because tense information (past, present, future) is not overt in the source-language text. The information used to select the targetlanguage tense depends entirely on the context of the utterance. For example, the second sentence would be generated if the speaker is looking at the scenery at the time of speech. The generation of tense is problematic in other languages as well. In Spanish there is a distinction made between simple past (preterit) and the ongoing past (imperfect). This type of distinction is not made explicitly in English. Consider the following example.

Example 9 Tense Generation (i) E: Mary went to Mexico. During her stay she learned Spanish. S: Mary iba a Mexico. Durante su visita, aprendi6 espaiiol. (ii) E: Mary went to Mexico. When she returned she started to speak Spanish. S: Mary fue a Mexico. Cuando regres6, comenz6 a hablar espaiiol.

In (i) went is translated as the Spanish imperfect past since the sentence that follows is an elaboration, making went stative. In (ii) went is translated as a preterit past since the sentence that follows does not elaborate the visit to Mexico. (For a discussion about analogous examples in French, see [76].) As we will see in section 3.2, the problems of understanding and generation in MT are often addressed by restricting the domain of the text so that the lexicon and grammar are constrained. A third type of linguistic problem for MT concerns the mappings between source- and target-language representations. There are a number of dimensions along which source- and target-language representations may vary. These divergences make the straightforward mapping between languages impractical. Some examples of divergence types that MT researchers strive This example is based on personal communication with Yan Qu,

10

BONNIE J. DORR ETAL.

to address are thematic, head-switching, structural, categorial, and conflational. Each of these will be discussed, in turn. Thematic divergence involves a “swap” of the subject and object positions.

’

Example 10 Thematic Divergence

E: I like Mary S: Mary me gusta “Mary (to) me pleases” Here, Mary appears in object position in English and in subject position in Spanish; analogously, the subject I appears as the object me. Head-switching divergences occur commonly across language pairs. In such cases, a main verb in the source language is subordinated in the target language.

Example 11 Head-Switching Divergence E: I like to eat G: Ich esse gern “I eat likingly” Observe that the word like is realized as a main verb in English but as an adverbial modifier (gern) in German. In structural divergence, a verbal argument has a different syntactic realization in the target language.

Example 12 Structural Divergence

E: John entered the house S: Juan entr6 en la casa “John entered in the house” In this example, the verbal object is realized as a noun phrase (the house) in English and as a prepositional phrase (en la casa) in Spanish. Categorial divergence involves the selection of a target-language word that is a categorial variant of the source-language equivalent. In such cases, the main verb often changes as well.

Example 13 Categorial Divergence

E: I am hungry G: Ich habe Hunger “I have hunger” Many sentences may fit into these divergence classes, not just the ones listed here. Also, a single sentence may exhibit any or all of these divergences.

CURRENT PARADIGMS IN MACHINE TRANSLATION

11

In this example, the predicate is adjectival (hungry) in English but nominal (Hunger)in German. Note that this change in category forces the generator to select a different main verb. Conflation is the incorporation of necessary participants (or arguments) of a given action. A conflational divergence arises when there is a difference in incorporation properties between the two languages.

Example 14 Conflational Divergence

E: I stabbed John S: Yo le di puiialadas a Juan “I gave knife-wounds to John” This example illustrates the conflation of a constituent in English that must be overtly realized in Spanish: the effect of the action (knife-wounds) is indicated by the word yufialadas whereas this information is incorporated into the main verb in the source language. Resolution of cross-language divergences is an area where the differences in MT architecture are most crucial. Many MT approaches resolve such divergences by means of construction-specific rules that map from the predicate-argument structure of one language into that of another. More recent approaches use an intermediate, language-independent representation to describe the underlying meaning of the source language prior to generating the target language. The details of these contrasting approaches will be discussed further in section 4.

3.2 Operational Considerations In addition to the above linguistic challenges, there are several operational challenges. These include: extension of the MT system to handle new domains and languages; handling a wide range of text styles; maintenance of a system once it has been developed; integration with other user software; and evaluation metrics for testing the effectiveness of the system. Typically, to handle the linguistic challenges associated with understanding or generating a text, the text is restricted by domain so that the lexicon and grammar are more restricted. By doing so, the problems of lexical ambiguity, homography, polysemy, metonymy, contextual ambiguity, lexical selection, and tense generation are reduced. Then when building or extending an MT system to handle a particular domain and language, the designer must take on the smaller but still expensive task of acquiring and adapting the lexicon. To give an idea of the size of a domain lexicon, we have seen domain lexicons in commercial MT systems ranging from around 8000 to 12000 entries. The lexicon size varies according to the domain and whether an entry represents multiple senses or a single sense.

12

BONNIE J. DORR ETAL.

Although several researchers have developed tools to help with the acquisition of the lexicon (see e.g. [28,31, 32, 34, 36,43,54,69,74, 81, 89, 132, 143, 145, 164, 165,166, 169, 171, 172,212,219,227,2311) these tools only help reduce the overall amount of work that is required by a small amount. The majority of the work still requires manual entry and fine-tuning by people with specialized expertise in linguistics and in the domain for which the system is being built. The words that should be included in the system can be extracted from a representative corpus and their possible parts of speech assigned. However, each of these entries must be reviewed to correct the part of speech assignments since the automated process is not 100% accurate. In addition, the entries must be manually modified so that other linguistic features can be added. While some argue that one would want to manually review and fine-tune each entry anyway [142], the expense involved depends on the system architecture and research paradigm involved (i.e. statistical-based MT systems do not require detailed linguistic and domain knowledge). For systems that require large amounts of encoded knowledge, research is in progress to automatically extract other linguistic features from published bilingual and monolingual dictionaries and from parallel corpora, [31,40,68,79,88, 1491. Another issue is how to cost effectively maintain a lexicon once it has been acquired. Most interfaces that have been built for users with no specialized linguistics training still look much like the first such interface created for the TEAM project [93]. (Other lexical interfaces are described in [17, 20, 71, 90, 92, 94, 125, 208, 2091.) The maintainer is presented with various sentences utilizing the word being updated and asked to indicate which usages are correct and which are not. Each sentence represents a test to determine whether or not a particular linguistic feature applies. One problem with these interfaces is that asking these types of questions does not work for all words. Someone with linguistic expertise will still have to review the results of the maintenance session. For example, once the Spanish verb gustur is entered into the lexicon as a psyche verb, someone with knowledge about linguistic structure must check that the argument structure (i.e. ordering of subject with respect to the object) is the reverse of the argument structure for the analogous English word like. (Example 10 given earlier illustrates this thematic divergence between Spanish and English .) The extension of a system to handle additional languages also involves providing an analysis grammar for the source language and a generation grammar for the target language. Creating these grammars requires specialized linguistics knowledge as well as an understanding of the domain for which the system is being built since the grammar writer usually must understand the text in order to write a grammar that will produce an appropriate

CURRENT PARADIGMS IN MACHINE TRANSLATION

13

analysis. Grammar writing is the point at which many of the linguistic challenges associated with understanding and generation must be addressed. Heuristics relevant to the particular domain are often utilized at this point. For example, in Eurotra preferences for PP attachment are expressed with heuristics such as: “a PP which is not a modifier is preferred over the same PP when it is a modifier” [23]. As the grammar is being written it must be continually tested and refined in order to arrive at a reasonably good result for most of the expected inputs. Herein lies two major challenges: determining what a reasonably good result is and predicting the most likely inputs. Since grammar writing requires a great deal of linguistic expertise, even a small adjustment to the grammar is a development issue and not a user maintenance issue. Even as a development problem, this is one of the more time-consuming tasks and one for which not many tools have been created. Another operational consideration is the type of text to be translated. Handling a wide range of styles and sources of published text presents vastly different degrees of operational difficulties for MT systems. Literary texts, such as novels and poetry, make frequent use of metaphor, have complex and unusual sentence structure, and assume a wide world and social context; these are all outside the competence of current MT systems. This is also true of popular journalistic texts, which, in addition, use (or create) the most fashionable words and social context. The problem is exacerbated by the fact that authors of these texts assume their audiences are knowledgeable about the general world and in some cases about the technical field underlying their writings. Often, the text cannot be understood without this type of knowledge, referred to as world knowledge. MT systems fail for texts that rely heavily on metaphor and world knowledge because they have great difficulty in representing and using complex and subtle metaphors or understanding social context and interactions, and it is nearly impossible for them to keep up with the rapid changes in vocabulary. MT systems work best for texts that are written using simple syntax, make little or predictable use of metaphor, and have a stable vocabulary and a limited domain. Scientific and technical documents fall into this category and thus far have represented the most successful applications of MT. Text fragments such as tables of contents and sentence fragments present a different situation in that the syntactic rules must be relaxed to deal with incomplete sentences and possibly ungrammatical phrases. Since there may be little context as a basis for translating the fragments, lexical selection becomes an important and difficult problem. Another operational consideration is the necessity for the MT system to be designed in such a way that it can be effectively integrated with other user software such as optical character recognition (OCR) and document

14

BONNIE J. DORR ETAL

publishing tools [4, 82, 96, 98, 1441. An application such as OCR might utilize some of the linguistic information that is available to the MT system; thus, this information should be handled in such a way that it is easily retrievable and usable independently from the MT system. Research MT systems tend to be modular and this operational consideration provides further motivation and challenges in designing the system. A final operational consideration is how to evaluate and test the MT system. This applies to both users and developers of systems. When a system is being extended or when a purchase is being considered, there must be a way to test the effectiveness of a system in meeting the user’s requirements. Further, when building research systems, one needs to be able to evaluate the effectiveness of the approach. As mentioned earlier in the above discussion on grammar writing, predicting the inputs is a challenge. In the case of evaluation, the question is whether the testing adequately covers the possible inputs when it is not clear what all the inputs will be. A second difficulty is determining the cerrectness of a translation. The correctness depends on the intended usage of the translation. Along with this, correctness is not a single binary judgement but a set of judgements which may or may not be binary. An important issue in evaluation is that of choosing the appropriate judgement for a particular use of translation. We elaborate on these evaluation issues and the research in this area later in section 6.

4. Architectures Current architectures for MT may be roughly organized into the following three classes: (1) direct; (2) transfer; and ( 3 ) interlingua. These levels have been characterized in terms of a “pyramid” diagram (see Fig. 3 ) which first appeared (in a slightly different form) in [218] and has since become classic. The three levels correspond to different levels of transfer, depending on the depth of analysis provided by the system. At the bottom of the pyramid is the direct approach which consists of the most primitive form of transfer, i.e. word-for-word replacement. At the top of the pyramid is the interlingual approach which consists of the most degenerate form of transfer, i.e. the transfer mapping is essentially non-existent. Most translation systems fall somewhere between these two extremes ranging from a shallow (syntactic) analysis to a deeper (semantic) analysis. We will discuss, in turn, the MT architectures corresponding to these three levels.

4.1

Direct Architecture

The result of a direct translation architecture is a string of target-language words directly replaced from the words of the source language. Generally

CURRENT PARADIGMS IN MACHINE TRANSLATION

15

Target Text

Source Text

FIG.3. Types of MT systems.

the word order of the target-language text is the same as that of the sourcelanguage, even in cases where the target-language does not permit the same word order. Unless the reader has a good knowledge of the source-language structure, this text can be very difficult to understand. Some systems based on the direct architecture recognize special sourcelanguage syntactic forms and reorder the words to acceptable forms in the target language. These syntactic improvements increase the readability of the target text. For example, a direct approach might handle the thematic divergence of Example 10 given earlier by means of a rule such as the following.

Example 15 Direct Mapping X LIKE Y -+Y GUSTAR X As we will see below, such rules are closer in nature to those used in the transfer approach. Unfortunately, without a detailed syntactic analysis, only simple forms can be recognized; consequently, complex structures, such as clauses and verb separations (as are frequently found in German), are left in the original syntax. Moreover, when more difficult cases arise, e.g. Example 11 above, it is impossible to construct direct mapping rules. The result is that this approach typically generates very literal translations, e.g. Z eat Zikingly for the German sentence Zch esse gern.

16

BONNIE J. DORR ETAL

A more serious problem with systems based on the direct architecture (as well as with some versions of transfer architecture systems) is selection of the correct target-language words for source-language words (lexical ambiguity). Recall from section 3.1 that many words, such as ball, have distinctly different meanings (homography) and translations; others, such as kill, have subtle related meanings (polysemy) that are frequently represented by distinct words in the target language. Direct architecture systems cannot cope with this lexical selection problem since they cannot relate a word to the way it is used in a sentence. The best that can be done is to restrict the textual domain and include in the lexicon only the translation most likely for that domain. Direct architecture systems produce, at best, poor translations. However, for limited domains and simple text (such as tables of contents or text fragments where correct syntax is less critical), they sometimes produce translations useful to domain experts.

4.2 Transfer Architectures As shown in Fig. 3, transfer architectures lie on a spectrum ranging from direct to interlingual architectures: at the direct architecture end of the spectrum is the syntactic transfer architecture; at the interlingual end of the spectrum is the semantic transfer architecture. The initial intent of transfer architecture systems was to provide syntactically correct targetlanguage text by transforming source-language representations into suitable target-language syntactic representations. Although the transfer rules that perform this conversion depend on both the source and target languages, some of the rules may need only slight modification when an MT system is developed for a new target language linguistically related to an existing one. Both the transfer and the interlingual approaches require “linking rules” that map between the surface (source- and target-language) text and some form of internal representation. What distinguishes these two approaches is that the internal representations used in the transfer approach are assumed to vary widely from language to language. Thus, transfer rules must be constructed to map between these two representations. As we will see in the next section, no transfer rules are needed in the interlingual approach because the same internal representation is used for both the source and target languages. Although the internal representations used for the source and target languages are not the same, the primitives (e.g. SUBJ, OBJ1) used in these representations are often similar, or even identical. The use of similar primitives allows for more general mapping rules than that of the direct approach. For example, the rule for mapping between the sentences

CURRENT PARADIGMS IN MACHINE TRANSLATION

17

in Example 10 would be more general than the analogous rule in Example 15.

Example 16 Transfer Mapping gustar(SUBJ(ARG 1:NP),OBJ 1(ARG2:PREP)) + like(SUBJ(ARG2:NP),OBJ1(ARG 1:NP)) The effect of this rule is to swap the subject and object arguments and to change the category of the object from a preposition (in Spanish) to a noun phrase (in English). Unlike the direct approach, the transfer architecture accommodates more complex mappings such as that of Example 11. (We will discuss specific approaches to handling such cases in section 5.1.3.) However, a common criticism of this approach is that a large set of transfer rules must be constructed for each source-language/target-languagepair; a translation system that accommodates y1 languages requires n2 sets of transfer rules. This shortcoming has been noted by a number of researchers (see, e.g. [24,65]). Despite the drawbacks associated with the use of transfer rules, the syntactic transfer architecture has the advantage that ambiguities that carry over from one language to another are handled with minimal effort. Consider the example given earlier: John hit the dog with a stick. In this example, the syntactic ambiguity is not resolved by the syntactic analysis because there is no way to determine from syntax alone whether the dog had a stick or John used a stick to hit the dog. We have already seen that, if we are translating between similar languages, it may not be necessary to resolve the ambiguity; the source-language syntactic ambiguity may transfer to the target language and still be understandable to human readers. In an attempt to improve performance, some syntactic transfer architecture systems take advantage of this phenomenon and refrain from doing a complete syntactic analysis of these structures. Transfer approaches are also able to resolve certain lexical ambiguities since the syntactic analysis can usually determine the lexical category (part of speech) of a source text word. For example, as mentioned earlier, it is possible to determine whether the English word book would be translated in Spanish to the noun libro or to the verb reservar, depending on the local context. The overall translation quality of syntactic transfer architecture systems tends to be lower than those that employ a deeper analysis of the source-language text. Many lexical and syntactic ambiguities are not resolvable; consequently, long and complex sentences may not be understandable. In an attempt to improve translation quality by considering the meaning of the sentences, most transfer architecture systems have moved to the semantic

18

BONNIE J. DORR ETAL.

transfer end of the spectrum by adding semantic analysis and semantic transfer rules as needed (i.e. ambiguities such as the hall and with a stick cases above would be resolved). The result of this combined syntactic and semantic analysis is a representation of the source text that combines translationrelevant syntactic and semantic information. Since this is usually done to solve specific language pair problems, the semantic analysis remains incomplete and, to some extent, language pair-dependent. That is, the addition of a new target language may well require modification of the source-language semantic analysis. In principle, semantic transfer architecture systems have the capability to produce excellent translations, provided that a context (discourse and pragmatic) analysis is done in addition to a deep semantic analysis. In practice, little or no discourse or pragmatic analysis is done, and only enough semantic analysis is done to meet the translation goals of the system. Semantic transfer architecture systems can produce good translations when the analysis and iules are complete, and the bilingual lexicon covers the domain of interest. A perceived difficulty with transfer architecture systems is that the transfer rules and, to some extent, the source-language analysis aye dependent on both the source and target language. Thus a new system would have to be developed for each language pair of interest. This is not as problematic as might be expected. First, target-language generation can be expected to need little augmentation when a new source language is added. Second, much of the source-language analysis will not change as new target languages are added; only newly discovered semantic and structural differences need be resolved. Finally, it is true that new transfer rules will be required. However, the addition of a new source or target language will affect only the recognition or production parts of the rules, respectively; if the language is being replaced by one similar in structure, many of the transfer rules need not be changed. Of course, the addition of radically different languages (e.g. the first Asian language added to a system working between European languages) will require a major effort. At the semantic-transfer end of the spectrum there is a final category of transfer architecture that could be viewed as a “special-case interlingual” design, i.e. one that defines a single syntactic and semantic representation for several related languages, such as the Romance languages. This approach is termed “multilingual.” In Fig. 3 , the multilingual representation takes the place of two semantic structure nodes; no transfer rules are necessary, yet the representation is not interlingual since, as in standard transfer systems, it relies on the characteristics of the source and target languages. In this approach the analysis and generation processes depend only on the respective source and target languages. In practice, this approach is being exploited by a number of systems.

CURRENT PARADIGMS IN MACHINE TRANSLATION

19

To summarize, transfer architecture systems produce higher-quality results than direct architecture systems, but at the expense of having to develop extensive source-language analysis techniques and sets of transfer rules.

4.3

Interl ing ual Architectures

The basic idea of the interlingual (sometimes called pivot) architecture for MT is that the analysis of the source-language text should result in a representation of the text that is independent of the source language. The targetlanguage text is then generated from this language-neutral, interlingual representation. This model has the significant advantage that analysis and generation development need be done only once for each language, and a translation system can be constructed by joining the analysis and generation through the interlingual representation. This is currently a very active area of research, although a few commercial systems are based on this approach, [16, 53, 80, 160, 161, 1871. The research issues center on the feasibility of specifying an interlingua that is adequate for all languages and on the depth of semantic analysis required to produce acceptable translations. The latter is also an issue for the more ambitious systems based on the semantic transfer architecture. The interlingual approach to Example 10 would be to assume that there exists a single underlying concept for the meaning of the main verb in both sentences, i.e. a representation such as the following.

Example 17 Interlingual Representation like/gustar: [CAUSE (X, [BE (Y, [PLEASED])1)l4 This representation conveys the idea that something or someone (X) causes someone (Y) to be pleased. An approach that adopts this representation would not require transfer rules since the representation would be the same for the source and target languages. Instead, all that would be needed is to define “linking rules” that map between the surface (source- and target-language) text and the interlingual form. An issue raised with respect to this approach is that, because interlingual representations are generally independent of the syntax of the source text, the generation of the target language text from this representation often takes the form of a paraphrase rather than translation (see, e.g. [lo, 102, 1081.) That is, the style and emphasis of the original text are lost. However, This is a simplified, generic version of a Lexical Conceptual Structure (LCS) representation that could be attributed to a number of researchers including Schank [184, 185, 1861 and Jackendoff [105,106] among others. See [65] for a more detailed treatment of such cases.

20

BONNIE J. DORR ETAL.

this is not so much a failure of the interlingua as it is a lack of understanding of the discourse and pragmatics required to recognize style and emphasis. In some cases, it may be an advantage to ignore the author’s style. Moreover, many have argued that, outside the field of artistic texts (poetry and fiction), preservation of the syntactic form of the source text in translation is completely superfluous (see e.g. [157, 2221.) For example, the passive voice constructions in the two languages may not convey identical meanings. The current state of the art seems to be that it is possible to produce interlinguas that are adequate between language groups (e.g. Japanese and western European) for specialized domains. Another issue concerns a point raised earlier, i.e. that authors of source texts assume their audiences are knowledgeable about the general world and in some cases about the technical field underlying their writings. Many researchers (e.g. [ 1551) who adopt the interlingual approach aim to employ a deep semantic analysis that requires extensive world knowledge; the performance of deep semantic analysis (if required) depends on the (so far unproven) feasibility of representing, collecting, and efficiently storing large amounts of world and domain knowledge. This problem consumes extensive efforts in the broader field of artificial intelligence.

5. Paradigms of MT Research Systems The architectural basis of the system is only one of many axes along which one might compare MT systems. Another important axis of comparison is that of research paradigm. It is important to understand the difference between the type of architecture and the type of paradigm: one does not presuppose the other. The former refers to the actual processing design (i.e. direct, transfer, interlingual), whereas the latter refers to informational components that aid the processing design (knowledge-based, example-based, statistics-based, etc.). This section enumerates and discusses some of the more recent classes of MT paradigms that researchers are currently investigating. This list is by no means exhaustive. It is intended to cover most of the approaches that have been introduced in recent years, a vast majority of which have been reported in the last five years at a number of conferences including the Annual Meeting of the Association for Computational Linguistics (ACL), the International Conference on Theoretical and Methodological Issue in Machine Translation (TMI), the Conference of the Association for Machine Translation in the Americas (AMTA), the International Conference on Computational Linguistics (COLING), and the Machine Translation Summit (MT-Summit).

CURRENT PARADIGMS IN MACHINE TRANSLATION

21

There may be some disagreement about the boundaries of the classification. For example, the S&BMT paradigm has been viewed as constraintbased (CBMT) (see e.g. [223,224]) in that the translation process is taken to be a collection and resolution of sets of constraints. It has also been viewed as lexical-based (LBMT) (see e.g. [21,22]) in that a bilingual lexicon is used to put into correspondence pairs of monolingual lexical entries. Frequently, researchers employ techniques from several categories. An example of such a case is an approach described in [91] which proposes to combine techniques used in example-based (EBMT), statistics-based (SBMT), and rulebased (RBMT). We will discuss research paradigms in terms of three different categories: (1) those that propose to rely most heavily on linguistic techniques; (2) those that do not use any linguistic techniques; and (3) those that use a combination of the two. The separation of linguistic-based and non-linguistic-based approaches illustrates an emerging dichotomy among MT researchers that first became evident at the TMI in 1992. This is the confrontation dubbed the “rationalist-empiricist” debate, which divides researchers into two groups, those who advocate well-established methods of rule-based/ constraint-based MT (linguistic-based MT) and those involved in newer corpus-based MT (including EBMT, SBMT, and neural network-based (NBMT)). Many of these same issues have continued as hot topics of debate during the TMI in 1992. Several researchers have now acknowledged the need for a hybrid or integrated approach to MT that makes use of techniques from both types of paradigms, combining the best that each paradigm type has to offer.

5.1

Linguistic-based Paradigms

Until very recently, most MT researchers studied linguistic-based MT, i.e. translation on the basis of principles that are well grounded in linguistic theory. Systems based on linguistic theory strive to use the constraints of syntax, lexicon, and semantics to produce an appropriate target-language realization of the source-language sentence. This section presents several of the most recent linguistic-based paradigms.

5. I. I

Constraint-based MT

Constraint-based (CBMT) techniques have shown up in several different MT approaches (see, e.g. [14, 76, 115, 116, 178, 223, 2241). For example, the Shake-and-Bake paradigm (discussed below) demonstrates the full utility of constraint application.

22

BONNIE J. DORR ETAL.

In this section, we will discuss one of the earliest MT approaches that uses constraints on a combination of lexical items, i.e. the LFG-MT system [115, 1161. This system translates English, French, and German bidirectionally based on lexical functional grammar (LFG) [ 1131. In the LFG formalism, f-structure (functional structure) is a fundamental component of the translation. For example, the f-structure for the sentence I gave a doll to Mary is:

Example 18 ‘GIVE((? SUBJ)(? OBJ)(? TO OBJ))’

-PRED TENSE OBJ

.To

PAST SPEC NUM PRED PCASE [OH

[

I

A SG ‘DOLL’ TO [PRED ‘MARY’]

1

The LFG-MT system is capable of handling difficult translation cases such as the head-switching case given earlier in Example 11. An example from [ 1151 is the following.

Example 19 Head-switching Divergence E: The baby just fell F: Le bt5bbC vient de tomber “The baby just (verb-past) of fall” Here, the English just is translated as the French main verb venir which takes the falling event as its complement de tomber. The f-structures that correspond, respectively, to the English and French sentences in this example are the following.

Example 20 PRED ARG

‘JUST((? ARG))’ PRED ‘FALL((? SUBJ))’ TENSE PAST PRED ‘BABY’ NUM SG SUBJ DEF

1

+

1

CURRENT PARADIGMS IN MACHINE TRANSLATION

(ii)

PRED SUBJ

'VENlR((I' SUBJ)(I' XCOMP))'
23

1

SPEC XCOMP

PRED COMPL TENSE SUBJ

'TOMBER((I' SUBJ))' DE INF [BEBE]

Because the LFG-MT system is based on construction-specific representations, the mapping operations required in the transfer are performed by transfer equations that relate source- and target-language f-structures. The transfer equations that relate the f-structures Example 20 (i) and (ii) are the following.

Example 21 LFG Transfer Rule (t (t

T PRED 'JUST(( T ARG))') = VENIR T XCOMP = z( TARG)

This equation identifies venir as the corresponding French predicate, and it constrains the argument of just to be a complement that is headed by the prepositional complementizer de. As illustrated here, the LFG-MT framework makes an association between the syntactic structure and the f-structure using a set of mediating selectional constraints that are encoded as lexical entries. The disadvantage to this approach is that the f-structure is tightly coupled with the syntactic structure of the language; thus, if a particular concept can be syntactically expressed in more than one way, there will be more than one f-structure in this framework. A drawback to this approach, discussed in [179], is the handling of cases like Example 19 in the context of embedded clauses. In particular, if the English sentence in Example 19 were realized as an embedded complement such as I think that the baby just fell, it would not be possible to generate the French output. The reason for this is that the LFG-MT system breaks this sentence down into predicate-argument relations that conform (roughly) to the following logical specification.

Example 22 LFG Predicate-Argument Relation think(l,fall(baby)) just(fall(baby)) The problem is that the logical constituent fall(baby) is predicated of two logical heads, think andjust. The LFG-MT generator is unable to determine how to compose these concepts and produce an output string.

24

BONNIE J. DORR ETAL.

More recently, this difficulty has been addressed in [116] where a new description-language operator, restriction, is used to provide a more adequate account of head-switching. A refined version of this approach is described in [59] and currently used in the Verbmobil MT project [58].

5.1.2 Knowledge-based MT Knowledge-based machine translation (KBMT) is a paradigm adopted by developers of numerous US systems including Pangloss at Carnegie Mellon’s Center for Machine Translation [45, 148, 155, 160, 1661; ULTRA at New Mexico State’s Computing Research Laboratory [81, 831; Cyc-NL at CYCORP [ 1311; Japangloss and GAZELLE at University of Southern California and IS1 [123, 1241; UNICON at the University of Pennsylvania [169]; and several European systems including an MT system developed at UMIST’s Department of Language Engineering [S]. More recent extensions to the ULTRA and Pangloss systems have resulted in a Multi-Engine Machine Translation (MEMT) architecture [W]-based on techniques investigated in Mikrokosmos [ 1361-in which the strengths of many different approaches (KBMT, EBMT, SBMT, etc.) are exploited. The KBMT paradigm concentrates on the development of knowledgeintensive morphological, syntactic, and semantic information for the lexicon. Tools have been developed for creating ontologies and have provided a framework for automatic lexical acquisition [125]. In general, the focus of research in KBMT has been on the development of underlying KR concepts. Little attention has been devoted to providing a systematic ‘linking’ of these concepts to the syntax; thus, KBMT is complementary to the (less knowledge-intensive) LBMT and PBMT paradigms described below. An example of a case addressed in KBMT is the translation of a sentence such as the following (taken from [ 1551).

Example 23 Drop by your old favorite Dunkin’ Donuts shop. The underlying representation for this sentence is an interlingual text (ILT) representation involving a set of frames that look like the following.

Example 24 (i) (make-frame text-1 (clauses (value clause-1)) (relations (value relation-1)) (attitudes (value attitude-1)) (producer-intentions (value producer-intention-1)))

CURRENT PARADIGMS IN MACHINE TRANSLATION

25

(ii) (make-frame clause-1 (head (value %visit-I)) (aspect (duration prolonged) (phase begin) (iteration 1)) (time (value time-2))) (iii) (make-frame %visit-1 (is-token-of (value *visit)) (agent (value *consumer*)) (destination (value %shop-I))) (iv) (make-frame relation-1 (type (value domain-conditional)) (first (value %visit-l)) (second (value %involuntary-perceptual-event-1))) (v) (make-frame attitude-1 (type (value &evaluative)) (attitude-value (value.9)) (scope (value %shop-I)) (attributed-to (value *consumer*)) (time (value (since time-5)))) (vi) (make-frame producer-intention-1 (is-token-of (value "cornmissive-act)) (scope (value relation-I))) KBMT requires a syntactic frame (in the lexicon) for each conceptual event that occurs in the ILT. The frame that provides the meaning for the drop by action (which is really a form of visit) looks like the following.

Example 25 (drop (make-frame +drop-v 1 (cat (value v)) (syn-struc ((root $varO) (subj ((root $varl) (cat n))) (obliques ((root $var2) (prep by))))) (sem (lex-map (%visit (agent (value $varl)) (theme (value $var2) (sem *location) (relaxable-to *object)))))))

26

BONNIE J. DORR ETAL.

Note that the syntactic realization information appears in the hand-coded syn-struc slot. The linking rule that relates this information to the ILT is implicit in the specification that appears in the sem slot. In particular, this information specifies that the agent (varl) maps into syntactic subject position and the theme (var2) maps into a syntactic oblique position. This encoding of the linking rule identifies the precise syntactic realization for the underlying concept (i.e. the concept is realized as the verb drop with a subject and an oblique argument). The reason such specific syntactic information is required is that the conceptual representation diverges significantly from the surface realization. In other words, there is no single systematic mapping between a concept and its surface realization. (In the PBMT paradigm described below, we will see that the syntax-semantics mapping may be generalized.) As described in [97], the KBMT paradigm provides high-quality, fullyautomated translations; however, the domains used for this approach are narrow and well defined since the required amount of information would otherwise be large and cost-prohibitive with respect to indexing and searching.

5.1.3 Lexical-based MT Lexical-based MT (LBMT)’ overlaps heavily with several other paradigms including RBMT [9, 10, 11, 131, PBMT [61, 62, 641, and S&BMT [21,22]; in general, a lexical-based system refers to any system that supplies rules for relating the lexical entries of one language to the lexical entries of another language. Several researchers have adopted the lexical-based paradigm, but at different degrees of generality. (See, e.g. [I, 30,60,63,65,70, 75, 78,79, 80, 81, 181, 211,213, 2271.) One such system is the LTAG system [ 11 for English-French and FrenchEnglish. The system is a transfer approach that uses synchronous treeadjoining grammars (as described in [ 1941) to map shallow tree-adjoining grammar (TAG) [113] derivations from one language onto another. The mapping is performed by means of a bilingual lexicon which directly associates source and target trees through links between lexical items and their arguments. Roughly, each bilingual entry contains a mapping between a source-language sentence and a target-language sentence.

’

The acronym LBMT has also been used for linguistic-based MT, which is a more general term referring to techniques that belong to any category outside of EBMT, NBMT, or SBMT. It is used in a more specific sense here, i.e. it refers to those linguistic-based systems that are driven primarily by the lexicon.

CURRENT PARADIGMS IN MACHINE TRANSLATION

27

This approach handles cases such as the following.

Example 26 Categorial Divergence E: John is fond of music F: John aime la musique “John loves the music” Here, the source language concept is realized as the adjectival form befond of in English, whereas the French translation realizes this concept as the verb aimer. The transfer rule that accounts for this mapping directly links the adjectival phrase fond of in the source-language tree with the verb aimer in the target-language tree as shown in Fig. 4. This translation mapping relates the AP node in the English tree to the V node of the French tree. The advantage of this approach is that it accommodates modifying phrases in cases such as the following.

Example 27 Categorial Divergence E: John is very fond of music F: John aime beaucoup la musique “John loves very much the music” Here, the English adverb very is associated with the predicate fond of (instead of with the main verb) whereas in French, the corresponding adverbial beaucoup is associated with the main verb aimer. The mechanism that permits this modification to be appropriately executed is the linking between the adjectival phrase fond of and the verb aimer: since the English main verb be has no link associated with it, the modifier must instead be associated with the adjectival phrase.

/\

I be

_ _ _ _ _ v

AP

V

A

PP

I

I \

P

aimer NP1 - - - - - NP1

I of

FIG.4. Mapping source-language trees to target-language trees in LTAG.

28

BONNIE J. DORR ETAL

One disadvantage to this approach is that it requires entire trees to be stored in the transfer dictionary for each source-to-target pair, which is significantly burdensome as the number of source and target languages begin to add up. However, the approach is powerful in its treatment of cases such as Example 27, which have remained otherwise unaddressed in the literature.

5.1.4 Rule-based MT The rule-based MT (RBMT) paradigm is associated with systems that rely on different linguistic levels of rules for translation between the source and target language, [9, 10, 11, 13,55, 84,91, 115, 116, 129, 140, 163, 176,210, 2151. The prototypical example is Rosetta [176], an interlingual system which divides translation rules into two categories: (1) M-rules, which are “meaning-preserving rules,” map between syntactic trees to underlying meaning structures; and (2) S-rules, which are %on-meaningful rules,” map lexical items to syntactic trees. The former are used for compositional (or “regular”) phenomena and the latter are used for non-compositional (or “exceptional”) phenomena. Consider the following case:

Example 28 Head-switching Divergence E: Mary happened to come D: Mary kwam toevallig “Mary came by chance” The interlingual representation used for this case is a canonical form corresponding to “by-chance (Mary, come ) .” Thus, the English syntactic structure parallels the canonical form: the verb construct corresponding to “by-chance” (happen to) takes as its argument the clause corresponding to “(Mary, come ) ” (come).The Dutch syntax, on the other hand, does not correspond to the structure of the canonical form since the verb corresponding to “ ( come, Mary) ” (kwam) takes as its argument the adverbial construct corresponding to “by-chance’’ (toevallig or “by chance”). In order to handle such cases compositionally, a “switch rule” is triggered by the adverb toevallig and normal processing is interrupted; control is then passed to a module that derives a new category (from an argument of the canonical head) that takes over the role of syntactic head.

The separation of these two rule types is analogous to the notion of relaxed compositionality in systems such as Eurotra and its descendant, MiMo [ 11, 131. Both groups address the same phenomena, e.g. head-switching divergences, but Rosetta uses an interlingual representation instead of transfer rules.

CURRENT PARADIGMS IN MACHINE TRANSLATION

29

This approach differs from the LBMT approach in that the idiosyncratic requirements of individual lexical items are encoded in the control mechanism rather than in the lexicon. In the case above, the control mechanism is governed by grammatical rules that interpret adverbials such as toevallig as a “deviant,” i.e. a non-head in the syntax but a head in the canonical form. In the LBMT approach, such information is encoded in the lexicon, thus allowing only certain adverbials to act as interrupt triggers, namely those associated with a lexical marker. A difficulty with this approach is the accommodation of head-swapping cases where the “deviant” serves as a head in the syntax but a non-head in the canonical form. Consider the following example:

Example 29 Head-switching Divergence E: Mary usually goes to school S: Mary suele ir a la escuela “Mary is accustomed to go to school” In this example, the canonical form could, arguably, be “go (Mary, school, usually) ,” i.e. the English syntax parallels the canonical form. By contrast, the Spanish syntax includes the “deviant” verb suele, which is a head in the syntax but a non-head in the canonical form; this is the inverse of the previous example. The head-swapping rules in Rosetta do not include such a case, perhaps because this would force an interrupt to occur too late-after the syntactic structure corresponding to the logical head has already been built. Even though it might not be linguistically justified, the canonical representation for the Spanish sentence would have to be “be-accustomed (Mary,go ( school ) ) .” By contrast, the English sentence would map into the canonical form given above which means that the two would never be translation equivalents. Instead the system would force the following, more literal, translation pairs (in both directions).

Example 30 Literal Translation (i) E: Mary usually goes to school S: Mary usualmente va a la escuela (ii) Mary is accustomed to going to school S: Mary suele ir a la escuela Taking a grammar-driven approach forces the Rosetta developers to regard such cases of mismatch as purely grammatical. The possibility of extending the notion of compositionality into the lexicon is a possible future direction for Rosetta, which is intrinsically a well-developed system that covers a wide range of linguistic phenomena.

30

BONNIE J. DORR ETAL.

5.1.5 Principle-based MT The principle-based MT (PBMT) paradigm has been investigated by a number of researchers [61, 62, 64, 72, 193, 196, 197, 2211. PBMT is an alternative to RBMT in which rules are replaced by a small set of principles that cover morphological, grammatical, and lexical phenomena in a general fashion. An example of a construction that is derived from general principles is the passive construction (e.g. The ball was hit by John), as described by Berwick in [29. pp. 1-21:

... constructions like passivefollow from the deductive interactions of a relative small set of primitives. On this view there is no “passive rule.” Passive constructions result from the interaction of deeper morphological and syntactic operations. A canonical example of the PBMT paradigm is the PRINCITRAN MT system [72], which is based on syntactic principles of Government-Binding (GB) Theory [5 11 and lexical-semantic principles of Lexical Conceptual Structure (LCS) [65,106, 1051. This system was originally designed for Korean-English machine translation; lexicons for Spanish and Arabic were subsequently developed for related NLP applications (e.g. foreign language tutoring) [67]. In this system, structure building is deferred until underlying descriptions satisfy a number of linguistic principles that are parameterized for ease of porting to new languages [66].The processing mechanism is language independent and accommodates structurally different languages (e.g. head-initial v. head-final) with equally efficient run-times. PRINCITRAN encodes the grammar for each language as a network of nodes that represent grammatical categories (e.g. NP, Nbar, N) or subcategories, such as V:NP (i.e. a transitive verb that takes an N p as complement). Input sentences are parsed by passing messages in the grammar network. The network nodes are computing agents that communicate with each other by sending messages in the reverse direction of the links. GB principles are implemented as constraints attached to and links. All information at a node must satisfy the node’s local constraint. A message can be sent across a link only if it satisfies the link’s constraint. For example, there is a GB principle that requires every NP to be assigned abstract case. The Case Filter rules out sentences containing an NP with no case. A Case Filter violation is detected if a node containing -cm percolates its attribute to a sister node containing -ca, thus ruling out sentences such as I believe John pleased (but allowing, for example, I believe John is pleased). This framework is well suited to an interlingual design since the linking rules between the syntactic representations and the underlying lexicalsemantic representation are well defined. PRINCITRAN uses LCS as its interlingual representation and handles translational divergences (such as

CURRENT PARADIGMS IN MACHINE TRANSLATION

31

those described above in section 3.1) by means of the parameter-setting approach. For example, there exists a single underlying concept for the meaning of the main verb in both the English and Spanish sentences in Example 10 given earlier, yet there are lexical-semantic divergences between the two languages.

Example 31 Thematic Divergence S: [S [NP X’] [VP [gustar [NPY’l111 E: [S [NP Y’] [VP [like [NP X’]]]] The relation between the lexicon entry for the verb and the syntactic representation is captured by means of a general “linking rule”-the main principle by logical arguments are mapped into syntactic positions. In Spanish, the default linking rules are used (e.g. the logical subject X is mapped into the syntactically external position X’). In English, the lexical entry is parameterized to override this linking (e.g. the logically external subject X is mapped into the syntactically internal position X’).

Example 3 1 Lexical Representations for Thematic Divergence like: [CAUSE (X:INT, [BE (Y :EXT, [PLEASED])])] gustar: [CAUSE (X, [BE (Y, [PLEASED])])] The PBMT paradigm is complementary to the KBMT and EBMT approaches in that it provides broad coverage of many different linguistic phenomena, but lacks deeper knowledge about the translation domain. Work is currently underway to combine the benefits of the PBMT and KBMT approaches in a collaborative large-scale Chinese-English MT effort between the University of Maryland and New Mexico State University [70, 164, 1651. 5.1.6 Shake and Bake MT

One of the newest linguistic-based translation paradigms is Shake and Bake MT (S&BMT) 121, 22, 35, 223, 2241, which is a perfect example of why we distinguish between research paradigm and MT architecture. Although the originators of this approach claim that S&BMT is an altemative to the transfer architecture (and also to the interlingual architecture), in fact, transfer rules are precisely the mechanism through which the translation is achieved. However, while the mapping between lexical items is achieved through standard transfer rules, the algorithm for combining these items to form a target-language sentence is non-conventional. The transfer rules are defined on the basis of “bilingual lexical entries” which relate monolingual lexical entries. After the source-language sentence

32

BONNIE J. DORR ETAL

is parsed, the source-language words are mapped to target-language words by means of the bilingual entries. The algorithm used for combining the target-language words attempts to order the words based on syntactic constraints of the target-language. S&BMT is motivated by the need to handle complex translations such as the head-switching case given above in section 3.1. Unlike the transfer approach, the S&BMT algorithm overcomes the difficulty of constructing non-compositional mapping rules for such cases by selecting target-lanp a g e words from a bilingual lexicon and trying different orderings of these words (the “Shake” of S&BMT) until a sentence is produced (the “Bake” of S&BMT) that satisfies all syntactic constraints. Consider the following case for English/Dutch, which is analogous to Example 11 given earlier.

Example 33 Head-switching Divergence E: John enjoys swimming D: Jan swemt graag “John swims likingly” The statements of equivalence in the bilingual entries for the words used in this example are spelt out as follows:

Example 34 Bilingual Entries fur Head-switching Divergence (i) X E & X E = X q (X, cite) = enjoy (XEcite) = prespart (X, cite) = graag ( X , sem index) = (X, sem index) (Xl, sern index) = (X, sem index) (X, sem exp index) = (X, sem exp index) (X, sem ojb index) = (X, sem obj index) (iii) Y E = Y, (YE cite) = swim (Y, cite) = zwemem (YEsem index) = (Y,, sem index) (YE sem agt index) = (YD sem agt index) These bilingual i d e s form the basis of the transfer between the English lexical entries X, (and Xb) and YE to the Dutch lexical entries X, and Y,, respectively. The cite feature uniquely picks out an entry in the dictionary. The sem feature associates a semantic representation with different components of the entry. The first two usages of sem indicate that the semantics of enjoy and the present participial (i.e. the “-ing” form in English) are mapped

CURRENT PARADIGMS IN MACHINE TRANSLATION

33

to the semantics of graag. The sem feature is also used to associate thematic relations (i.e. experiencer and object in Example 34(i); and agent in 34(ii)). The words swim and zwemen are also related through the use of the sem feature. One point to note here is that the two lexical entries in English (X, and Xl,) are related to one lexical entry in Dutch (X,). The relation of Xl, to X, need not be specified in the bilingual rules since this information can be determined from grammatical constraints during translation (i.e. that the present participial morpheme “-ing” must be associated with the verbal argument swim, not with the main verb enjoy). There are also other types of information inherent in the translation pairs that need not be specified in the bilingual rules; in particular, the fact that the equivalent tense morphemes (pres) occur on non-equivalent stems (enjoy and zwemen) follows immediately from the mechanics of generation. The idea behind this approach is that, once the bilingual elements correctly identify the indices of the lexical entries, the S&BMT algorithm has the job of “combining” these elements. Translation equivalence is stated between bags of lexical constituents. For example, the full bags for the source- and target-language sentences given above in Example 33 are the following:

Example 35 (jan,pres,zwemen,graag} = { john,pres,enjoy,prespart,swim] The relation between the constituents in those bags need not be explicitly stated in the lexicon since these can be determined from the grammatical restrictions of the two languages. The benefit of this design is that the bilingual lexicographer need only specify contrastive knowledge between the two languages; the monolingual grammars used for parsing and generation take care of the rest. The creators of this design have proposed that the bilingual mappings are restricted enough to allow for the possibility of automated acquisition of bilingual correspondences from aligned corpora (see [22,224]). A disadvantage to this approach is that, as described in Example 35, SBrBMT generation is an NP-complete problem. Thus, there is no tractable general algorithm for generating within the S&BMT framework. However, it is possible to impose restrictions on the target-language bag which forms the input to generation. For example, heuristic control might be provided from the structure of the source language. Brew has shown that a heuristic approach based on constraint propagation provides considerable improvements in practice. In addition, refinements have been proposed in [77, p. 3651 for handling translation ambiguity.

34

BONNIE J. DORR ETAL.

5.2

Non-linguistic-based Paradigms

In the past few years, researchers have investigated MT paradigms that are not based on linguistic theories or even linguistic properties of language. This investigation has been made possible by the rapid advances in computational power and the availability of machine-readable dictionaries and monolingual and bilingual text corpora. The approaches all depend on the existence of large text corpora which are used either for training data or databases of existing translations. This section describes some of the recent research in non-linguistic-based paradigms.

5.2.1 Statistical-based M T (SBMTI The production of translations based on statistical prediction techniques depends heavily on statistical analysis of bilingual parallel corpora. While there were some early investigations [117] of the SBMT approach, the modern efforts were initiated by IBM in 1988 in the Candide French-English Machine Translation Project [37, 38, 39, 411. Additional investigations of SBMT have been reported in [49, 57, 91, 127, 137, 159, 2051. SBMT was derived from speech processing techniques. In particular, a variant of Bayes' Rule is used to show that the probability that a string of words (T) is a translation of a given string of words (S) is proportional to the product of the probability that a string of target words is a legal utterance in the target language and the probability that a string of words in the source language is a translation of the string of words in the target language. That is:

Example 36 P(T 1 5') - P ( T ) * P (S 1 7') If the right-hand probabilities are known, the translation is obtained by choosing T such that the left-hand probability is maximized. Obviously, the probabilities for all strings in both languages cannot be known and consequently must be estimated for the approach to be tractable. The usual approach is to define approximate probabilistic models constructed from probabilities that can be directly estimated from existing data. The Candide language model is a trigram model asserting that the probability that any word in a target language (English) string is part of a legal sentence depends only on the two previous words. Knowing these probabilities, an estimate of the probability that a string of words is a legal sentence is the product of all the trigrams in the string. The trigram probabilities can

CURRENT PARADIGMS IN MACHINE TRANSLATION

35

be estimated by counting the frequency of word triples in a large corpus of English text. The probabilistic model underlying the Candide system assumes that the probability that a source language (French) word is a translation of a given English word depends only on the English word. A single translation allows for 0 to 10 French words. It is also assumed that the English equivalents of the French words might be ordered differently in the target sentence. The estimation of these probabilities is considerably more difficult than for the trigrams. In this case a very large bilingual parallel corpus is required.' The problem is to align each English word in a target sentence with the French equivalent(s) in the source sentence.' The approach is to assume values for the alignment probabilities and compute the transfer probabilities of the sentence pairs in the corpus. Depending on the alignment and translation probabilities, a given sentence pair may have several transfer probabilities. Each occurrence of the alignments and translations are counted and weighted by the transfer probability. These weighted counts are used to make a new estimate of the individual probabilities and the process is repeated. This iterative approach converges to a local equilibrium of probabilities and is used to compute P(S T).lo This approach has been tested in the laboratory for French-English MT and produces translations approaching the quality of those from syntactic transfer systems. The grand claim made for this approach is that no lexicons or grammars are used. Everything comes from statistical analysis of corpora. While this is the strength of this approach, it is also the weakness since the corpora must exist. Also the translations are very dependent on the domain of the corpora. An even more serious problem is that the only way to improve the quality of the translation is to improve the accuracy of the probabilistic models of the target language and of the translation process. Unfortunately, this would add many more parameters to the millions required by the simple models described above. Recognizing this difficulty, IBM has applied a number of techniques from classical computational linguistics to form a hybrid system. Morphological analysis, part of speech tagging, syntactic regularization, limited grammatical analysis, and contextual marking are used. Most of these techniques are parameterized with the values derived from analysis of the corpora. Some improvement was

I

' '

Of course, no corpus will be large enough to contain all possible triples and some smoothing method is required to assign a (small) probability to unseen triples. Fortunately French and English versions of the Canadian parliamentary proceedings (called the Hansards) are available. The search for source text words is non-trivial (see [37]). '"The details of this process are outside the scope of this paper (see [50]). Obviously smoothing is required.

36

BONNIE J. DORR ETAL.

achieved; however, they were unable to match the best of the commercial MT systems [226]. IBM continued to work on this system until 1995 when both internal and external support were withdrawn. Two quotes from Yorick Wilks [226] best summarize the impact of this work: Another way of looking at this is how much good IBM is doing us all: by showing us, among other things, that we have not spent enough time thinking about how to acquire, in as automatic a manner as possible, the lexicons and rule bases we use. (p. 144)

Brown ct ul.’s retreat to incorporating symbolic structures shows the pure statistics hypothesis has failed. (p. 145) Since this earlier work on SBMT, there have been improvements to IBM’s original model of translation. Speed, a long-standing issue for statistical methods, has been addressed by techniques involving dynamic programming and structural constraints [228,230]. Another interesting statistics-based MT approach to using statistical techniques to generate MT systems is LINGSTAT, developed by Dragon Systems, Inc. [19, 232, 2331. This work started in 1992 as a translation aid and is a direct substitution system with a simple, hand-generated finite state grammar for Japanese. The English glosses were based on bilingual dictionaries and the grammar was used to assign Japanese phrase attachment. This was quickly seen to be unsatisfactory and a number of statistical steps were taken to provide improved complete translation. The finite state grammar was expanded to a probabilistic context-free grammar (PCFG) and trained on Japanese text. The PCFG was used to provide a gross parse and a lexicalized grammar (also trained on Japanese text) was used to assist with attachments. Hand-generated reordering rules were provided to assist the transfer to English. Further, a trigram probabilistic language model was developed for English to assist in gloss selection. Some improvement was obtained with these changes. These techniques were ported to Spanish/English translations with somewhat better results than for the Japanese. The LINGSTAT project ended in 1995 when support was withdrawn. Interestingly, linguistic-based extensions were planned as a continuation of this work. One extension involved the assignment of case frame categories to the source-language verbs in order to improve the parse. The probabilities of these sub-categories were to be learned by iterative parsing of source text. Additional extensions involved experimentation with extraction of phrase translations from parallel bilingual corpora. While the LINGSTAT group never committed to “pure” statistical MT as did the Candide group, they were strongly committed to statistical training and extraction of more

CURRENT PARADIGMS IN MACHINE TRANSLATION

37

symbolic approaches. This intersection of statistical and symbolic paradigms is relevant to the hybrid techniques discussed in section 5.3 below.

5.2.2 Example- (or Case-/Memory-)based MT (EBMT) Example-based MT (EBMT), first suggested by Nagao [146], emulates human translation practice in recognizing the similarity of a new source language sentence or phrase to a previously translated item and using this previous translation to perform “Translation by Analogy.” Sato and Nagao [ 1831 implemented an experimental EBMT system to demonstrate the translation of simple Japanese sentences into English. Additional investigations of EBMT have been reported in [85,91, 110, 138, 141, 1.54, 1.59, 163, 175, 201,206,207,2341. The basic idea of EBMT assumes a database of parallel translations which is searched for the source language sentences and phrases closest matching a new source language sentence. The translations of the matched phrases are then modified and combined to form a transfer translation of the new sentence. This technique is quite similar to case-based reasoning used in artificial intelligence 11261. A simple match would be an identical phrase (especially in the function words) except for a similar content word. The closeness of the match would be determined by the semantic “distance” between the two content words as measured by some metric based on a thesaurus or ontology. The translation would be the substitution of a translation of the different word in the translation of the best match. The accuracy and quality of the translation depends heavily on the size and coverage of the parallel database. While the database need not be as large as required for SBMT (since the full vocabulary need not be covered), the required coverage of syntactic and semantic divergences results in a size difficult to store and search. Phrasal matching requires at least a rough syntactic analysis of the parallel translations as well as some semantic analysis to determine the closeness of the match. “ In order to avoid matching improper divergences, Collins and Cunningham [52] weight phrasal translations by their frequency in the database. Sentence translation in EBMT requires that in addition to phrasal matching the syntactic structure of the source sentence must be matched with sentences in the database. While full sentence matching has shown some success [%I, most uses of EBMT are restricted to subproblems such as function words [207], noun phrases [ 1821, and prepositional phrase attachment [207]. Nirenburg, Domashnev, and Grannes [152] argue that such analysis defeats the purpose of EBMT and propose substring pattern matching using synonyms and hyponyms.

38

BONNIE J. DORR ETAL.

5.2.3 Dialogue-based MT Dialogue-based MT (DBMT) is a paradigm aimed at a user who is the original author of text to be translated. Systems based on this approach provide a mechanism for entering into a dialogue with the user about the translation [33], thus allowing the user to disambiguate the input text and to incorporate culture-specific stylistic detail for high-quality MT [ 1801. DBMT is similar to EBMT in that a representation of the user’s input text is built and, as it is iteratively revised through dialogue with the user, attempts are made to match the updated representation against those pre-stored in a translation database. Interaction with the user may take place during the translation process or before text is input to the system. In the former, the interaction provides a user-guided online disambiguation mechanism; in the latter, the interaction provides a user-guided revision process that results in text that the system is capable of handling. The first implementation of DBMT was the ENtran project [ 1091 which served as the basis of work at UMIST for British Telecom, [ 111,201, 2141. The system was designed to provide a means for constructing an input text that it is capable of translating, leaving the remaining phenomena to be processed by the user. In an extension to that work [202], a more flexible system was developed for Japanese ATR research. This augmented system acted as an intermediary for the user in a dialogue with a conference office, thus providing a dialogue MT system in two senses (as described in [203]): (1) it enters into a dialogue with the user about translation; and (2) the object of the translation is the user’s contribution to a dialogue. The type of phenomena addressed by DBMT systems is more knowledgeintensive than the divergences described in section 3.1. In [ l l l ] , certain contextual information is encoded in a constrained domain (business correspondence) so that the system can determine the likely intention of the user. Using this information, the user is guided through a series of choice points, thus providing a means for constructing a representation that is offered to the system as a translation candidate. Consider a case where the user has produced a text that is analyzed as two representations.

Example 37 (i) complain ( X I ) a g e n t ( X2 g o a l ( X 3 recipient (ii) not-receive ( X I )agent ( x2 )goal ( x3 1 source

The system has pre-stored knowledge of a relation between complaint and not-received; the user’s intention is thus deduced to be part of a “wrong order” or “faulty goods” context, in which the writer and addressee are assumed to be related. This information is presented to the user in

CURRENT PARADIGMS IN MACHINE TRANSLATION

39

template form as a translation candidate. Such templates may be further embedded in additional templates, which are then used as the basis of novel textual expressions. Somers [203] summarizes this work as follows: This is an interesting development away from the current situation where the MT system makes the best of what it is given (and cannot really be sure whether or not its translation is good) towards a situation where quality can be assured by the fact that the system knows what it can do and will steer the user to the safe ground within those limitations. (p. 241)

DBMT has been used primarily for small domains such as the case given above. For a larger domain, the required amount of information would be too large to store and search. Similar observations have been made for the KBMT and EBMT paradigms described above.

5.2.4

Neural Network-based MT INBMT)

Experiments have been done with neural network technology for such MT functions as parsing [ 1071, lexical disambiguation [95], and learning of grammar rules. The incorporation of neural networks and connectionist approaches into MT systems is a relatively new area of investigation [ 1031. Most recently, Castaiio et al. [48] have run some tests with very small vocabularies (about 30 words) and simple syntax. Handling large vocabularies and grammars dramatically inflates the size of the neural networks and the training set, as well as the training time. In addition, dealing with word sequences requires an explicit representations of time, further complicating the neural network representation. McLean [141] uses neural nets to find similar sentences in an EBMT system. But again, a small vocabulary (30 words) and short sentences are used. It is not clear that this approach can be extended to existing EBMT systems. In contrast with the other approaches described in this paper, no realistic MT systems have been built based solely on neural network technology. This technology is thus more of a technique than a system approach.

5.3 Hybrid Paradigms In the previous section on non-linguistic-based paradigms it was mentioned that many of those paradigms had difficulty with some aspects of the MT process. For example, SBMT does not handle long-range contextual dependencies and EBMT has difficulties with complex sentence structure. It was quickly recognized that these non-linguistic paradigms could be combined with linguistic paradigms to exploit the strengths of each, [6,44, 85,

40

BONNIE J. DORR ETAL.

91, 121, 130, 154,220,2291. The hybrid paradigm involves a mixing of MT paradigms (as well as mixing of the MT architectures). The usual approach is to use linguistic methods to obtain parses of the source text and to use statistical or example techniques to resolve dependencies and phrasal translations [85]. Statistical trigram target language models have been used for lexical selection [42]. Statistically generated decision trees have been used to insert English articles into article-free translations of Japanese text [ 1221. The Pangloss system [156] is a hybrid of both MT paradigms and MT architectures.

6. Evaluation of MT Systems The evaluation of MT systems is also an active area of research. Once an MT system or portion of an MT system is built, how does one evaluate whether it is working correctly and whether it is a promising approach with which to continue? As noted in Hutchins [loll, it is clear that fully automatic high-quality translation is no longer the current goal of most MT experts. In fact, it is expected that revision is required for all translations, whether done by humans or computers. Thus, in order to decide what the evaluation criteria for a machine translation system should be, we must first determine what the intended use of the MT output will be, and then decide whether the output is satisfactory for this purpose. Hutchins argues that “There can be valid uses of poor quality output in unedited form if it is produced quickly, cheaply, and is not intended for publication. If better quality is required then collaboration of man and machine is essential” [101, p. 3031. Given that “perfect” translation is not within our grasp now, if ever, we still need to decide how we can judge whether the output is high quality or low quality. Hutchins claims that the concept of good quality MT output is an elusive concept. As observed by Van Slype [216] it is difficult to find an objective measure of any type of translation, machine-aided or otherwise. (In fact, there is no quality control metric for human translators.) In this section, we will first briefly discuss why the evaluation of translations is so elusive and then describe current solutions to evaluation of translations and MT systems. We do this by first outlining the various approaches that can be taken for defining evaluation criteria and then the techniques that can be applied within these approaches.

6.1 Evaluation Challenges

NL applications, such as MT, have some unique problems that must be accounted for when doing evaluations. The biggest problem with evaluating

CURRENT PARADIGMS IN MACHINE TRANSLATION

41

NL applications is minimizing the subjectivity that, to date, has proven unavoidable due to the nature of natural language itself. Standard software evaluation techniques must be enhanced to allow for the multiple “correct” answers that frequently occur with natural language. It is not clear what constitutes a correct answer especially when dealing with translations. It is because of this that judging the correctness of the output for MT still retains a degree of subjectivity. As pointed out in [15] there are no neighboring disciplines to which we can look for criteria and techniques. There is no general, well-developed methodology for evaluating software systems but as we will see in the next section there are some evaluation criteria that generally apply to software systems. Besides the lack of a general evaluation methodology, there are no clear measures for human translations to guide us and for that matter it is questionable whether MT systems should even be attempting to simulate the behavior of human translators. According to Krauwer [ 1281, the human translator metaphor is questionable because, while the output quality may improve for a short time, it most likely will hit a point of little or no improvement given our current technology. He further suggests that it is better for designers and users to negotiate the specifications for specialized systems. The evaluation can then be based on the specifications. Admittedly, it is still not an easy task to come up with the specifications but it would enable better evaluations. In keeping with the idea of writing specifications for MT systems, we must keep in mind that we need to produce an output that suffices for the intended use (most desirably this would be according to some specification), and we must do this cost-effectively. 6.2

Evaluation Approaches

The approach one takes when evaluating software systems (in general) is two-fold: (1) evaluation of the accuracy of the input/output pairs; and (2) evaluation of the architecture of the system and the data flow between the system components. The former (external) view of software evaluation is called “black-box’’evaluation, and the latter (internal) view is referred to as “glass-box” evaluation [ 1681. Black-box evaluation covers engineering issues such as reliability, productivity, user learnability and user friendliness. Glass-box evaluation also considers reliability (at the component level) as well as maintainability, improvability, extendability, compatibility, and portability. Black-box evaluation, in the case of MT, tends to focus on evaluating the translation quality of the output. Essentially it is an attempt to measure the acceptability of the translation to users. To produce the most objective

42

BONNIE J. DORR ETAL.

measure possible, a standard test-suite of input/output pairs should be established for judging whether the system is performing “correctly” or not and whether it will be cost-effective. In light of the above discussion, this is a very costly undertaking and has yet to be satisfactorily accomplished in any evaluation of an MT system. Another difficulty in applying a black-box evaluation approach is the number of dimensions along which MT developers must limit their systems. These systems can be thought of as shells that are customized to apply to a particular domain, language pair, and type of text. The evaluation criteria (i.e. how well does it translate these texts) must also be limited along the same dimensions, but there is no common range among the systems. Because of this lack of commonality, some systems will need to be customized for the chosen ranges in order to do comparative evaluations. Comparative evaluations would be the goal for users looking to purchase an MT system. Researchers are also interested in comparative evaluations to determine the effectiveness of their MT paradigm or micro-theory. However, the most useful information in this case tends to result from glassbox approaches to evaluation. The glass-box approach attempts to evaluate the system’s internal processing strategies to measure how well the system does something. According to the ideas for evaluating NLP systems [168], this type of evaluation should include a determination of the system’s linguistic coverage, and an examination of the linguistic theories used to handle the linguistic phenomena. Determining the linguistic coverage means testing what linguistic phenomena are handled and to what degree. The examination of the linguistic theories used includes how closely these theories were followed in the implementation and noting what modifications had to be made to the theories. In addition, the performance of the system’s various modules must be examined and the evaluation of each of these modules should be treated as individual black-box evaluations. Under the glass-box evaluation approach, techniques for measuring improvability have received the most attention. Considering these basic evaluation approaches, what then are reasonable and useful evaluation criteria for MT systems? There are a number of dimensions along which one can make a judgement of the quality of MT output. Carbonell ef at. 1461 enumerate the following external evaluation criteria:

(1) Sernantic invariance: is the “meaning” of the source text preserved in the target text? (2) Pragrizatic irzvariaizce: is the implicit intent or illocutionary force (e.g. politeness, urgency, etc.) of the source text preserved in the target text?

CURRENT PARADIGMS IN MACHINE TRANSLATION

43

( 3 ) Structural invariance: is the syntactic structure of the source text preserved in the target text? (4) Lexica2 invariance: is there a one-to-one mapping of words or phrases from source to target texts? ( 5 ) Spatial invariance: are the external characteristics of the source text, such as length, location on page, etc. preserved in the target text? Semantic invariance is today a more dominant criterion (in contrast to the early days when MT systems primarily sought to preserve lexical invariance). In general, MT systems currently seek to preserve meaning and style. l2 Other researchers argue that, in order to determine which criteria are important in evaluating an MT system, we must first know what type of text we are translating. In [ 1471, the criteria for evaluation are determined on the basis of a classification of the different types of text that are to undergo transformation into a foreign language. For example, if we are translating poetry, we would want to preserve pragmatic invariance, whereas if we are translating technical and scientific material, we would want to preserve semantic, lexical, and possibly spatial invariance. If translation is to be confined to technical and scientific matter, then the text is generally from very narrowly defined fields that restrict the lexicon and grammar and constitute a sub-language. In this case full “understanding” is less likely to be a necessity since the set of constructs is bounded and the vocabulary is limited; thus, a small set of simple mappings may be used. On the other hand, translating free-text is a much harder problem than that of translating texts that are restricted to a particular sublanguage. In order to make an evaluation of a system that is intended to translate free-text, we need to look at the degree to which a machine translator might make mistakes if we are lenient with our “understanding” requirement. We can then decide if it is possible to get around these mistakes without adding a high degree of “understanding.” Van Slype [216] (quoted from Hutchins) offers additional evaluation criteria for black-box approaches to evaluation and has identified a number of metrics for evaluating the degree of success of an MT system: (1) (2) (3) (4) (5)

Intelligibility of output text, e.g. via readability scales. Fidelity to the SL original, e.g. via measures of information transfer. Acceptability to recipient of translation. Time spent in revision (post-editing). Number of errors corrected, and type.

l 2 Preserving style is a questionable practice considering the findings of work in multilingual generation [170].

44

BONNIE J. DORR ETAL.

A paper by Slocum and Justus [199] addresses some of the engineering measures described under the black-box evaluation approach as well as some of the measures described under the glass-box evaluation approach in addition to the usual focus on improvability. The criteria derived from this paper are:

(1) Cross-linguistic applicability: the MT system must support several human languages. This means the system must be easily extensible. In particular, adding coverage for a new language should be facilitated. ( 2 ) Perfornzance: the MT system must support implementation on a parallel architecture, or perform decently on non-parallel machines. (3) Eased acquisitioiz: the MT system must be built on top of syntactic, semantic, and lexical information sources that are easily updated, perhaps automatically. (4) Unifornz aizalysis and synthesis: the MT system should have rules that are used during both types of processing. ( 5 ) Fault-tolerant, fail-soft: the MT system should have adequate error recovery and it should be able to provide an understandable explanation for failures (e.g. misspelled word, unanalyzable syntax, etc.). (6) Suitability .for speech inputloutput: the MT system should provide support for speech processing (e.g. it should provide for the possibility that word boundaries are often ignored in speech). Additional evaluation criteria provided in a paper by King [ 1181 that also fall under the black-box and glass-box approaches to evaluation are: (1) Pructicality: the MT system must have fall-back mechanisms. The

interface structure must include information on the valency boundedness of constituents, on their surface syntactic function, etc. so that when no semantic interpretation is available, the system can provide some translation rather than none at all. (In the worst case, the translation would be word-for-word.) (2) Collaboration: the MT system should be built by means of joint teams that define and construct the sharable components (e.g. the interlingua or the transfer rule language). There must be an agreement to use a common basic software, that manipulates an agreed upon data structure. (3) Extensibility: the MT system must provide the ability to add new language pairs at any time without having to rewrite the pre-existing system. Summarizing all the criteria given above into a final list is difficult since the criteria need to be further adapted to the particular type of text that is

CURRENT PARADIGMS IN MACHINE TRANSLATION

45

being translated. This comment notwithstanding, we consider the following criteria to be crucial in the evaluation of MT systems:

(1) Intelligibility: must be readable and reasonably “natural.” ( 2 ) Fidelity: must preserve certain characteristics of the source text (e.g. must support structural invariance). ( 3 ) Acceptability: must be satisfactory for intended purpose (e.g. must conform to properties of relevant sublanguage). (4) Speed: must have reasonable run-time. ( 5 ) Cost: must be cost-efficient. (6) Time spent revision: must require as little post-editing as possible. (7) Number of errors: must not have an unreasonably large number of errors (e.g. every other sentence on the average). (8) Cross-linguistic applicability: must support several languages in a uniform fashion. (9) Extensibility: must provide ability to easily add new languages. (10) Uniform analysis and synthesis: must use same data structures for both parsing and generation. (1 1) Fault-tolerance: must handle errors gracefully, and must provide some translation rather than none at all. (12) Collaboration: all languages must operate on basis of common software and data structures. Some of these evaluation criteria require further definition depending on the intended purpose of the MT system. For example, what is “natural” in one domain may not be “natural” in another domain. In addition, various measures must be specified: “reasonable run-time” might be different for on-line processing v. off-line processing; “cost-efficient” might mean one thing to one end-user and something else to another; and “unreasonably large number of errors” might mean every other word in one domain and every other sentence in another domain. Also, the “graceful” handing of errors depends on what purpose the system serves (e.g. whether the system is intended to operate interactively as in a tutorial situation, or whether the system is intended to operate as a batch job). In conjunction with the intended use of an MT system is the notion of the different purposes behind doing an evaluation. An end-user of an MT system will approach evaluation differently from a developer or a researcher. Not only will the most appropriate techniques for these different types of evaluators differ but so will the goals they have for doing an evaluation, Researchers typically work with test-suites since usually they are focusing on one aspect of the whole problem of translation at one particular time (e.g. a theory about translation, an architecture, or a technique for handling a difficult phenomena

46

BONNIE J. DORR ETAL.

within a particular theoretical framework). A developer will use test-suites to ensure modifications have not affected sentences that were previously correctly translated (regression testing) as well as whether the targeted sentences that motivated the modification are now correctly handled by the change. An end-user will use test-suites to comparatively evaluate MT systems when considering a purchase and will also use test-suites after acquiring a system and arranging for system extension in lexical or grammatical coverage. A final, frequently overlooked point is that the MT paradigm has a significant impact on the choice of evaluation criteria [ 151. Today’s statisticalbased and example-based paradigms should not be expected to rate as well on fidelity, intelligibility and acceptability, for example, as the linguisticbased paradigms. On the other hand, we would expect the linguistic-based paradigms to be less fault-tolerant. This idea meshes well with the intended use of an MT system. A statistical-based approach would be expected to provide rough translations more cost-effectively.

6.3

Evaluation Techniques

Test-suites are often proposed as a way to determine a system’s linguistic coverage and can be useful for both black-box and glass-box approaches to evaluation. When one is more interested in the types of errors produced by a system than the total number of errors, test-suites are most often the technique used. To construct a test-suite one must attempt to predict the linguistic constructions and legal combinations of these constructions that will be encountered in the input. In addition, it is important to include illegal constructions as well since an inability to recognize the construction as illegal can result in poor quality output as well. So a test-suite could contain sentences with different verb forms and auxiliaries or various complex sentence structures such as sentences with restrictive or non-restrictiverelative clauses, or conjoined clauses. However, determining the appropriate constructions to include in a testsuite is difficult and the size of the test-suite grows quickly. To bound the problem, the test-suite developers must know what linguistic phenomena are of greatest importance to the users and be well versed in linguistics and the languages of interest [120]. Test-suites have also been proposed by King and Falkedal [ 1201 as a way to test the improvability of an MT system. Improvability tests assume that either the evaluator is working closely with the developer or that the evaluator is able to modify the system. The caveats mentioned earlier on bounding the problem, apply here as well. The simplest use of a test-suite is to run the system on it and record the successes and failures. This then gives developers and perhaps potential end-

CURRENT PARADIGMS IN MACHINE TRANSLATION

47

users an idea of what constructions are problematic as well as an idea of the overall progress being made in the development of the MT system. However, unless a clear record is made of what constructions and interactions the input is intended to test, one can only get an indication of the overall progress in development. The developer will then have to spend time examining each failure and determining exactly what went wrong in the system. Some problems with test-suite construction as noted in Arnold et al. [ 151 are : (1) The projection assumption: the assumption is that it is possible to determine the behavior of the system on the real input from the behavior on the test-suite. The test-suite may not include all of the phenomena encountered in a real input. (2) Weighting of phenomena: a test-suite does not indicate the weighting of the phenomena according to what one would expect to encounter in the real input. So the inability to handle a large number of low frequency phenomena will lead one to expect a worse performance than if there is a problem with one high frequency phenomenon. ( 3 ) It is necessary to take source and target languages into account. For example, “John went into the house” would test past tense and location prepositional phrases whereas “John entered the house” would test past tense as well as structural divergences in the case of Spanish.

A final technique used in evaluation is to collect the output of the system and evaluate it. While it may be difficult to get representative test material, this tends to be the most reasonable means that end-users have today for evaluating MT systems. One approach for evaluating the output is to mark and categorize the errors. Another approach is to rate the output according to intelligibility and fidelity scales. In both cases this evaluation is done by hand and tends to be expensive, tedious, error-prone, and subjective. Marking and categorizing errors requires that a category of errors be defined beforehand and a score associated with each. The weighting of the errors tends to be subjective unless something such as the frequency of the construction in the real input is the basis of the scoring. Likewise, the rating of intelligibility and fidelity requires a rating scheme and will be subjective. In addition, this type of rating requires many test inputs and evaluators to get a statistically significant result. l 3

’’

It might be useful to consider a test such as the Kappa coefficient of agreement [47] as used in discourse annotation research for assessing inter-coder reliability. In this case, one would be testing inter-evaluator reliability. By establishing such a measure, the evaluators would learn what improvements are needed in the evaluation scheme to get consistency among the evaluators. Once reliability is achieved, one evaluator is all that should be necessary. However, establishing an interpretation of the Kappa measure is not without its problems [56].

48

BONNIE J. DORR ETAL.

Test-suite evaluations can also be time-consuming, tedious, and errorprone. A number of tools are being researched to help with test-suite evaluation. Shiwen [ 1951 has a tool for scoring test-suite results. This tool provides a language to associate input strings with patterns representing acceptable outputs and scores. Arnold er al. [ 121 describe a tool for test-suite construction which uses a simple grammar to generate a test-suite. The tool described by Nerbonne et al. [lSO]records in a relational database the phenomena tested by a particular construction so that a test-suite can be built from this database by indicating the grammatical constructions that need to be tested.

6.4 Examples of Machine Translation Evaluations We have examined the task of MT system evaluation from three different perspectives: (1) end-user evaluation; (2) developer’s evaluation; and (3) researcher’s evaluation. Each evaluation perspective is described in turn.

6.4.1 End-user Evaluation We will look at two examples of end-user evaluation to illustrate the different depths of evaluation a potential customer of an MT product might undergo. The first example is the evaluation methodology of the Union Bank of Switzerland (UBS) [ 2 , 3 ] which assessed MT products on behalf of end-users with well-defined requirements. The second is an evaluation methodology of our Mitre study, conducted on behalf of a wide range of end-users in the US government with disparate requirements [112]. In the case of the UBS evaluation, the well-defined requirements pre-selected a smaller candidate pool of MT products, making an in-depth evaluation more feasible. In the case of the Mitre evaluation, the end-users’ requirements were open-ended in that they were interested in all language pairs and all domains of interest. The result was that no MT system could be excluded from the evaluation; thus, the Mitre evaluators undertook a higher-level evaluation to narrow down the possible candidates. Both evaluations considered operational and economic issues. For example, both examined the costs associated with adapting the system to the current work environment and the types of text that needed to be translated. In addition, both took into account the quality of support provided by the MT system. While the UBS evaluation answered these questions by bringing the systems in-house and adapting them enough to do testing, the Mitre evaluation attempted to determine this by means of a survey questionnaire. The difference in the approaches was a matter of time and cost.

CURRENT PARADIGMS IN MACHINE TRANSLATION

49

Another area considered by both studies was the evaluation of translation output. Both used representative input texts, instead of collections of unrelated sentences, that were customized to test particular features of the system. Both evaluations acknowledged the need to test the system on what it had been customized to do. In the UBS evaluation, the system was customized to handle the input texts. In the Mitre evaluation, test-suites were selected for each system; these were tailored for the domain, coverage, and end-user needs for each system. The studies were distinguished by the metrics used for assessment of the quality of MT output. The UBS study categorized the complexity of the input test sentences on a scale of 1 to 4 and scored the mistakes in the raw translations based on: (1) whether the error was easily corrected; (2) the degree to which the error interfered with understanding; and (3) whether the error violated basic grammatical structure. In addition, dictionary errors and failures to translate were counted separately. All the criteria (linguistic capabilities, technical environment, and organizational changes) were weighted according to user requirements; a final rating was designed for each system evaluated. The Mitre study evaluated output quality by comparing it to human-produced translations; multiple evaluators were used for each test case. To lessen the influence of possible exposure to the “good” translation in rating the meaning invariance, the evaluators first paraphrased the meanings before comparing the MT output to the human-produced translation. l4 After paraphrasing, the evaluators completed the evaluation by comparing it to the human-produced translation. With the widely ranging end-user requirements (from rough translations to publication-quality translations), categorization of the types of errors was impractical. Thus, the criteria results were listed separately so that each end-user group could weight the criteria according to their specific needs. End-users also have a role to play in the evaluation of an MT system once it is purchased and customized by the developer. Although the UBS evaluation touches upon this situation to a small extent-since they customized the system before their selection evaluations-the example in the next section discusses this from the perspective of a longer-term customization process.

6.4.2 Developer‘s E valuati0 n Typically the end-user and the developer of an MT system must develop an ongoing relationship in order to customize the system. During this longterm customization process, techniques for evaluating the progress of the l 4 The rationale was that if the “answer” was present it would be easier to see the MT system’s output as being closer in meaning to the human output, i.e. there might be a false sense of understanding even when something was badly translated.

50

BONNIE J. DORR ETAL.

customization must be established. Moreover, the integrity of the system must not be compromised by incremental modifications, e.g. during regression testing. One example that addresses such considerations is the evaluation procedure used by B’VITAL and SITE for their CAT system [177]. Although the procedure was not fully deployed to the extent planned at the time of this writing (i.e. only 100 pages of the 5000 intended pages were tested), it serves as a useful example since it is representative of what many developers reportedly do according to the initial Mitre survey. B’VITAL’s procedure involves both the end-user who, as post-editor, reports output problems and the developer who, as linguist and lexicographer, modifies the grammar and the dictionary. First a balanced corpus of pages from technical manuals is selected and run through CAT. The posteditor revises the system output and records the time required to do so. This gives a measure of efficiency of the system. Presumably as the customization progresses, the efficiency improves. For a random sampling of the test corpus, the post-editor also fills out a detailed problem report, categorizing the types of problems encountered by counting surface form errors. In addition, the post-editor assesses the clarity of the incorrectly translated sentences and gives the developer the context needed to reproduce the problems (i.e. input, MT output, and the expected output). Next, the developer reviews each problem and either corrects the problem or categorizes the reasons it could not be corrected (e.g. a phenomenon that is rare, low priority, or too complex). Categorizing the reasons for which problems are left uncorrected provides feedback to the end-user on the limits of the system, frequently resulting in a refinement of user requirements. For the problems that are corrected, the time required for the repair is recorded along with the type of modification needed (e.g. dictionary or grammar modification). Keeping track of the repair time gives an indication of how difficult the system is to customize. At the end of the procedure, once the entire test corpus has been translated and corrections implemented, a subset of the corpus is again tested as a higher-level form of regression testing. Developers also undertake a type of evaluation that does not directly involve the end-user when the system is still being built or when some aspect of it is changed. This evaluation typically relies on test-suites and overlaps to a large extent with the researchers’ evaluation, the subject of the next section.

6.4.3 Researcher’s Evaluation MT evaluation in the research community focuses on the handling of different linguistic phenomena by various MT systems. Mitre’s later evaluation

CURRENT PARADIGMS IN MACHINE TRANSLATION

51

work [173,235] is a current example of such an evaluation. This work is one of several contributions in the 1998 AMTA Workshop on Interlinguas [7] which examined the translation of a text from the UNESCO Courier [ 1671 into multiple languages. The objective of the workshop was to determine how different aspects of the text would be represented using an Interlingual Representation. l5 Specific challenges addressed by the group were the handling of basic predicate-argument structure, noun phrases/referents, proper nouns, prepositional meaning, non-literal language, temporal relations, textual organization, lexical divergences, syntactic divergences. The more general issue examined in the evaluation work of [235] was whether an interlingua would improve the system output over that of a transfer design. Consider the following sample bilingual text examined in the workshop:

Example 38 (i) E: ACCION International is a US-based private non-profit organization that currently provides technical assistance to a network of institutions in thirteen countries in Latin America and six cities in the United States. Its network of eighteen independent organizations in Latin America has lent over $1 billion to microenterprises in the last five years, in loans averaging less than $500. (ii) S: ACCION Internacional es un organism0 privado sin fines de lucro con sede en Estados Unidos, que brinda actualmente asistencia ttcnica a una red de establecimientos de microcrCdito en trece paises de America Latina y seis grandes ciudades de Estados Unidos. En America Latina la red abarca dieciocho organizaciones independientes que desembolsaron mil millones de d6lares en 10s dltimos cinco aAos en forma de prtstamos de una cuantia media inferior a quinientos d6lares. Two transfer-based commercial MT systems were used to translate the English excerpts above to Spanish: (1) Logos, [190, 191, 1921: and (2) Systran [87, 188, 1891. The following results were produced: l6

Example 39 (i) Logos: ACCION-organizaci6n privada basada no beneficio que proporciona en la actualidad la asistencia ttcnica a una red de l5 This text was available in 13 languages. Our examples focus on the English and Spanish versions of the text. I6In [235],Globalink [99, 133, 1741 was used in place of Logos, and the translation direction was Spanish to English. Despite this difference, the findings in that work were similar to those described here.

52

BONNIE J. DORR ETAL.

instituciones en trece paises en la America Latina y seis ciudades en 10s Estados Unidos. Su red de dieciocho organizaciones independientes en la America Latina ha prestado m8s de 1 mil millones de dblares a microenterprises en 10s cinco Cltimos aiios, en prkstamos que promedian menos de 500 dblares. (ii) Systran: ACCION intemacional es una organizacih no lucrativa privada de US-based que proporciona actualmente a asistencia tecnica a una red de instituciones en trece paises en Am6rica latina y seis ciudades en 10s Estados Unidos. Su red de dieciocho organizaciones independientes en America latina ha prestado concluio $1 mil millones a 10s microenterprises en 10s cinco afios pasados, en 10s pr6stamos que hacian un promedio menos de de $500. Overall, the translations into Spanish were readable by a native speaker, but not entirely grammatical and not at all similar to the version produced by the human speaker. For example, the phrase provides technical assistance to a network of institutions is translated as proporciona en la actualidad la asistencia te‘cnica a una red de instituciones (“supplies at the present time the technical assistance to a web of institutions”) by Logos and proporciona actualinente a asistencia te‘cnica a una red de instituciones (“supplies presently to the technical assistance to a web of institutions”) by Systran. Neither of these corresponds exactly to the human-generated Spanish version briiida actualmente asistencia tkcnica a una red de establecirriientos (“offers currently technical assistance to a web of establishments”). In particular, the mapping between provides and brindar appears to be missing in these two systems. This hypothesis was further tested by translating the Spanish version of the clause, que hrinda actualmente asistencia te‘cnica a una red, and verifying that provides is not the main verb in the target-language sentence. The test was done with Systran and Globalink only since Logos does not translate in the Spanish-to-English direction.

Example 40 (i) Systran: ... that offers currently technical assistance to a network (ii) Globalink: ... that at the moment offers to technical attendance to a network From the translations above, the internal mappings are deduced to be of the following form:

Example 41 Transfer Mapping for Systran brindar(Y) 4offer(Y)

CURRENT PARADIGMS IN MACHINE TRANSLATION

53

Example 42 Transfer Mapping for Globalink brindar(Y) -+ offer(to(Y)) From these we see three things: 0

0

0

The verb provide is not an English equivalent of brindar in either system. l7 The phrase to a network is viewed as a modifier that is taken to be outside of the predicate-argument structure of either verb. In the Globalink translation, the direct object of the verb is taken (erroneously) as the beneficiary of the main verb as in “toast to the bride,” which forces two prepositional phrases to be generated.

Given that an interlingual representation is designed to accommodate complex predicate-argument structure mappings, these examples provide evidence that an interlingual approach would improve the system output over that of a transfer design. Even a simplified form of interlingua, such as one based on thematic roles [70],provides the basis of a more systematic mapping into the target-language. l 9 For example, the following thematicrole representations are used for the English and Spanish verbs used above.

Example 43 (i) provide: [ag th goal (to)] (ii) offer: [ag th ben(to)] (iii) brindar: [ag ben, ag t h goal( a)]

A thematic-role analysis of the English sentence containing provide would not result in a beneficial reading of technical assistance because, even if brindar were chosen in the target language, the thematic specification forces the direct object into theme (th)position; thus reserving the remaining argument for goal (goal) position. Unlike the transfer case, this alignment of thematic information allows to a network to be analyzed as an argument rather than as a modifier and the verb brindar is selected as a possible translation candidate. Similarly, a thematic-role analysis of the Spanish sentence l7 Interestingly, Spanish-speaking informants at the AMTA commented that the source text is, in fact, awkward-that the verb brindar is used in a less conventional context. Perhaps this evaluation acts as somewhat of a diagnostic for acceptability of the human-generated input. We set aside this possibility for the purpose of this discussion, but see related work on DBMT (above) in which the user’s input is iteratively revised through interaction with the translation system. Spanish-speaking informants indicated that brindar translates most typically to the verb

’’

toast.

“Thematic roles in this system are taken from a standardized set, e.g. Agent (ag), Theme (th), Source (src), Goal (goal), Location (loc), Beneficiary (ben) [104].

54

BONNIE J. DORR EJAL.

containing brindur would allow either offer or provide to be selected, with a preference for the latter because of the alignment of the three roles. In either case, this analysis differs from that of the transfer approach: technical assistance is not associated with a spurious preposition because the only argument that allows this preposition has been “saturated” by the phrase a network. This evaluation has demonstrated the potential benefit of adopting interlingual over transfer. However, one must take care to recognize the potential risks when making such an assessment. As described in [97], a deeper analysis runs the risk of prohibitive storage and access costs as systems are scaled up for broader coverage. On the other hand, lexical-transfer systems provide lower-quality translations and require a great deal of human assistance. A more recent trend is to prioritize the development of systems that exploit the strengths of different approaches or that vary in functionality according to the task at hand. This trend is associated with increasingly higher recognition of the importance of establishing the requirements of the consumer of the translation output [204, 2171. Evaluations metrics are, correspondingly, tuned to the objectives of the final application [73, 1621.

7. Summary and Conclusions In this survey we have presented the major challenges for MT in the areas of linguistics, operations, system and translation evaluation, acquisition of linguistic and domain knowledge, and the utilization of the empirically available linguistic and domain knowledge in bilingual, and source and target language corpora. To summarize the linguistic challenges: MT research must deal with the unanswered questions of how much understanding is enough to deal with the various ambiguities that arise in natural language, whether an assumption of pragmatic invariance will be enough to generate a useful text, and how one can best deal with the various linguistic divergences between languages. Building general core MT systems and tools that can be easily extended to other languages is another of the major challenges. In conjunction with this is the issue of how to acquire and maintain all of the information that will adapt a general core MT system to particular language pairs and translation needs. This in turn influences the basic approach of the general core MT systems. As for the system and translation evaluation challenges, MT research must find ways to evaluate the efficiency, maintainability, portability, and quality of translation output relative to user needs. We expect to see more research on comparative evaluation

CURRENT PARADIGMS IN MACHINE TRANSLATION

55

approaches as well as on the evaluation of working prototypes in actual translation settings. Since large amounts of knowledge are necessary (but not sufficient) for better quality results and broader coverage, this has led to research on methods for acquiring and utilizing information more easily. The traditional rationalist approach is to try for high-quality translations first and then to find ways to broaden the coverage while the empiricist approach is to try for broad coverage first and then upgrade the quality of the result. One predicts then that hybrid approaches might provide the next step forward for advances in machine translation research. Indeed, some research is moving in this direction, and current trends indicate a heightened awareness of the utility of multi-engine approaches. Over the next several years, advances in efficiency and portability are expected as researchers discover more about cross-linguistic generalizations in language processing and develop efficient techniques for utilization of existing knowledge resources. Moreover, synergism between systems and humans is expected as technologies are combined to enhance MT throughput and/or quality. Finally, as the need for international access to multilingual text continues to grow, advances in MT technology will become increasingly more important and, correspondingly, the utility of MT paradigms will be measured in terms of their impact with respect to a wide range of cross-language applications. ACKNOWLEDGMENTS The first author has been supported, in part, by DOD Contract MDA904-96-C-1250, DARPA/ITO Contract N66001-974243540, Army Research Laboratory contract DAALOl-97C-0042, NSF PFF IRI-9629108 and Logos Corporation, NSF CNRS INT-9314583, and Alfred P. Sloan Research Fellowship Award BR3336. The second author has been supported, in part, by the Mitre Corp, the Center for Machine Translation at Carnegie Mellon University, Mitsubishi Electric Research Laboratory, the National Science Foundation under Grant No. IRI-9314961, an Andrew Mellon Predoctoral Fellowship and the Intelligent Systems Program at University of Pittsburgh. Useful guidance and commentary have been provided by several members of the Laboratories for Computational Linguistics and Information Processing (CLIP) and Language and Media Processing (LAMP) at the University of Maryland. Many thanks especially to Doug Oard, Mari Olsen, Clare Voss, Amy Weinberg, and David Zajic. We are forever indebted to Edna Walker at the University of Maryland, who spent countless hours assisting us in the compilation of the bibliography.

REFERENCES [l] AbeillC, A., Schabes, Y., and Joshi, A. K. (1990). Using lexicalized tags for machine translation. Proceedings of 13th International Conference on Computational Linguistics, Helsinki, Finland, pp. 1-6.

56

BONNIE J. DORR ETAL.

[2] Albisser, D. (1991). Evaluation of MT systems at Union Bank of Switzerland. Proceedings of the Evaluators’ Forum, (Kirsten Falkedal ed.) Les Rasses, Vaud, Switzerland, 21-24 April, ISSCO, Universite’ de Geneve, Geneva, Switzerland. [3] Albisser, D. (1993). Evaluation of MT Systems at Union Bank of Switzerland. Machine Translation, 8(1-2), 25-27. [4] Allen, J. (1998). Lexical variation in Haitian Creole and orthographic issues for MT and OCR applications. Proceedings of Embedded MT Work.ehop,AMTA-98, Langhorne, PA October. [ 5 ] ALPAC ( 1966). Language and Machines: Computers in Translation and Linguistics, Automatic Language Processing Advisory Committee. [6] Alshawi, H., Buchsbaum, A. L., and Xia, F. (1997). A comparison of head transducers and transfer for a limited domain translation application. Proceedings of the 35th Annual Meeting of the Association for Computational Linguistics (ACL-97), Madrid, Spain, 7-12 July, pp. 360-365. [7] AMTA Special Interest Group for Interlinguas. Proceedings of the SIG-iL Second Workshop on interlinguas. AMTA-98, 28-31 October, Langhorne, PA, NMSU, Technical Report MCCS-98-316. Computing Research Laboratory, New Mexico State University, Las, Cruces, New Mexico, 1998. [8] Antona, M., and Tsujii J. (1993). Treatment of tense and aspect in translation from Italian to Greek-an example of treatment of implicit information in knowledge-based transfer MT. Proceedings of the Fifth International Conference on Theoretical and Issues in Machine Translation of Naturul Languages, pp. 131-153. [9] Appelo, L. (1986). A compositional approach to the translation of temporal expressions in the Rosetta System. Proceedings of 11th International Conference on Computational Linguistics, Bonn, Germany, pp. 313-318. [lo] Arnold, D., and Tombe, L. des (1987). Basic theory and methodology in Eurotra. Machine Translation: Theoretical and Methodological Issues, (S. Nirenburg ed.), Cambridge University Press, Cambridge, England, pp. 114-135. [ l l ] Arnold, D., Krauwer, S., Tombe, L. des, and Sadler, L. (1988). Relaxed compositionality in machine translation. Proceedings of the 2nd International Conference on Theoreiical aid Methodological Issues in Machine Translation of Natural Languages. Carnegie Mellon University, Pittsburgh, PA. [12] Arnold, D., Moffat, D., Sadler, L., and Way, A. (1993). Automatic test suite generation. Machine Translation, 8(1-2), 29-38. [13] Arnold, D., and Sadler, L. (1990). Theoretical basis of MiMo. Machine Trunslation, 5(3), 195-222. [14] Arnold, D., and Sadler, L. (1992). Rationalism and the treatment of referential dependencies. Proceedings of the 2nd International Conference an Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 195-204. [15] Arnold, D., Sadler, L., and Huinphreys, R. L. (1993). Evaluation: an assessment. Machine Translation, 8(1-2). 1-24. [16] ATLAS 11: A machine translation, system for multilingual translation/Japanese to German. Sales document from FUJITSU, 1986. [ 171 Ballad, B., and Stumberger, D. E. (1986). Semantic acquisition in TELL Proceedings of the 24th Arinual Meeting of the Association for Coniputational Linguistics, pp. 20-29. [18] Bar-Hillel, Y. (1960). The present status of automatic translation of languages. Advances in Coniputers, vol. 1, Academic Press, New York. pp. 91-163. [19] Bamett, J., Cant, J., Demedts, A., Dietzel, T., Gates, B., Hays, E., Ito, Y., and Yamron, J. (1994). LINGSTAT: state of the system. In ARPA Workshop on Machine Translation, Vienna, Virginia, November.

CURRENT PARADIGMS IN MACHINE TRANSLATION

57

[20] Bates, M., and Bobrow, R. (1983). A transportable natural language interface. Proceedings of the 6th Annual ACM SIG Conference on Research and Development in Information Retrieval. [21] Beaven, J. (1992). Lexicalist Unification-Based Machine Translation. PhD thesis, University of Edinburgh, Edinburgh. [22] Beaven, J. (1992). Shake and bake machine translation. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 603-609. [23] Bennett, P., and Paggio, P. (1993). Preference in Eurotra. Studies in Machine Translation and Natural Language Processing, vol. 3. Commission of the European Communities. [24] Bennett, P. A,, Johnson, R. L., McNaught, J., Pugh, J. M., Sager, J. C., and Somers, H. L. (1986). Multilingual Aspects of Information Technology, Gower, Brookfield, VT. [25] Bennett, W. S. (1990). How much semantics is necessary for MT systems? Proceedings of the 3rd International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Larlguages, Linguistics Research Center, The University of Texas, Austin, TX, pp. 261-269. [26] Benoit, J. W., Jordan, P. W., and Dorr, B. J. (1991). Machine Translation Action Plan. Technical report MP-9 1W00023, The Mitre Corporation. [27] Benoit, J. W., Jordan, P. W., and Don, B. J. (1991). Machine Translation Technology Survey and Evaluation Report. Technical report MP-91W00021, The Mitre Corporation. [28] Bergler, S. (1995). Generative lexicon principles for machine translation: A case for meta-lexical structure. Machine Translation, 9(3-4), 155-182. [29) Berwick, R. C. (1991). Principles of principle-based parsing. Principle-Based Parsing: Computation and Psycholinguistics, (R. C. Berwick, S. P. Abney, and C. Tenny eds.), Kluwer Academic Publishers, pp. 1-37. [30] BIBser, B., Schwall, U., and Storrer, A. (1992). A reusable lexical database tool for machine translation. Proceedings of the 14th International Conference on Computational Linguistics, Nantes, France, pp. 5 10-5 16. [31] Boguraev, B., and Briscoe, E. J. (eds.) (1989). Computational Lexicography for Natural Language Processing. Longman, London. 1321 Boguraev, B., and Pustejovsky, J. (1990). Lexical ambiguity and the role of knowledge representation in lexical design. Proceedings of 13th International conference on Computational Linguistics, Helsinki, Finland, pp. 36-41. [33] Boitet, C. (1989). Speech synthesis and dialogue based machine translation. ATR Symposium on Basic Research for Telephone Interpretation, Kyoto, Japan, pp. 6-5- 1-9. [34] Brent, M. (1993). From grammar to lexicon: unsupervised learning of lexical syntax. Computational Linguistics, 19(2), 243-262. [35] Brew, C. (1992). Letting the cat out of the bag: generation for shake-and-bake MT. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 610-616. [36] Briscoe, E. J., and Copestake, A. A. (1990). Enjoy the paper: lexical semantics via lexicology. Proceedings of 13th International Conference on Computational Linguistics, Helsinki, Finland, pp. 42-47. [37] Brown, P. F. (1990). A statistical approach to machine translation. Computational Linguistics, 16(2), 79-85. [38] Brown, P. F., Cocke, J., Della Peitra, S. A., Della Pietra, V. J., Jelinek, F., Mercer, R. L., and Roossin, P. S. (1988). A statistical approach to French/English translation. Proceedings of the 2nd International Conference on Theoretical and Methodological

58

[39] [40]

[41]

1421

[43] [44]

[45] [46]

(471 [48]

[49] [50] [51] [52]

[53] [54]

BONNIE J. DORR ETAL.

Issues in Machine Translation of Natural Languages, Carnegie Mellon University, Pittsburgh, PA. Brown, P. F., Della-Pietra, J., Jelinek, F., Mercer, R. L., and Roossin, P. S. (1988). A statistical approach to language translation. Proceedings of 12th International Conference on Computationul Linguistics, Budapest, Hungary, pp. 7 1-76. Brown, P. F., Lai, J. C., and Mercer, R. L. (1991). Aligning sentences in parallel corpora. Proceedings of the 29th Annual Meeting of the Association for Computational Linguistics, University of California, Berkeley, CA, pp. 169-176. Brown, P. F., Della Pietra, S. A., Della Pietra, J. D., Lafferty, J. D., and Mercer, R. L. (1992). Analysis, statistical transfer and synthesis in machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 83-100. Brown, R., and Frederking, R. (1995). Applying statistical English language modeling to symbolic machine translation. Proceedings of the 6th International Conference on Theoretical and Methodological Issues in Machine Translation, Leuven, Belgium, pp. 221-239. Byrd, R. J., Calzolari, N., Chodorow, M. S., Klavans, J. L., Neff, M. S., and Rizk, 0. A. (1987). Tools and methods for computational linguistics. Computational Linguistics, 13, 219-240. Carbonell, J., Mitamura, T., and Nyberg, E. (1992). The KANT perspective: a critique of pure transfer (and pure interlingua, pure statistics, ...). Proceedings of the 4th Internutional Conference on Theoretical and Methodulogical Issues in Machine Translation, Montreal, Canada, pp. 225-235. Carbonell, J. G. (1987). Knowledge-based machine translation. Tutorial at 25th Annual Meeting of the Association for Computational Linguistics, Stanford University, Stanford, California. Carbonell, J. G., Cullingford, R. E., and Gershmm, A. V. (1981). Steps toward knowledge-based machine translation. IEEE Transactions on Pattern Analysis and Machine Intelligence, PAMI-3(4). Carletta, J. (1996). Assessing agreement on classification tasks: the Kappa statistic. Computational Linguistics, 22(2), 249-254, June. Castano, M. A., Casacuberta, F., and Vidal, E. (1997). Machine translation using neural networks and finite-state models. Proceedings of the 7th International Conference on Theoretical and Methodological Issues in Machine Translation, Santa Fe, New Mexico, pp. 160-167. Chang, J. S., and Su, K. Y. (1993). A corpus-based statistics-oriented transfer and generation model for machine translation. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp. 3- 14. Charniak, E. (1993). Statistical Language Learning. MIT Press, Cambridge, Massachusetts. Chornsky, N. (1986). Knowledge of Language: Its Naiure, Origin and Use. The MIT Press, Cambridge, MA. Collins, B., and Cunningham, P. (1997). Adaptation guided retrieval: approaching EBMT with caution. Proceedings of the 7th International Conference on Theoretical and Methodological Issues in Machine Translation, Santa Fe, New Mexico, pp. 119-1126. Computing Research Laboratory, New Mexico State Univ. The Interactive Tent Translation System User’s Manual (ULTRA). Copestake, A,, Briscoe, T., Vossen, P., Ageno, A., Castellon, I., Ribas, F., Rigau, G., Rodriguez, H., and Samiotou, A. (1995). Acquisition of lexical translation relations from MRDS. Machine Translation, 9(3-4), 183-219.

CURRENT PARADIGMS IN MACHINE TRANSLATION

59

[55] Danlos, L., and Samvelian, P. (1992). Translation of the predicative element of a sentence: category switching, aspect, and diathesis. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 21-34. [56] Eugenio, D. B., Jordan, P. W., Moore, J. D., and Thomason, R. H. (1998). An empirical investigation of proposals in collaborative dialogues. ACLICOLING 98, Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics (joint with the 17th international conference on computational linguistics), Montreal, Canada. [57] Doi, S., and Muraki, K. (1992). Translation ambiguity resolution based on text corpora of source and target languages. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 525-53 1. [58] Doma, M., and Emele, M. C. (1996). Semantic-based transfer. Proceedings of the 16th International Conference on Computational Linguistics, Copenhagen, Denmark, pp. 316-321. [59] Doma, M., Frank, A., van Genabith, J., and Emele, M. C. (1998). Syntactic and semantic transfer with f-structures. Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics (ACL'98), Montreal, Quebec, Canada, pp. 341-347. (601 Don, B. J. (1990). Solving thematic divergences in machine translation. Proceedings of ACL-90, University of Pittsburgh, Pittsburgh, PA, pp. 127-134. [61] Don, B. J. (1991). Principle-based parsing for machine translation. Principle-Based Parsing: Computation and Psycholinguistics, (R. C. Benvick, S. P. Abney, and C. Tenny eds.), Kluwer Academic Publishers, Norwell, MA, pp 153-184. [62] Don, B. J. (1992). Parameterization of the interlingua in machine translation. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 624-630. [63] Dorr, B. J. (1992). The use of lexical semantics in interlingual machine translation. Machine Translation, 7(3), 135-193. [64] Dorr, B. J. (1993). Interlingual machine translation: a parameterized approach. Artificial Intelligence, 63(1 & 2), 429-492. [65] DOIT,B. J. (1993). Machine Translation: A View from the Lexicon. The MIT Press, Cambridge, MA. [66] Dorr, B. J. (1994). Machine translation divergences: a formal description and proposed solution. Computational Linguistics, 20(4), 597-633. [67] Dorr, B. J. (1997). Large-scale acquisition of LCS-based lexicons for foreign language tutoring. Proceedings of the ACL 5th Conference on Applied Natural Language Processing (ANLP),Washington, DC, pp. 139-146. [68] Don, B. J. (1997). Large-scale dictionary construction for foreign language tutoring and interlingual machine translation. Machine Translation, 12(4), 27 1-322. [69] Dorr, B. J., Garman, J., and Weinberg, A. (1995). From syntactic encodings to thematic roles: building lexical entries for interlingual MT. Machine Translation, 9,221-250. [70] Dorr, B. J., Habash, N., and Traum, D. (1998). A thematic hierarchy for efficient generation from lexical-conceptal structure. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhome, PA, October 28-31, pp. 333-343. [71] Dorr, B. J., Hendler, J., Blanksteen, S., and Migdaloff, B. (1995). Use of LCS and discourse for intelligent tutoring: on beyond syntax. In M. Holland, J. Kaplan, and M. Sams, eds., Intelligent Language Tutors: Balancing Theory and Technology, Lawrence Erlbaum Associates, Hillsdale, NJ, pp. 289-309. [72] Dorr, B. J., Lin, D., Lee, Jye-hoon, and Suh, S . (1995). Efficient parsing for Korean and English: a parameterized message passing approach, Computational Linguistics, 21(2), 255-263.

60

BONNIE J. DORR ETAL.

[73] Don, B. J., and Oard, D. W. (1998). Evaluating resources for query translation in crosslanguage information retrieval. Proceedings of the 1st International Conference on Language Resources and Evaluation, Granada, Spain, pp. 759-763. [74] Don, B. J., and Olsen, M. B. (1997). Deriving verbal and compositonal lexical aspect for NLP applications. Proceedings of the 35th Annual Meeting of the Association for Computational Linguistics (ACL-97),Madrid, Spain, July 7-12 pp. 151-158. [75] Don, B. J., and Voss, C. (1993). Machine translation of spatial expressions: Defining the relation between an interlingua and a knowledge representation system. Proceedings of 12th Conference of the American Association for Artificial Intelligence. Washington, DC, pp. 374-379. [76] Eberle, K., Kasper, W., and Rohrer, C. (1992). Contextual constraints for machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 213-224. [77] Emele, M. C., and Doma, M. (1998). Ambiguity preserving machine translation using packed representations. Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics (ACL’98). pp. 365-371. [7X] Farwell, D., Guthrie, L., and Wilks, Y. (1992). The automatic creation of lexical entries for a multilingual MT system. Proceedings of the 14th lnternational Conference on Computational Linguistics, Nantes, France, pp. 532-538. [79] Farwell, D., Guthrie, L., and Wilks, Y. (1993). Using machine readable dictionaries for the creation of lexicons. Working Notes, Building Lexicons for Machine Translation, AAAI-93 Spring Symposium, Technical Report SS-93-02, Stanford, CA, p. 106. [XO] Farwell, D., and Wilks, Y. (1990). Ultra: a multi-lingual machine translator. Technical Report MCCS-90-202, Computing Research Laboratory, New Mexico State University. [Xl] Farwell, D., and Wilks, Y. (1991). ULTRA: A multi-lingual machine translator. Proceedings of Machine Translation Summit 111, Washington, DC, July, pp. 19-24. [82] Fisher, F., and Voss, C. R. (1997). FALCON, an MT system support tool for nonlinguists. Proceedings of the Advanced Information Processing and Analysis Conference, McLean, VA. [83] Frederking, R., and Nirenburg, S. (1994). Three heads are better than one. Proceedings of the 4th Conference on Applied Natural Language Processing (ANLP-94), Stuttgart,

Germany. [84] Fujii, Y., Suzuki, K., Maruyama, F., and Dasai, T. (1990). Analysis of long sentence in Japanese-English machine translation system. Proceedings of Information Processing Society of Japan. [85] Furuse, O., and Iida, H. (1992). An example-based method for transfer-driven machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 139-150. [86] Furuse, O., and Iida, H. (1994). Constituent boundary parsing for example-based machine translation. (COLING-94). [87] Gachot, D. A. (1989). The SYSTRAN renaissance. Proceedings of the Machine Translation SUMMIT I!, Deutsche Gesellschaft fuer Dokumentation e.V. (DGD), August pp. 66-71. [88] Gale, W. A., and Church, K. W. (1993). A program for aligning sentences in bilingual corpora. Computational Linguistics, 19,75- 102. [89] Gates, D., and Shell, P. (1993). Rule-based acquisition and maintenance of lexical and semantic knowledge. Proceedings of 6th Conference of the European Chapter of the Association for Computational Linguistics, Utrecht, Holland, pp. 149-157.

CURRENT PARADIGMS IN MACHINE TRANSLATION

61

[90] Ginsparg, J. (1983). A robust portable natural language data base interface. Proceedings of the Conference on Applied Natural Language Processing. [91] Grishman, R., and Kosaka, M. (1992). Combining rationalist and empiricist approaches to machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 263-274. [92] Grishman, R. (1986). Computational Linguistics: An Introduction. ACL Studies in Natural Language Processing. Cambridge University Press, New York. [93] Grosz, B. J., Appelt, D. E., Martin, P. A,, and Pereira, F. C. N. (1987). TEAM: an experiment in the design of transportable natural-language interfaces. Artificial Intelligence, 32(2), 173-243. [94] Guida, G., and Tasso, C. (1983). IR-NLI: an expert natural language interface to online data bases. Proceedings of the Conference on Applied Natural Language Processing. [95] Higinbotham, D. (1990). Semantic cooccurrence networks. Third International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Language, Austin Texas, University of Texas at Austin. [96] Hogan, C. (1998). Embedded spelling correction for OCR with an application to minority languages. Proceedings of Embedded MT Workshop, AMTA-98, Langhome, PA, October. [97] Hogan, C., and Frederking, R. E. (1998). An evaluation of the multi-engine MT architecture. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhome, PA, October 28-31, pp. 113-123. [98] Holland, V. M., and Schlesinger, C. (1998). FALCON, lessons learned in the field. Proceedings of the Advanced Information Processing and Analysis Conference, McLean, VA. [99] Hopp, K. L. (1990). Globalink translation system equal goes it loose ... the problem of computer-assisted translation. Computerland, 3(8). [loo] Hutchins, J. W., and Somers, H. (1992). An Introduction to Machine Translation. Academic Press, London, England. [loll Hutchins, W. J. (1986). Machine Translation: Past, Present, Future. Ellis Honvood, Ltd, Chichester, England. [lo21 Hutchins, W. J. (1987). Prospects in translation. Proceedings of Machine Translation Summit I , Japan. [lo31 Ishikawa, M., and Sugimura, R. (1992). Natural language analysis using a network model: modification deciding network. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 55-66. [ 1041 Jackendoff, R. (1972). Grammatical relations and functional structure. Semantic Interpretation in Generative Grammar. The MI" Press, Cambridge, MA. [lo51 Jackendoff, R. (1983). Semantics and Cognition. The MIT Press, Cambridge, MA. [lo61 Jackendoff, R. (1990). Semantic Structures. The MIT Press, Cambridge, MA. [lo71 Jain, A. N. (1991). Parsing complex sentences with structured connectionist networks. Neural Computation, 3, 110-120. [lo81 Johnson, R., King, M., and Tombe, des L. (1985). EUROTRA: A multilingual system under development. Computational Linguistics, 11, 155-169. [lo91 Roderick, L., Johnson, M., and Whitelock, P. (1987). Machine translation as an expert task. Machine Translation: Theoretical and Methodological Issues ( S . Nirenburg ed.), Cambridge University Press, Cambridge, England, pp. 136-144. [110] Jones, D. (1992). Non-hybrid example-based machine translation architectures.

62

BONNIE J. DORR ETAL.

Proceedings of the 4th International Conference on Theoretical arid Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 163-172. [ I1 I] Jones, D., and Tsujii, J. (1990). High quality machine-driven text translation. Proceedings of the 3rd International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Linguistics Research Center, The University of Texas, Austin, TX, pp. 43-46. [112] Jordan, P. W., Don, B. J., and Benoit, J. W. (1993). A first-pass approach for evaluating machine translation systems. Machine Translation, 8( 1-2), 49-58, Mitre Best Paper Incentive Award. [113] Joshi, A. K. (1985). How much context-sensitivity is necessary for characterizing structural descriptions-tree adjoining grammars. Natural Language Processing: Theoretical, Computational, and Psychological Perspectives, (D. Dowty, L. Karttunen and A. Zwicky eds.). Cambridge University Press, New York. [114] Kaplan, R., and Bresnan, J. (1982). Lexical-functional grammar: A formal system for grammatical representation. The Mental Representation of Grammatical Relations, (J. Bresnan ed.). The MIT Press, Cambridge, MA, pp. 173-281. [I151 Kaplan, R., Netter, K., and Zaenen, A., Wedekind, J. (1989). Translation by structural correspondences. Proceedings of the 4th Conference of the European Chapter of the Association for Computational Linguistics, Manchester, pp. 272-28 1. [116] Kaplan, R. M., and Wedekind, J. (1993). Restriction and correspondence-based translation. Proceedings of the 6th Conference of the European Chapter of the Association for Computational Linguistics, Manchester, pp. 193-202. 171 King, G . (1956). Stochastic methods of mechanical translation. Mechanical Translation. 181 King, M. (1981). Design characteristics of a machine translation system. Proceedings of the 7th International Joint Conference on Artificial Intelligence, University of British Columbia, Vancouver, BC, Canada, Volume 1, pp. 43-46. 191 King, M. (1987). Machine Translation: The State of the Art. Edinburgh University Press, Edinburgh. 201 King, M., and Falkedal, K. (1990). Using test suites in evaluation of machine translation systems. (COLING-90), Helsinki. [I211 Knight, K., and Al-Onaizdn, Y . (1998). Translation with finite-state devices. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhome, PA, 28-31 October, pp. 421-437. [122] Knight, K., and Chander, I. (1994). Automated Postediting of Documents. Proceedings of the 12th National Conference on Artificial Intelligence, Seattle, Washington, pp. 779-784. [123] Knight, K., Chander, I., Haines, M., Hatzivassiloglou, V., Hovy, E. H., Iida, M., Luk, S. K., Whitney, R. A., and Yamada, K. (1995). Filling knowledge gaps in a broadcoverage MT system. Proceedings of the 14th International Joint Conference on Artificial Intelligence, Montreal, Quebec, Canada, August. [124] Knight, K., and Luk, S. (1994). Building a large knowledge base for machine translation. Proceedings of M I - 9 4 . [ 1251 Knight, K. (1991). Integrating Knowledge Acquisition and Language Acquisition. PhD thesis, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA, CMU-CS-91-209. [ 1261 Kolodner, J. (1993). Case-Based Reasoning. Morgan Kauffman, San Mateo, California. [127] Komatsu, E., Jin, C., and Yasuhara, H. (1993). A mono-lingual corpus-based machine translation of the interlingua method. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp. 24-46.

CURRENT PARADIGMS IN MACHINE TRANSLATION

63

[I281 Krauwer, S. (1993). Evaluation of MT systems: A programmatic view. Machine Translation, S(1-2), 59-66. [I291 Landsbergen, J., Odijk, J., and Schenk, A. (1989). The power of compositional translation. Literary and Linguistic Computing, 4(3). [I301 Lehmann, H., and Ott, N. (1992). Translation relations and the combination of analytical and statistical methods in machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 237-248. [131] Lenat, D. B., and Guha, R. V. (1990). Building Large Knowledge-Based Systems. Reading, MA, Addison-Wesley. [132] Lonsdale, D., Mitamura, T., and Nyberg, E. (1995). Acquisition of large lexicons for practical knowledge-based MT. Machine Translation, 9,251-283. [ 1331 Lozano, M. C. (1989). Globalink translation system. American Translators Association Conference, pp. 489-490. [134] Lytinen, S. L, (1987). Integrating syntax and semantics. Machine Translation: Theoretical and Methodological Issues, (S. Nirenburg ed.), Cambridge University Press, Cambridge, England. [I351 Machine Translation (1993). Special Issue on Current Research in Translation, 7(4). [136] Mahesh, K., and Nirenburg, S. (1995). A situated ontology for practical NLP. Proceedings of IJCAI-95 Workshop on Basic Ontological Issues in Knowledge Sharing, August. [137] Maruyama, H., Ogino, S., and Hidano, M. (1993). The mega-word tagged-corpus project. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp. 15-23. [I381 Maruyama, H., and Watanabe, H. (1992). Tree cover search algorithm for examplebased machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 173-184. [139] Maxwell, D., Schubert, K., and Witkam, T. (1988). Recent Developments in Machine Translation. Foris, Dordrecht, Holland. [140] McCord, M. C. (1989). Design of LMT: A prolog-based machine translation system, Computational Linguistics, 15, 33-52. [141] McLean, I. J. (1992). Example-based machine translation using connectionist matching. Proceedings of the 4th International Conference on Theorerical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 35-43. [I421 Mercer, R. L. (1993). Inflectional morphology needs to be authenticated by hand. Working Notes, Building Lexicons for Machine Translation, AAAI-93 Spring Symposium, Technical Report SS-93-02, Stanford, CA, p. 105. [I431 Miller, K. J., and Zajic, D. M. (1998). Lexicons as gold: Mining, embellishment and reuse. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhome, PA, 28-31 October, pp. 484-493. [144] Mittendorf, E., Schauble, P., and Sheridan, P. (1995). Applying probabilistic term weighting to OCR text in the case of a large alphabetic library catalogue. Proceedings of the 18th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval, Seattle, Washington, 9-13 July, pp. 328-335. Available at http://www-ir.inf.ethz.chlPublic-Web-Pages/sherid~shend~.html; http://trec.nist.gov (TREC-3 and TREC-4 confusion track papers). I1451 Montemagni, S., and Vanderwende, L. (1992). Structural patterns v. string patterns for

64

I1461 [147] [ 1481

[149]

[I501 [151]

[152]

[ 1531

[154] [155] [156] [I571

[I581 [159] [160] [I611 [I621

BONNIE J. DORR ETAL.

extracting semantic information froin dictionaries. Proceedings of the 14th International Conference on Computational Linguistics, Nantes, France, pp. 546-552. Nagao, M. (1984). A framework of a mechanical translation between Japanese and English by analogy principle. Artificial and Human Intelligence (A. Elithom and R. Banerji eds.), North-Holland. Nagao, M. (1989). Machine Translation: How Far Carl I t Go? Oxford University Press (translated from Japanese by Norman D. Cook.). Nagao, M. (1990). Dependency analyzer: A knowledge-based approach to structural disambiguation. Proceedings of 13th International Conference on Computational Linguistics, Helsinki, Finland, pp. 282-287. Neff, M. S . , Blaser, B., Lange, J. M., Lehmann, H., and Dominguez, I. Z. (1993). Get it where you can: Acquiring and maintaining bilingual lexicons for machine translation Working Notes, Building Lexicons for Machine Translation, AAAI-93 Spring Symposium, Technical Report SS-93-02, Stanford, CA, p. 104. Nerbonne, J., Netter, K., Diagne, A. K., Klein, J., and Dickmann, L. (1993). Diagnostic tool for German syntax. Muchine Translation, 8(1-2), 85-108. NieBen, S . , Vogel, S., Ney, H., and Tillmann, C. (1998). A DP based search algorithm for statistical machine translation. ACLJCOLING 98, Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics (joint with the 17th International Conference on Computational Linguistics), Montreal, Canada, 10-14 August, pp. 960-967. Nirenburg, S . , Domashnev, C., and Grannes, D. J. (1993). Two approaches to matching in example-based machine translation. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp. 41-57. Nirenburg, S . (1987). Machine Translation: Theoretical & Methodological Issues. Cambridge University Press, Cambridge, England. Nirenburg, S . (1993). A Direction of MT development. Proceedings of Machine Translation Summit N , Kobe, Japan, pp. 189-194. Nirenburg, S . , Carbonell, J., Tomita, M., and Goodman, K., (eds.) (1992). Machine Translation: A Knowledge-Based Approach. Morgan Kaufmann Publishers, San Mateo, CA. Nirenburg, S., Farwell, D., and Wilks, Y. (1994). Multi-engine, adaptive MT. Proceedings of 15th International Conference on Computational Linguistics. Nirenburg, S., and Goodman, K. (1990). Treatment of meaning in MT systems. Proreedings of the 3rd International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Language, Linguistic Research Center, University of Texas at Austin pp. 171-187. Nomiyama, H. (1991). Lexical selection mechanism using target language knowledge and its learning ability. Technical Report IPSJ-WG, Information Processing Society of Japan. Nomiyama, H. (1992). Machine translation, by case generalization. Proceedings of 14th lniernational Conference on Computational Linguistics, Nantes, France, pp. 7 14-720. Nyberg, E., and Mitamura, T. (1991). An efficient interlingua translation system for multilingual document production. Proceedings of Machine Translation Summit Ill, Washington, DC, July pp. 55-61, Nyberg, E., and Mitamura, T. (1992). The KANT system: fast, accurate, high-quality translation in practical domains. Proceedings of the 4th International Conference on Computational Linguistics, Nantes, France. Oard, D. W. (1998). A comparative study of query and document translation for cross-

CURRENT PARADIGMS IN MACHINE TRANSLATION

[163]

[164]

[165]

[166] [ 1671

[168] [169] [170] [171] [172] [173]

[174] [175]

[176] [177] [178] [ 1791

65

language information retrieval. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhorne, PA, 28-3 1 October, pp. 472-483. Okumura, A., Muraki, K., and Yamabana, K. (1992). A Pattern-laming based, hybrid model for the syntactic analysis of structural relationships among Japanese clauses. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 45-54. Olsen, M. B. (1998). Translating English and mandarin verbs with argument structure (Mis)matches using LCS representation. Proceedings of the SIG-IL Second Workshop on Interlinguas, AMTA-98, New Mexico State University Technical Report MCCS-98316, Langhorne, PA, pp. 45-58. Olsen, M. B., Don, B. J., and Thomas, S. C. (1998). Enhancing automatic acquisition of thematic structure in a large-scale lexicon for mandarin Chinese. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhorne, PA, 28-31 October, pp. 41-50. Onyshkevich, B., and Nirenburg, S. (1995). A lexicon for knowledge-based MT. Machine Translation, lO(1-2). 5-57. Otero, M. (1997). AmCrica latina: Radiografii de una proeza. UNESCO Courier, January. Palmer, M., and Finin, T. (1990). Workshop on the evaluation of natural language processing systems. Computational Linguistics, 16(3). Palmer, M., and Wu, Z. (1995). Verb semantics for English-Chinese translation. Machine Translation, 10(1-2), 59-92. Pans, C., and Scott, D. (1994). Stylistic variation in multilingual instructions. Seventh International Workshop on Natural Language Generation, Kennebunkport, Maine, pp. 45-52. Pustejovsky, J., Bergler, S., and Anick, P. (1993). Lexical semantic techniques for corpus analysis. Computational Linguistics, 19(2), 33 1-358. Pustejovsky, J., and Bergler, S. (1987). The acquisition of conceptual structure for the Lexicon. Proceedings of the 6th Conference of the American Association of Artificial Intelligence, Seattle, Washington, pp. 566-570. Reeder, F., and Loehr, D. (1998). Finding the right words: an analysis of not-translated words in machine translation. Proceedings of the 3rd Conference of the Association for Machine Translation in the Americas, AMTA-98, in Lecture Notes in Artificial Intelligence, 1529, Langhorne, PA, 28-3 1 October, pp. 356-363. Retinger, C.-T. (1991). Globalink-foreign languages made easy do you speak a foreign language? Excerpt from COM (Austria). Richardson, S. D., Vanderwende, L., and Dolan, W. (1993). Combining dictionarybased and example-based methods for natural language analysis. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp. 69-79. Rosetta, M. T. (1994). Compositional Translation. Kluwer Academic Publishers, Dordrecht, The Netherlands. Roudaud, B., Puerta, M. C., and Gamrat, 0. (1993). A procedure for the evaluation and improvement of an MT system by the end-user. Machine Translation, S(1-2), 108-1 16. Sadler, L., and Arnold, D. (1992). A constraint-based approach to translating anaphoric dependencies. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 728-734. Sadler, L., and Thompson, H. S. (1991). Structural non-correspondence in translation. Proceedings of 5th Conference of the European Chapter of the Association for Computational Linguistics, Berlin, Germany, pp. 293-298.

66

BONNIE J. DORR ETAL

[I801 Saito, H., and Tornita, M. (1986). On Automatic Composition of Stereotypic Documents in Foreign Languages. Technical Report CMU-CS-86- 107, Department of Computer Science, Carnegie Mellon University. [181] Sanfilippo, A., Briscoe, T., Copestake, A., Marti, M.A., Taule, M., and Alonge, A. ( 1992). Translation equivalence and lexicalization in the ACQUILEX LKB. Proceedings of the 4th International Conference on Theoretical arid Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 1-1 1. [I821 Sato, S. (1993). Example-based translation of technical terms. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp. 58-68. [I831 Sato, S., and Nagao, M. (1990). Toward memory-based translation. Proceedings of Z3th International Conference on Computational Linguistics, Helsinki, Finland, pp, 247-252. [I841 Schank, R. C. (1972). Conceptual dependency: A theory of natural language understanding. Cognitive Psychology, 3, 552-631. [ 1851 Schank, R. (1973). Identification of conceptualizations underlying natural language. Computer Models of Thought and Language, (R. Schank and K. Colby eds.), Freeman, San Francisco, CA, pp. 114-151. [ 1861 Schank, R. C., (ed.) (1975). Conceptual Information Processing. Elsevier Science Publishers, Amsterdam, The Netherlands. 11871 Schubert, K. (1988). The architecture of DLT-interlingual or double direct? Recent Developments in Machine Translation (D. Maxwell, K. Schubert, and T. Witkam eds.), Foris, Dordrecht, Holland, pp. 131-144. [ 1881 Science applications international corporation (SAIC). SYSTRAN Administrator’s Manual, September, 1988. [189] Science applications international corporation (SAIC). SYSTRAN User’s Manual, September 1989. [190] Scott, B. E. (1989). The LOGOS system. MT SUMMIT I I , Deutsche Gesellschaft fuer Dokumentation e.V. (DGD), August, pp. 174-179. [191] Scott, B. E, (1990). Biological neural net for parsing long, complex sentences. Review draft, Logos Corporation Technical Center, 111 Howard Blvd, Mt Arlington NJ 07856, November. [192] Scott, B. E. (1990). Tender offer in response to European commission tender call #6. Response to call, Logos Corporation, January. [193] Sharp, R. M. (1985). A Model of Grammar Based on Principles of Government and Binding. Master’s thesis, Department of Computer Science, University of British Columbia. [194] Shieber, S. M., and Schabes, Y. (1990). Synchronous tree adjoining grammars. Proceedings of 13th International Conference on Computational Linguistics, Helsinki, Finland, pp. 253-258. [ 1951 Shiwen, Y. (1993). Automatic evaluation of output quality for machine translation systems. Machine Translation, 8( 1-2), 117- 126. [196] Sigurd, B. (1988). Translating to and from Swedish by SWETRA-a multilanguage translation system. Recent Developments in Machine Translation (D. Maxwell, K. Schubert and T. Witkam eds.), Foris, Dordrecht, pp. 205-218. [197] Sigurd, B., and Eeg-Olofsson, M. (1991). Prolog Implementations of English and Swedish GB Grammars. Technical Report Working Papers 38, Department of Linguistics, Lund University. [198] Slocum, J. (1988). Machine Translation Systems. Cambridge University Press, Cambridge. [I991 Slocum, J., and Justus, C. F. (1985). Transportability to other languages: The natural

CURRENT PARADIGMS IN MACHINE TRANSLATION

[200] [201]

[202]

[203] [204]

[205]

[206] [207]

[208]

[209]

[210]

[21I]

[212] [213]

[214]

[215]

67

language processing project in the A1 program at MCC. ACM Transactions on Office Information Systems, 3(2), 204-230. Slocum, J. (1985). A survey of machine translation: Its history, current status and future prospects. Computational Linguistics, 1 1, January-March. Somers, H. (1992). Interactive multilingual text generation for a monolingual user. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 151-161. Somers, H., Tsujii, J., and Jones, D. (1990). Machine translation without a source text. Proceedings of the 13th international Conference on Computational Linguistics, Helsinki, Finland, pp. 271-276. Somers, H. (1993). Current research in machine translation. Machine Translation, 7(4), 231-246. Steiner, E. ( 1993). Producers-users-customers: Towards a differentiated evaluation of research in machine translation. Machine Translation, 7(4), Special issue on current research in machine translation. Su, K. Y., and Chang, J. S. (1992). Why corpus-based statistics-oriented machine translation. Proceedings of the 4th International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 249-262. Sumita, E., Iida, H., and Kohyama, H. (1990). Example-based approach in machine translation. Proceedings of InfoJapan. Sumita, H., Furuse, O., and Iida, H. (1993). An example-based disambiguation of prepositional phrase attachment. Proceedings of the 5th International Conference on Theoretical and Methodological Issues in Machine Translation, Kyoto, Japan, pp, 80-91. Templeton, M., and Burger, J. (1983). Problems in natural language interface to DBMS with examples for EUFID. Proceedings of the Conference on Applied Natural Language Processing, pp. 3-16. Thompson, B., and Thompson, F. (1983). Introducing ASK, a simple knowledgeable system. Proceedings of the Conference on Applied Natural Language Processing, pp. 17-24. Thurmair, G. (1990). Complex lexical transfer in METAL. Proceedings of the 3rd international Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Linguistics Research Center, The University of Texas, Austin, pp. 91-107. Trujillo, A. (1992). Locations in the machine translation of prepositional phrases. Proceedings of the 4th International Conference on Theoretical and Methodological issues in Machine Translation of Natural Languages, Montreal, Canada, pp. 13-20. Trujillo, A. (1995). Towards a cross-linguistically valid classification of spatial prepositions. Machine Translation, lO(1-2), 93-141. Tsujii, J., and Fujita, K. (1991). Lexical transfer based on bilingual signs: Towards interaction during transfer. Proceedings of the European Chapter of the Association for Computationul Linguistics, Berlin, Germany, pp. 275-280. Tsujii, J., and Nagao, M. (1988). Dialogue translation v. text translation interpretation based approach. Proceedings of the 12th International Conference on Computational Linguistics, Budapest, Hungary, pp. 688-693. van Noord, G., Dorrepaal, J., van der Eijk, P., Florenza, M., and des Tombe, L. (1990). The MiMo2 research system. Proceedings of the 3rd International Conference on Theoretical and Methodological Issues in Machine Translation of Natural Languages, Linguistics Research Center, The University of Texas, Austin, TX, pp. 213-233.

68

BONNIE J. DORR ETAL.

[216] van Slype, G. (1982). Conception dline mtthodologie g6nCrale d’ivaluation de la trdduction automatique. Multilingua, 1,221-237. [217] Vasconcellos, M. (1993). What do we want from MT? Machine Translation, 7(4), Special issue on current research in machine translation. [218] Vauquois, B. (1968). A survey of formal grammars and algorithms for recognition and transformation in machine translation. IFIP Congress-68, pp. 254-260. [219] Voss, C., and Dorr, B. J. (1995). Toward a lexicalized grammar for interlinguas. Machine Translation, lO(1-2), 143-184. [220] Wang, Y.-Y., and Waibel, A. (1998). Modeling with structures in statistical machine translation. ACLICOLING 98, Proceedings of the 36th Annual Meeting of the Association for Cornputational Linguistics (joint with the 17th International Conference on Computational Linguistics), Montreal, Canada, 10-14 August, pp. 1357-1363. [221] Wehrli, E. (1992). The IPS system. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 870-874. [222] Whitelock, P. (1989). Why transfer and interlingua approaches to MT are both wrong: A position paper. Presented at MT Workshop, Into The ~ O ’ S Manchester, , England. [223] Whitelock, P. (1991). A Lexicalist Unification Grummar of Japanese. PhD thesis, Language and Linguistics, UMIST, Mmchester. [224] Whitelock, P. (1992). Shake-and-bake translation. Proceedings of 14th International Conference on Computational Linguistics, Nantes, France, pp. 784-79 1. [225] Wilks, Y. (1991). Comparisons with US/Europe. JTEC Machine Translation Workshop, Washington, D.C., March. National Science Foundation. [226] Wilks, Y. (1993). Corpora and machine translation. Proceedings of Machine Translation Summit lV, Kobe, Japan, pp. 137-146. [227] Wilks, Y., Fass, D., Guo, C.-M., McDonald, J. E., and Plate, T. (1990). Providing machine tractable dictionary tools. Machine Translation, 5(2), 99-154. [228] Wu, D. (1996). A polynomial-time algorithm for statistical machine translation. Proceedings of the 34th Conference of the Association for Computational Linguistics, Santa Cruz, CA, June, pp. 152-158. [229] Wu, D. (1997). Stochastic inversion transduction grammars and bilingual parsing of parallel corpora. Conzputational Linguistics, 23(3), 377-400. [230] Wu, D., and Wong, H. (1998). Machine translation with a stochastic grammatical channel. ACLJCOLING 98, Proceedings of the 36th Annual Meeting of the Association for Cornputational Linguistics (joint with the 17th International Conference on Computational Linguistics), Montreal, Canada, 10-14 August, pp. 1408-1415. [231] Wu, D., and Xia, X. (1995). Large-scale automatic extraction of an English-Chinese translation lexicon. Machine Translation, 9(3-4), 285-313. [232] Yamron, J., Baker, J., Barnberg, P., Chevalier, H., Dietzel, T., Elder, J., Kampmann, F., Mandel, M., Manganaro, L., Margolis, T., and Steele, E. (1993). LINGSTAT: An interactive, machine-aided translation system. ARPA Workshop on Human Language Technology, Plainsboro, New Jersey. [233] Yamron, J., Cant, J., Demedts, A., Dietzel, T., and Ito, Y. (1994). The automatic component of the LINGSTAT machine-aided translation system. ARPA Workshop on Machine Translation, Vienna, Virginia, March. [234] Yasuhara, H. (1993). An example-based multilingual MT system in a conceptual language. Proceedings of Machine Translation Summit IV, Kobe, Japan, pp. 189-194. [235] Zajic, D. M., and Miller, K. J, (1998). Where interlingua can make a difference. Proceedings of the SIG-1L Second Workshop on Interlinguas, AMTA-98, New Mexico State University Technical Report MCCS-98-3 16, Langhome, PA, pp. 69-78.

Formality in Specification and Modeling: Developments in Software Engineering Practice J. S. FITZGERALD Centre for Software Reliability University of Newcastle upon Tyne

NE? 7RU UK [email protected]. uk

Abstract Formal methods have been a controversial subject among software engineering practitioners for twenty years. However, advances in the technology supporting formal methods, coupled with a realistic view of their potential for commercial application, have brought about marked improvements in the ease with which formal techniques can be integrated into industrial software development. This paper reviews the use of formal techniques for modeling systems in the commercial software development context. The basic ideas of formality and formal methods are introduced. The characteristics of formal models are introduced via a small example based on a commercial application. Reports of experiences in applying formal techniques in industrial contexts lead to a discussion of the promises and challenges facing formal methods in industry today.

1. Introduction

........................................................ ......................

3.1 Modeling Data. . . . . . . . . 3.2 Modeling Functionality. . . . 3.3 State-based Modeling . . . .

.......... ..........

...... ......

.........................

70 I1 15

I1 19

5.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVANCES IN COMPUTERS, VOL. 49 ISBN 0- 12-012149-2

69

Copyright 01999 by Academic Press All rights of reproduction in any form reserved.

70

J. S. FITZGERALD

1. Introduction The term “formal methods” has come to be associated with theoretical technology: arcane notations supported by weak tools and training, used by academic experts to specify unrealistically simple computing systems. At best, such methods would be used by a few specialist companies on highly critical subsystems. Recent years have, however, seen developments in the technology supporting formal methods coupled with a more realistic view of how these methods may be applied effectively. This makes it possible to conduct studies on the use of formal methods in the commercial environment, and to introduce some formal techniques without catastrophic disturbance to existing development processes. This paper aims to provide a view of formal techniques that are mature enough to be applied in the industrial environment at the present time. The central technique in software engineering is modeling: developing a description of a proposed or existing computing system which suppresses unnecessary detail and which admits analysis. The most useful view of formal methods for the industrial practitioner is that they are techniques which admit improved modeling at various stages in the development process. For example, data flow models could be enhanced by giving executable formal descriptions of the data transforms: analysis tools would allow testing, animation, even proof of emergent properties of the model. This view of formal techniques as enhancements to existing software engineering technology is borne out in the many working groups that have been discussing the future of formal methods. See, for example, Saiedian’s round-table discussion [Sai96] or the survey by Clarke, Wing et al. [CW 96). Other authors, such as Luqi and Goguen [LG97], have identified developments in software practice, such as the use of iterative prototyping, which tend to undermine a simplistic view of software development in which a formal specification can be refined to provably correct code in a series of traditional waterfall steps. Jackson and Wing [JW96] encourage the use of partial modeling; Jones [Jon961 encourages rigor in the analysis of models, but advises against a dogmatic pursuit of formal proof. This paper draws on a strand of work aimed at developing accessible and commercially applicable formal techniques based on model-oriented specification languages. In particular, the paper reports a study undertaken in collaboration with a UK company in which a formal model of a tracking system was developed purely in order to understand the system better, rather than to develop it to the level of running code. The study serves to illustrate some of the salient characteristics of formal modeling and analysis in industrial practice. In particular, there are points at which the aspiration to use an expressive +

FORMALITY IN SPECIFICATION AND MODELING

71

mathematical language must be balanced against pragmatics, for example in balancing executability and testing with the ability to conduct proof. Section 2 introduces basic concepts in the formal modeling of computing systems. The focus then shifts to the use of formal modeling techniques during industrial systems development. The tracking system model is presented in Section 3 . Section 4 introduces the major analysis techniques applicable to formal models, again with reference to the example. The discussion is widened in Section 5 to consider the lessons learned from other industrial applications and surveys reported in the literature.

2. Modeling, Abstraction and Formality Modeling is a common activity in engineering. Models provide a means of testing out design ideas, or of determining the feasibility of a project, and they also serve as a communication medium between engineers and clients. Modeling a system before committing it to the implementation medium, be it metal or software, can help to avoid errors which might otherwise only become apparent in late development stages when rework costs are high. Two characteristics of good engineering models are of interest here: abstraction and rigor. Models are constructed for a particular purpose, and several complementary models of a system may be constructed during its development. For example, a new aircraft’s wing shape may be modeled during aerodynamic design but the layout of the cockpit instruments is modeled at a different stage. Engineering models are abstract in that those aspects of a system which are not believed to be significant for the purpose of the model are suppressed. The choice of which aspects of the system should be in a model, and which should be suppressed, is a matter of engineering skill. The value of a model lies in its suitability for analysis and this is enhanced by rigor in the model’s expression. The purpose of analysis is to provide an objective assessment of the model’s properties. It is valuable to be able to perform as much of the analysis as possible mechanically, in order to maximize objectivity, reduce the likelihood of human error and save on effort. In order to achieve this level of objectivity and mechanization, mathematically well-founded analysis techniques are often used. Formal modeling techniques for computing systems are simply techniques which have a well-founded mathematical basis. They normally have a precisely defined syntax and an equally precisely defined semantics, so that, in principle, an argument over the meaning of some expression in the model can be resolved by reference to the formal semantics. For the purposes of this paper, a formal method is a formal modeling language and a

72

J. S. FITZGERALD

collection of techniques for analyzing models expressed in the language. The formality of a modeling language is a characteristic that developers are free to exploit or ignore as they see fit. Work on the commercial application of formal methods concentrates on the development of modeling languages and analysis techniques, the tools and training materials to support them, which are capable of being applied within an existing development process with the aim of achieving an improvement in the process itself, such as a reduction in rework costs, or in characteristics of the developed product, such as reliability. Wing [Win901 gives a broad introduction to the classes of formal methods in existence, drawing a distinction between property-oriented and modeloriented formal methods. Using a property-oriented method, an engineer models the system of interest by listing its properties, usually as a series of logical axioms. Examples of property-oriented methods include Larch tGHW8.5, GMH901 and Clear [BG80, BG811. In a model-oriented method, the engineer calls on a rich repertoire of data types representing abstract mathematical structures, such as mappings, sequences and sets, to construct a model of the system. Well-known model-oriented methods include Z [WD96] and VDM [Jon90, FL981. A third class of notations describe the behavior of a system in terms of a state-transition model, usually expressed in a graphical notation. Some methods, such as Raise [NHWG89, RAI92, RAI951, accommodate a range of styles, property-oriented and modeloriented. Still other formal notations and techniques deal with specialized issues such as concurrency, for example CCS [Mi189], CSP [Hoa85] and the graphical Statecharts formalism [Har87]. LOTOS [LOT, TB941 provides for a rich repertoire of data while supporting concurrency. The following sections are based on experiences in using model-oriented techniques in a number of industrial projects. An example of a modeloriented specification is presented here in order to illustrate how a formal modeling language supports abstraction and rigor, and in order to introduce the main issues surrounding the use of such techniques in industrial practice. 3. An Example of a Model-oriented Specification The example introduced in this section serves to illustrate many of the concepts introduced so far, especially abstraction and the range of validation techniques that can be used on a formal model. It is a simplified version of a tracking manager (or tracker) system model developed by a team at Manchester University in association with BNFL (Engineering) in the UK. This simplified model, due to Fitzgerald and Larsen, is presented in greater depth in [FL98], while aspects of the original model are discussed in [Fit961 and [FJ98]. The simplified model is presented in this section, along with observations on those aspects of the model that proved significant in the project.

FORMALITY IN SPECIFICATION AND MODELING

73

The purpose of the tracker is to monitor the movement of containers of waste material as they pass through a reprocessing facility. The facility consists of phases corresponding to physical processes such as unpacking, dissolving, distilling or compaction. Each phase will accept only containers holding certain kinds of material: for example, liquid waste cannot be accepted for compaction. The tracker system maintains a record of containers, their contents and the phases in which they are placed. When a container is to be moved between phases, the tracker is asked to confirm that the move is permissible. When the move takes place, the tracker’s record of container positions is to be updated. The purpose for which a model is developed must be articulated clearly so that abstraction is used appropriately. The purpose of the model developed in this example is to verify the rules governing the movement of containers between phases. The model should therefore be expected to show containers and phases and to contain functionality sufficient to grant permission for a move and to record the move when it takes place. Other issues such as the tagging of containers with timestamps, modeling rate of throughput, etc. will not play a part in this particular model, although they might be significant in models developed for other purposes. The formal model of the tracker was developed using the IS0 Standard VDM Specification Language (VDM-SL) [VDM96]. VDM-SL is a modeloriented language in which the system is modeled via data values drawn from types defined using the type constructors and base types of the language. For example, a model may contain a mapping from identifiers,represented as character sequences, to sets of records. The system functionality is modeled as a set of functions or operations which manipulate values from the defined types.

3.1 Modeling Data The model of the tracker will have to represent Containers, so the type Container is introduced. Containers will be represented as tuples containing relevant information about the container, including its fissile mass, represented as a real number, and the kind of material that is carried. In VDM-SL, this is expressed as follows: Container :: fiss-mass material

: real : Material

The data type r e a l is built into VDM-SL. The “: :” notation defines a record type, here with two named fields. The type of each field is given alongside its name. The type Material is defined elsewhere in the model as an enumerated type: Material =

1

<Metal>

I

74

J. S. FITZGERALD

Note the forms of abstraction used so far. The type real contains all real numbers, not just those within particular bounds. It is used here because the representation of numerical values is not a dominant concern for the purpose of this particular model. If it were felt to be relevant to the model, then restrictions on representation of numbers (e.g. maxima, minima, precision) could be built in to the model. Formal modeling notations such as VDM-SL typically allow restrictions to be recorded on data types. Such restrictions are termed data type invariants. For example, the definition of the type representing the phases of the reprocessing plant is as follows: Phase :: contents expected-materials capacity

: set of ContainerId : set of Material : nat

Phases are modeled as records containing the phase’s contents (the identifiers of the containers in the phase), the kinds of material which are accepted by the physical process in the phase and the capacity of the phase in terms of the number of containers permitted in the phase at any time. An invariant is used to record the restriction that the number of containers in the contents should not exceed the capacity and also the set of expected materials should not be empty. Formally, the invariant is recorded as a predicate associated with the type definition: Phase :: contents : set of ContainerId expected-materials : set of Material : nat capacity inv p == card p.contents <= p.capacity and p.expected-materials <> { }

Engineers approaching formal modeling for the first time have commented on the value of the invariant as a means of recording hitherto implicit or assumed requirements. lnvariants are stronger than comments in code: they have real semantic force in the sense that all functions which produce modifications in values drawn from a type must be shown to respect the invariant on the type. The overall tracker is modeled as a record containing two mappings - one from container identifiers to containers and one from phase identifiers to phases: Tracker :: containers : map ContainerId to Container : map PhaseId t o Phase phases

The ContainerId and PhaseId types will not be further defined here. However, it is worth noting that a number of important invariant restrictions must be recorded against the Tracker type. In the tracking manager project

75

FORMALITY IN SPECIFICATION AND MODELING

these included restrictions to ensure internal consistency (for example, that phases contain only container identifiers known in the containers mapping) but also additional constraints which arise from safety considerations, for example that all the containers identified in a given phase hold only the kinds of material expected for that phase. The restrictions were recorded as an invariant on the data type representing the tracker: Tracker :: containers : map ContainerId to Container phases : map PhaseId to Phase inv mk-Tracker(containers,phases) == Consistent(containers,phases) and PhasesDistinguished(phases) and MaterialSafe(containers,phases)

The details of the three conjuncts in the invariant were provided separately. For example, MaterialSaf e (containers,phases ) was defined via the following logical predicate: forall ph in set rng phases & forall cid in set ph.contents & cid in set dom containers and containers(cid).material in set ph.expected-materials

Notice that VDM-SL permits predicates that include quantification (“forall” or “exists”) over sets or types of values. While this facility contributes to abstraction, it can be at odds with support for execution and testing of models, especially where the quantification is over an infinitely large type of values. Executability is discussed in section 4.2.3.

3.2 Modeling Functionality The functionality of the system may be modeled by means of functions defined over the data types. For example, the tracker is required to give or refuse permission for the movement of a container from one phase to another. This is formalized by the following function which, given a tracker, a container identifier and an identifier for the destination phase, returns a Boolean value true provided the four conditions are met under which permission can be granted. The conditions are that the container identifier and destination phase’s identifier are known to the tracking system; that the destination phase has sufficient capacity to take one more container and that the material in the container is of the expected type for the destination phase. Permission: Tracker * ContainerId * PhaseId -> boo1 Permission(mk-Tracker(containers, phases), cid, dest) cid in set dom containers and

==

J. S.FITZGERALD

76

dest in set dom phases and card phases(dest).contents < phases(dest).capacity and containers(cid).material in set phases(dest).expected-materials

The modeled functionality must respect constraints on the system data. In the formal model, this is realized by a requirement that the functions must respect the invariants on their result types. Consider, for example, a function which describes the movement of a container from one phase to another. The basic function definition could be as follows: Move: Tracker * ContainerId * PhaseId * PhaseId -> Tracker Move(trk, cid, ptoid, pfromid) == let pha = mk-Phase ( trk.phases(ptoid).contents union {cid}, trk.phases(ptoid).expected-materials, trk.phases(ptoid).capacity) in mk-Tracker(trk.containers, Remove(trk,cid,pfromid).phases ++ {ptoidl-> pha})

This function returns a new tracker calculated from the old (input) tracker by deleting the container identified by c i d from its phase (pf romid) and adding it to the destination phase ( p t o i d ) . This function, however, could allow the invariant on the type Tracker to be violated, for example, by exceeding the capacity of the destination phase or sending the wrong kind of material to the destination phase. Clearly, some restriction must be recorded on the use of the Move function. Such restrictions on functions are recorded as yre-conditions in VDM-SL. The Move function should be augmented by a precondition requiring that permission should be given for the move (and that the removal can proceed from the “from” phase). This is formalized as follows: Move: Tracker * ContainerId * PhaseId * PhaseId -> Tracker Move(trk, cid, ptoid, pfromid) == let pha = mk-Phase( trk.phases(ptoid).contents union {cid}, trk.phases(ptoid).expected-materials, trk.phases(ptoid).capacity) in

mk-Tracker(trk.containers, Remove(trk,cid,pfromid).phases

++

{ptoid

I->

pha})

FORMALITY IN SPECIFICATION AND MODELING

77

pre Permission(trk, cid, ptoid) and pre-Remove(trk,cid,pfromid)

Function definitions of the kind shown so far are explicit in the sense that the value returned by the function is uniquely defined for each input satisfying the pre-condition, if present. In many cases, it is desirable to abstract away from defining a specific result to be returned by the function and instead to provide an implicit function definition which characterizes the result but does not uniquely define it. In the tracking system example it might be necessary to define a function which, given a container’s identifier, returns the phase in which that container is currently located. Rather than defining a function which searches the phases in some order, the result of the search might be characterized as “the identifier of some phase known to the tracking manager with the sought-after container in its contents”. This is formalized by giving a post-condition for the function: cid:ContainerId) p: PhaseId I pre cid in set dom trk.containers post if exists pid in set dom trk.phases & cid in set trk.phases(pid).contents then p in set dom trk.phases and cid in set trk.phases(p).contents else p = Find(trk:Tracker,

Notice that the pre-condition is used to record the restriction that this function should be applied only to a container identifier which is known to the tracker. The conditional expression in the post-condition includes a check that a phase exists for the container, and that a special error value is to be returned if this is not the case.

3.3 State-based Modeling The model expressed so far is functional in style: the functionality is mediated by functions which take “the system” as arguments and may return a “new system” as a result. In many cases, it may be more intuitive to model a system state, with the functionality mediated by operations which take inputs and deliver outputs while having some side-effect on the system state. In this sense, the system state is a collection of persistent variables. For example, the tracking system’s state might be modeled formally using two state variables as follows: state Tracker of containers : map ContainerId to Container phases : map PhaseId to Phase

78

J. S.FITZGERALD

inv mk-Tracker(containers,phases) == Consistent(containers,phases) and PhasesDistinguished(phases) and MaterialSafe(containers,phases) end

The Move function described above would, in this case, be defined as an operation as follows: Move(cid:ContainerId, ptoid:PhaseId, pfromid:PhaseId) ext rd containers : map ContainerId t o Container wr phases : map PhaseId t o Phase pre Permission(rnk-Tracker(containers,phases), cid, ptoid) and pre-Remove(mk-Tracker(containers,phases), cid, pfromid) post let pha = mk-Phase(phases-(ptoid).contents union {cid), phases”(ptoid).expected-materials, phases- (ptoid).capacity) in phases = Remove(mk-Tracker(containers,phases-), cid,pfromid).phases ++ {ptoid 1-> pha})

Here, the operation’s inputs are given in a header and its access rights to the state variables are given in an “externals” (ext)clause. This records the fact that the operation has read-only access (rd) to the c o n t a i n e r s state variable, but has read/write access (wr) to the phases variable. Apart from some necessary syntactic changes, the pre-condition is the same as the functional version, while a post-condition defines the new value of phases in terms of the old value denoted p h a s e s - . The presence of a post-condition makes this operation definition implicit, although the post-condition does define a unique result. Explicit operation definitions are also possible in VDM-SL and these use combinators similar to those found in high-level imperative programming languages.

3.4

Review of the Example Model

Part of a simple formal model has been presented in VDM-SL, based on the larger and more complex model developed on a “real” project. The particular abstractions made in the formal model are guided by the purpose for which it is developed. Abstraction is supported in the modeling language by the use of unrestricted data types such as r e a l , type constructors such as unbounded sets and mappings and implicit function definition. These

FORMALITY IN SPECIFICATION AND MODELING

79

features are found to varying degrees in a wide range of model-oriented languages, including Z [WD96], RSL [RAI92] and B [Abr96, Lan961. Apart from the ability to define functions or operations implicitly, the model presented here does not appear very different from a high-level functional program. What, then, is the contribution of formality in the modeling language? As indicated in section 1, the main contribution of formality is in the ability it confers to perform a wide range of analyses in a consistent manner. The following section presents the major forms of analysis possible on formal models, and, where appropriate, discusses their application to the tracker example.

4. Analysis Techniques for Formal Models What can the engineer learn from the formal model? If the model’s purpose is only to gain a better understanding of a proposed system, then the model must be analyzed in some way, even if only by inspection and discussion. This section begins by presenting three kinds of analysis to which models may be subjected, and then goes on to consider the range of techniques available for conducting such analyses. 4.1

Analyses on Model-oriented Specifications

It is possible to distinguish three forms of analysis for formal models. These are illustrated on the tracking manager example. In each case, we consider the additional information that this sort of analysis provides to the developer.

4.1.1 Internal Consistency As with a model expressed in any language with a formal syntax, it is possible to conduct static checks to ensure conformance to language syntax and static semantics (e.g. scope and type rules). With a formal model, the existence of a formal semantics for the language makes it possible to check certain forms of internal consistency. In the case of the tracker study, this included verifying that partial operators, such as arithmetic division, were protected against application outside their domain of definition; checking that functions respected invariants and, ultimately, that functions or operations were satisfiable in the sense that every collection of inputs satisfying the pre-condition could yield a result satisfying the post-condition or explicit definition. In VDM, certain consistency checks, including

80

J. S.FITZGERALD

satisfiability, are defined as proof obligations: properties of the specification that its author must assure, to a suitable level of confidence before the model can be regarded as completed. An example of an internal consistency check in the tracker example would be the satisfiability of the Move function. This would entail showing that, for any inputs satisfying the precondition on Move, the function’s output is a valid T r a c k e r . This can be stated formally as follows: trk:Tracker; cid:ContainerId; ptoid, pfromid:PhaseId; pre-Move(trk, cid, pfromid, ptoid) Move(trk, cid, pfromid, ptoid) : Tracker

In stating proof obligations formally, we give the hypotheses above the horizontal line and the desired conclusion separately, below the line. The obligation above states that, given any t r k , cid, ptoid and pfromid from the appropriate data types and assuming that the pre-condition on Move holds for these values, the result of applying Move is an element of the T r a c k e r type and thus respects its invariant. In the original tracking manager study, much of the proof effort was devoted to discharging satisfiability obligations. This was a worthwhile activity, because the process of assuring satisfiability revealed subtle deficiencies in the model. For example, the full tracking manager model had rules of containment, allowing some types of container to be held within other types. The satisfiability check on operations to pack and unpack containers revealed inconsistencies in the containment rules. However, satisfiability must be checked every time there is a change to the model, and so this can represent a significant overhead if formal techniques are used to discharge the proof obligation. Knowing that these checks would be performed was an influence on the particular choice of model. For example, the full invariant on the tracker system state was rewritten in a different form simply in order to ease the satisfiability checking. There is a careful choice to be made when restrictions such as safety constraints are recorded in a model. It is often appropriate to record such properties in invariants. If this is done, then showing satisfiability entails showing the preservation of the safety constraints. When a new function is added, the safety properties are once again checked when the satisfiability of the function is assured. If safety constraints are simply recorded as preconditions on functions, then a new function added to the model may or may not contain the necessary pre-conditions an so the preservation of those constraints might not be guaranteed. Thus, the use of an invariant versus a pre-condition has an impact on the effort in checking internal consistency.

FORMALITY IN SPECIFICATIONAND MODELING

4.1.2

81

Validation

This is the process of increasing confidence that the formal model is a faithful expression of the behavior of the system being modeled. As any programmer knows, internal consistency is no guarantee of correctness with respect to requirements. In contrast with internal consistency checking, validation involves a process of interpretation as the formal model is mediated to domain experts who may have no knowledge of the modeling language. In a study with British Aerospace, Larsen et al. [LFI396] reported an increase in the level of client questioning during requirements analysis when a formal modeling approach was used, over a parallel development using informal modeling techniques alone. The question of how to present a formal model in such a way as to get the most effective feedback from a client is an important area of research. Validation plays a particularly important r6le in the development of critical systems. It is often the case that a safety or security property must be shown to hold, to a level of assurance demanded by an external authority or standard. The level of assurance required governs the choice of validation technique employed. In the tracking manager example used in this paper, an example of a very simple validation check would be to ensure that moving a container from one phase to another is detected by the Find function. A first attempt to formalize this check could be as follows: trk:Tracker; cid:ContainerId; pf,pt:PhaseId; post-Find(trk, cid, pf); Move( trk, cid, pf , pt) post-Find(Move(trk, cid, pf, pt), cid, pt)

This states that, given t r k , cid, and phases pf and p t , provided the Find function returns pf as the current phase containing cid,then if Move is performed, Find now returns pt, the phase to which the container was moved. In fact, an analysis using the techniques discussed in the remainder of this section reveals that this statement of the conjecture, although formal, leaves some important things unsaid. It does not guarantee that the Find function can actually be applied to the tracker either before or after the application of Move - it merely checks the post-condition. A more precise statement of the condition is as follows: trk:Tracker; cid:ContainerId; pf, pt:PhaseId; pre-Find(trk, cid); post-Find(trk, cid, pf); Move(trk, cid, pf, pt) pre-Find(Move(trk, cid, pf, pt), cid) and post-Find(Move(trk, cid, pf, pt), cid, pt)

82

J. S. FITZGERALD

On the real tracking manager project, a number of validation checks were performed, relating mainly to desirable emergent properties of the system. As one might expect, such checks often relate to the composition of functions and operations, such as F i n d and Move, whereas internal consistency checks such as satisfiability normally relate to one function or operation at a time. The example, and the full tracking manager study, both illustrate an important point about the validation of formal models: the choice of what checks to perform is at least as important as the performance of the checks themselves. Indeed, the choice of validation check should always be tempered by an awareness of the fact that one is assessing a model and not an implementation. During the real tracking manager project, the validation checks included statements like “Liquid cannot be compacted by the compaction phase.” Such statements did not take proper account of the separation of the tracking manager and the physical system that it was intended to control. No validation check, however rigorously performed, could prevent the compaction of liquid if either the tracking manager was improperly implemented or a failure occurred in the compaction equipment. Formal modeling takes place as part of a larger development process. In the case of the tracker, that process would include overall system design, modeling of communications between tracking managers and plant, and safety analysis of the overall system. System developers are free to choose how much of the system to model, and must keep the limitations of the choice made in mind when drawing conclusions from validation checks performed on the model.

4.1.3 Comparison between Models Internal consistency checking and validation involve the analysis of a single model, but two or more models expressed in the same language may be analyzed for similarities or differences. The classical example of this is the process of formal refinement in which two models are compared, one relatively abstract and the other more concrete. It should be possible to show that the behaviors exhibited by the abstract specification are reflected in the concrete one, via a mapping from the types and operations of the concrete specification back to their abstract counterparts. In the tracking manager example, a refinement to the model could be the representation of the sets of containers in phases by queues of containers. The reason for the modification may be to bring the model closer to a proposed implementation strategy. The data type representing phases might be modified as follows:

FORMALITY IN SPECIFICATION AND MODELING

83

Phase :: contents : seq of ContainerId expected-materials : set of Material capacity : nat inv p == len p.contents <= p.capacity and (not exists i,j in set inds p.contents & i <> j and p.contents(i) = p.contents(j)) and p.expected-materials <> { }

The second part of the invariant has been added to record a restriction that the same container identifier should not occur twice in the contents sequence: this was not required while the contents were modeled as a set. Other modifications may be necessary in the functions; for example, to add a new container to a phase, its identifier must be added to the sequence by concatenation. It is possible to perform checks that the original specification’s functionality is still respected in this new model. Few authors regard the application of formally validated refinement as a practical proposition for commercial software development. This is mainly because of the overheads associated with checking that refinements are internally consistent and faithful to more abstract models. It is also because some requirements are deliberately omitted from abstract models and introduced at later development stages, making it impossible to show complete fidelity to the abstract model. In the real tracking manager study, we were not concerned with the detailed design. The model was developed as a proof of concept and as an inspiration to subsequent design activities; refinement proofs were not undertaken,

4.2

Analysis Techniques

The previous section has outlined various analyses that can be performed on models. The special contribution of formality is in allowing these analyses to be conducted in a rigorous and controlled way. This section examines a range of techniques for conducting analyses on formal models, ranging from inspection and review to formal proof. 4.2.1

Inspection

In common with other design notations, formal models may be inspected as part of the development process, either in design reviews or in a traditional inspection. Inspection often plays an important part in projects applying formal techniques and many studies incorporating inspection note the importance of well-commented and explained formal models, just as with conventional program code.

84

J. S. FITZGERALD

In the Tracking Manager study, reviews were held with the domain experts with the aim of improving confidence in the formal model before proceeding to a formal validation stage in which proof played an important r61e. It became apparent that several issues which later were to complicate the proof work could have been resolved had ease of validation been a consideration. In particular, it would seem constructive to hold at least one review while the principal data types and system state are being defined and that these reviews should be attended by people who are expert in the validation technology to be employed, in this case rigorous proof. The value of the reviews was also limited by the need to convey the formal model to domain experts unfamiliar with the details of the notation. Where the experts were able to see the benefit, such as in the explicit recording of data type invariants, they were able to participate fully in the review. Larsen et al., in their study with British Aerospace [FBGL94, BFL961, extended the training to include all staff participating in reviews as well as development engineers, in order to maximize the number of people familiar with the modeling language in design reviews.

4.2.2 Syntax and Type Checking A formal modeling language has formal syntax and static semantics, permitting models to be automatically syntax- and type-checked as part of internal consistency checking. Almost all formal modeling notations in commercial use are supported by tools which, at the very least, provide basic syntax checks. Many provide levels of type-checking and other forms of static analysis are possible. As with programs, errors reported in a static check may be indicative of deeper semantic errors. The Tracking Manager model was developed using the Adelard SpecBox VDM tools [BFM89] and later syntax- and type-checked using the IFAD VDM-SL Toolbox [ELL94]. The latter tool offers several forms of static checking, including identification of points in a specification where a partial operator may be applied to a value outside its domain of definition. This “definite” type check yields errors at any point where an invariant or other subtyping constraint might be violated, giving the author of the model an opportunity to ensure that each point is protected against the violation, for example by a pre-condition [Muk95]. This form of static check can be seen as an automatic proof obligation generator [AL97b].

4.2.3 Animation and Testing The analysis techniques considered so far are not markedly different from those available to programmers. When testing is considered, however, some

FORMALITY IN SPECIFICATIONAND MODELING

85

differences between programming and modeling languages begin to emerge. Modeling languages have been developed primarily as a means of expressing high-level abstract properties of computing systems, not as efficient implementation languages. They therefore often contain constructs which are not executable. The tracker example makes this clear: the implicit definition of the F i n d function cannot be executed directly: an algorithm for performing the search for a container would be required. Other constructs, such as existential quantification over unbounded collections of values, are also not directly executable. Hayes and Jones [HJ89] stress abstraction as a vital aspect of specification. Fuchs [Fuc92], however, argues that executability, and the ability to test specifications, is often valuable when formal proof is a costly alternative. On the small scale, the availability of an interpreter for a specification language allows the developer to conduct individual tests of functions while the model is under development. A larger-scale testing process is also possible, and it is worth noting that the IFAD VDM-SL Toolbox includes tools to give basic statistics on the coverage of a formal model by a series of tests conducted in a batch testing environment. If a model can be executed, it becomes possible to present its behavior through an interface. One promising approach to bridging the gap between formal modeling experts and domain experts which can hinder validation is to provide an executable model with an interface familiar to the domain expert. A number of studies bear this out, and suggest that testing and proof can be used in a complementary way to good effect. Heitmeyer et al., in developing a formal model of a safety-critical military control system, report benefits from the use of a simulation to validate a software requirements specification described using the SCR method [HKL98]. This was particularly valuable in gaining credibility for the underlying formal model. Agerholm and Larsen [AL97a] present a graphical interface to an executable formal model of the controller for an astronaut jet propulsion pack and claim that testing the model through the interface revealed deficiencies in the model which formal proof did not identify. Testing serves to increase confidence that some property holds in a formal model. As with programs, however, this level of confidence is related to the qualities of the test set used. Exhaustive techniques, capable of exploring all the possible states of a model, would be expected to give higher assurance. Model checking and proof fall into this category.

4.2.4

Model Checking

Model checking (the term is due to Clarke and Emerson [CE811) involves an entirely automatic and exhaustive search of the state space of a model to

86

J. S. FITZGERALD

verify that a desired property holds in each state, or to find a state in which the property does not hold. With a finite state space, this check is guaranteed to terminate. Even for some infinite state-space systems, it may be possible to give a symbolic representation for constraints forming sets of states and thereby construct a finite space for checking. The problem of checking very large state spaces can be alleviated by the use of abstraction techniques to reduce the space size [CGL92], although care must be taken to ensure that the abstraction is sound [BH97]. Model checking in commercial practice has its origins in hardware and protocol verification, but is now being applied ever more widely in software development [CAB+981. A comprehensive review of applications of model checking can be found in the survey by Clarke, Wing et al. [CW+96]. 4.2.5 Proof Formal models, because of their very well worked-out semantics, are susceptible to analysis by mathematical proof. A formal proof is a highly structured sequence of assertions in a well-defined logical language. Each step is justified by appealing to a formally-stated rule of inference. In contrast with model checking, proof can deal with infinite classes of states. However, although it is possible to be very confident about a formal proof, its construction is laborious: proofs about models of computing systems typically require little mathematical insight, but are highly detailed, a characteristic that suggests they are susceptible to machine support. In practice, machine support for the construction of proofs has been rather limited. However, work on the development of proof support tools such as PVS [ORS92] which combine deductive methods with other techniques, such as model checking, are increasing the degree of automation in support of the process. The overheads associated with fully formal proof are still perceived as high, with the result that proof is generally only required for systems developed to the highest levels of assurance. Despite the costs associated with proof, it is still possible to gain many of its benefits through a less formal use of the technique. Jones’ approach, characterized as “formal methods light,” [Jon961 is to utilize a knowledge of proof in checking proof obligations or conducting validation or refinement, without necessarily producing a fully formal proof (unless, of course, the level of assurance demands it). A rigorous proof borrows the ideas of careful structuring and line-by-line justification from formal proof, but relaxes some of the strictures which make the production of a formal proof so costly. Obvious hypotheses may be omitted, abbreviations may be used, justifications may appeal to general theories rather than to specific rules of inference.

FORMALITY IN SPECIFICATION AND MODELING

87

In the Tracking Manager study, validation of safety properties was conducted by means of proof at various levels of rigor. For example, the property that the model precludes movement of containers when this could lead to exceeding the capacity of a phase could be stated as a formal conjecture as follows: t:Tracker; cid:ContainerId; pf:PhaseId; pf in set dom t.phases; pt:PhaseId; pt in set dom t.phases; t.phases(pt).capacity = card t.phases(pt).contents not pre-Move(t, cid, pt, pf)

The structure of the proof of the simple property given above is very straightforward. The format is as follows: From t:Tracker; cid:ContainerId; pf:PhaseId; pf in set dom t.phases; pt:PhaseId; pt in set dom t.phases; t.phases(pt).capacity = card t.phases(pt).contents 1

2 3 4

not (card phases(pt).contents < t.phases(pt).capacity) arithmetic(h7) not Permission(t,cid,pt) defn-Permissionfl) not Permission(t,cid,pt) or not pre-Remove(t,cid,pf) or-I-right(2) not (Permission(t,cid,pt) and pre-Remove(t,cid,pf)) not-and-I-deM(3) Infer not pre-Move(t,cid,pt,pf)

Fold(4)

The “From” and “Infer” lines restate the hypotheses and conclusion. Between them, a series of lines give logical expressions derived by application of rules of inference to the hypotheses and results obtain thus far. For example, line 4 follows by application of one of de Morgan’s laws to the result on line 3. The rule used to justify a line, and a record of the expressions used as inputs to the rule, is shown to the right. The simple presentation of the proof above belies a surprising degree of complexity. Lines 2 to 4 follow by straightforward application of rules. However, lines 1and 2 use more general forms of justification, appealing to the properties of arithmetic inequalities and the definition of the function Permission respectively. The full formalization of line 1 would require an appeal to an inference rule in arithmetic and entail a sub-proof that the

88

J. S.FITZGERALD

expressions being compared by the ‘‘4 operator ’ are indeed numbers. Likewise, the formalization of line 2 requires an appeal to rules of inference derived from the definition of the P e r m i s s i o n function: again these rules will entail sub-proofs that the arguments to the function are well formed. Thus, the production of a fully formal proof of the conjecture can entail considerable detailed subsidiary reasoning. The detailed construction of formal proofs about VDM models is explored in [BFL 941. The Tracking Manager study raised a number of issues surrounding the use of proof in validation: +

0

0

0

Delimiting system scope: As indicated in section 4, the validation conjectures for the tracking manager were sometimes stated in terms of the physical system that the manager was designed to control, rather than the model of the controller. There is a danger of misunderstanding what can be proved: properties of the combined system (controller, interface, and environment) would involve modeling the physical system, the sensors and actuators and communications between them and the tracking manager. Use of proof in model development: The proof work began by revising the model in order to make the proof task more straightforward. As indicated in the discussion of inspection and review above, the contribution of experts in the validation techniques to be used can have an impact on the effort required subsequently to complete proofs. Future work in proof support is likely to see tools emerge that allow the user to combine various sources of evidence supporting the conjecture under analysis: formal proof alongside the results of model checking and even testing. Relationship to Testing: The proof work highlighted deficiencies in the model of the tracker that a test-based approach to validation would not have been expected to detect. Test sets are often based on unwritten assumptions, while the proof process deals only in written hypotheses.

5. Lessons from Industrial Applications 5.1

Some Recent Applications of Formal Modeling

In 1993, Craigen, Gerhart, and Ralston published a detailed study of 12 commercial applications of formal methods technology [CGR93] in regulatory, commercial and exploratory application areas. While they concluded that formal methods are maturing and are being applied to systems of some significance, they concluded that the integration of formal techniques with

FORMALITY IN SPECIFICATION AND MODELING

89

existing software engineering practice is clearly needed. They were also concerned that the tools available to support formal techniques were hampering their adoption because they did not integrate well with existing tools and were often prototype or “academic” in nature. Technological developments in automated deduction, and extensions to encompass real-time, concurrency and asynchronous processes were all envisaged. Since Craigen, Gerhart, and Ralston’s study was published, many other industrial applications have been reported. The Tracking Manager project used as an example in this paper was not dissimilar from many trial studies of the use of formal methods in the industrial context. Its principal conclusion was that the use of a formal notation to construct a model was valuable primarily because of the rigor it brought to the requirements elicitation and analysis process through the ability to record restrictions such as safety properties using invariants. With regard to successful application on a larger scale, the study concluded that a degree of concurrent engineering is required, with validation experts involved in the production and analysis of the model. Finally, in common with many other studies, the trial concluded that robust tool support is essential to efficient validation. However, it also concluded that there are benefits from undertaking rigorous, rather than fully formal, proof unless formality is demanded by assurance levels. Tool support for rigorous proof remains a challenging and largely unexplored area. Reports of the application of formal modeling in commercial practice are now commonplace in major journals and conferences. In order to illustrate the variety of such studies, we consider three relatively recent reports and the trends or challenges that they identify. Hall [Ha1961 reports on the development of CDIS, an application in air traffic control. The project is notable for the use of a variety of formal modeling and analysis techniques, including VDM, each suited to different purposes within the development process. These formal techniques were used alongside other well-established engineering practices. For example, VDMSL was used alongside entity-relationship modeling and real-time structured analysis as part of the requirements analysis. Hall’s review of the project noted some deficiencies in existing formalisms, including difficulties in modelling user interfaces, and also observed that the differences between the structure of a design and the structure of its specification can lead to difficulties in validating the design. Larsen et al. [LFB96] describe the experimental parallel development of a small system by two separate teams, one using formal modeling in addition to normal practice. In contrast to the CDIS development, this development took place in a company with little prior experience of formal techniques. The published data on cost distribution through the project

90

J. S.FITZGERALD

suggested that the costs of their early (system design) phase were raised by about 20-25% as a result of using formal modeling. More importantly, these costs were recovered in saved rework compared to the conventionally developed product. As in Hall’s air traffic control project, the cooperative use of structured analysis and formal techniques proved valuable. This was particularly important because it allowed the modest and limited introduction of formal modeling as an achievable “delta” over existing practice. Supporting the integration of methods, some integration of toolsets was possible: data flow models were accompanied by data dictionary entries and data transform specifications in VDM-SL. The VDM could be extracted and processed by the IFAD VDM-SL Toolbox. Garlan and Delisle [GD95] report on the use of formal modeling to clarify architectural frameworks for a family of instrumentation systems, not a single specific product. Further, there was no attempt to provide provably correct implementations of the models produced. Illustrating the point made in section 3 that the choice of abstractions in a model is governed by the purpose for which the model is developed, Garlan and Delisle sought abstractions that could cover a range of specific products but which could also provide a basis for design. In common with our experience in the tracking manager, the use of proof was limited to exploration of the models and varied in the level of rigor at which proofs were conducted. Building even informal arguments about conjectures identified deficiencies in models.

5.2 Conclusions This paper refers to reports of a small number of studies out of the many now being reported in major journals and conferences. Nevertheless, they illustrate a number of common points that should give industrial practitioners the confidence to conduct trials of their own: 0

0

0

0

Formal techniques can be integrated into the development process via small changes to existing practice, rather than revolutionary change. Crucial to this is the ability to integrate formal models with less formal models, such as the products of structured analysis. Integration of tool support is a prerequisite for such integration. It is possible to use formal modeling techniques appropriate to the development in hand. Studies increasingly indicate that execution and testing of formal models have a place alongside formal proof. Modeling techniques employed in early development stages may pay off in reduced rework costs.

FORMALITY IN SPECIFICATIONAND MODELING

91

Alongside these encouraging findings, it is important to set some challenges. In common with most other software engineering approaches, evidence for the cost-effectiveness of formal techniques needs to be gathered, so that the methods themselves can improve and so that informed choices can be made “on project.” It is not feasible to conduct double-blind “clinical trials” of software engineering techniques, but some evidence collected to date is flimsy and unconvincing [PH97, Fen931. Methods and tools developers must address the need to collect and present data on effectiveness carefully. See, for example, the criticisms levelled at the CICS study [HK9 13 by Finney and Fenton [FF96]. The importance of tool support cannot be overstated. Tools supporting formal techniques are still often “closed” in the sense that integration with tools supporting complementary techniques is not possible or not straightforward. In particular, a continued dependence on subsidiary tools such as editors and compilers that are not widely used in the industry forms a significant barrier to the take-up of formal methods technology. Formal methods are not a branch of theoretical computing science. They are beginning to find a place in the range of engineering techniques that are mature enough to be used in a commercial context. To a great extent this is due to the carefully judged, often modest, application of formal modeling techniques in studies that have involved careful and realistic assessment of costs and benefits. The development of tools and applicable techniques is driven by such studies and it is to be hoped that many more will come to light in the near future. ACKNOWLEDGMENTS Much of the material in this paper stems from discussions and collaboration over several years with Dr Peter Gorm Larsen of the Institute for Applied Computer Science at Odense, Denmark. The author is grateful to Professor Marvin Zelkowitz for comments on earlier drafts of this paper and patience during its preparation. Many colleagues contributed to the work on the tracking manger study, especially Cliff Jones, Ian Cottam and Martyn Spink at the University of Manchester.

REFERENCES [Abr96] [AL97a] [AL97b]

Abrial, J.-R. (1996). The B-Book: Assigning Programs to Meanings. Cambridge University Press. Agerholm, S., and Larsen, P. G. (1997). Modeling and validating SAFER in VDM-SL. Proceedings of the 4th NASA Langley Formal Methods Workshop, September. NASA Conference Publication 3356. Aichemig, B. K., and Larsen, P. G. (1997). A proof obligation generator for VDMSL. In FME97: Industrial Applications and Strengthened Foundations of Formal

92

J. S. FITZGERALD

Methods, (J. S. Fitzgerald, C. B. Jones, and P. Lucas eds.), Lecture Notes in Computer Science 1313, Springer-Verlag, pp. 338-357. [BFL+94] Bicarregui, J. C., Fitzgerald, J. S., Lindsay, P. A., Moore, R., and Ritchie. B. (1994). Proof in VDM: A Practitioner's Guide. Springer-Verlag. [BFL96] Brookes, T. M., Fitzgerald, J. S., and Larsen, P. G. (1996). Formal and informal specifications of a secure system component: Final results in a comparative study. In FME'96: Industrial Benefit and Advances in Formal Methods, (M.-C. Gaudel and J. C. P. Woodcock eds.) Lecture Notes in Computer Science 1051, SpringerVerlag, pp. 214-217. [BFM89] Bloomfield, R., Froome, P., and Monahan, B. (1989). Specbox: A toolkit for BSIVDM. SafetyNet, 5,4-7. [BG80] Burstall, R. M., and Goguen, J. A. (1980). The semantics of clear, a specification language. Proceedings of Advanced Course on Abstract Softwure Specifications, Lecture Notes in Computer Science 86, Springer-Verlag. [BG81] Burstall, R. M., and Goguen, J. A. (1981). An informal introduction to specifications using clear. In The Correctness Problem in Computer Science, (R. Boyer, and J. Moore eds.), Academic Press, New York, pp. 185-213. Bharadwaj, R., and Heitmeyer, C. (1997). Model Checking Complete Requirements [BH97] Specifications Using Abstraction. Technical Report Memorandum Report NRL/MR/5540-97-7999, Naval Research Laboratory, Washington, November. [CAB 981 Chan, W., Anderson, R. J., Beame, P., Bums, S., Modugno, F., Notkin, D., and Reese, J. D. (1998). Model checking large software specifications. IEEE Transactions on Software Engineering, 24(7), 498-519, July. Clarke, E. M., and Emerson, E. A. (1981). Synthesis of synchronisation skeletons [CE81] for branching time temporal logic. Logic of Programs: Workshop, Lecture Notes in Computer Science 131, Springer-Verlag. [CGL92] Clarke, E. M., Grumberg, O., and Long, D. E. (1992). Model checking and abstraction. Proceedings of Principles of Programming Languages (POPL). [CGR93] Craigen, D., Gerhart, S., and Ralston, T. (1993). An International Survey of Industrial Applications of Formal Methods. Technical Report NISTGCR 931626, US Department of Commerce, Technology Administration, National Institute of Standards and Technology, Computer Systems Laboratory, March. 2 vols. [CW '961 Clarke, E. M., Wing, J. M., et al. (1996). Formal methods: State of the art and future directions. ACM Computing Surveys, 28(4) 626-643, December. [ELL941 Elmstr@m,R., Larsen, P. G., and Lassen, P. B. (1994). The IFAD VDM-SL Toolbox: A practical approach to formal specifications. ACM Sigplan Notices, Summer. [FBGL94] Fitzgerald, J. S., Brookes, T. M., Green, M. A., and Larsen, P. G . (1994). Formal and informal specifications of a secure system component: first results in a comparative study. In FME94: Industrial Benefit of Formal Methods, (M. Naftalin, B. T. Denvir, and M. Bertrm eds.), Lecture Notes in Computer Science 873, Springer-Verlag, pp. 35-44. Fenton, N. (1993). How effective are software engineering methods? Journal of [Fen931 Systems and Software, 22 141-146. Finney, K., and Fenton, N. (1996). Evaluating the effectiveness of 2: the claims [FF96] made about cics and where we go from here. Journal of Systems and Software, November. [Fit961 Fitzgerald, J. S. (1996). Two industrial trials of formal specification. In Algebraic Methodology and Software Technology (Proceedings of the 5th International. Conf AMAST'96), (M. Wirsing and M. Nivat eds.), Lecture Notes in Computer Science 1101, Springer-Verlag, pp. 1-8. +

FORMALITY IN SPECIFICATION AND MODELING

93

Fitzgerald, J. S., and Jones, C. B. (1998). Proof in the analysis of a model of a tracking system. In Proof in VDM: Case Studies, (J. C. Bicarregui ed.), Formal Approaches to Computing and Information Technology (FACIT). Springer-Verlag . Fitzgerald, J. S., and Larsen, P. G . (1998). Modelling Systems: Practical Tools and [FL98] Techniques in Software Engineering. Cambridge University Press. Fuchs, N. E. (1992). Specifications are (preferably) executable. Software [Fuc92] Engineering Journal, September, pp. 323-334. Garlan, D., and Delisle, N. (1995). Formal specification of an architecture for a [GD95] family of instrumentation systems. In Applications of Formal Methods, (J. P. Bowen and M. G . Hinchey eds.), Prentice Hall. [GHM90] Guttag, J. V., Homing, J. J., and Modet, A. (1990). Report on the Larch Shared Language: Version 2.3. Technical Report 58, DEC Systems Research Center. [GHW85] Guttag, J. V., Homing, J. J., and Wing, J. M. (1985). Larch in Five Easy Pieces. Technical Report 5, DEC Systems Research Center. Hall, A. (1996). Using formal methods to develop an ATC information system. [Ha1961 IEEE Software, 12(6), March. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of [Har87] Computer Programming, 8,231-274. Hayes, I. J., and Jones, C. B. (1989). Specifications are not (necessarily) exe[HJ89] cutable. Software Engineering Journal, 4(6), 320-338 November. Houston, I., and King, S. (1991). CICS project report: experiences and results [HK91] from using z. Proceedings of VDM9I: Formal Development Methods, Lecture Notes in Computer Science 551, Springer-Verlag. [HKL98] Heitmeyer, C., Kirby, J., and Labaw, B. (1998). Applying the scr requirements method to a weapons control panel: An experience report. Proceedings of Formal Methods in Software Practice '98. Hoare, C. A. R. (1985). Communicating Sequential Processes. Prentice Hall. [Hoa85] Jones, C. B. (1990). Systematic Software Development Using VDM. Prentice Hall [Jon901 International, 2nd edn. Jones, C. B. (1996). Formal methods light: A rigorous approach to formal [Jon961 methods. Computer, 29(4), 20-21 April. Jackson, D., and Wing, J. (1996). Lightweight formal methods. Computer, 29(4), [JW961 21-22 April. Lano, K. (1996). The B Language and Method: A Guide to Practical Formal [La11961 Development. Springer-Verlag. [LFB96] Larsen, P. G., Fitzgerald, J. S., and Brookes, T. M. (1996). Applying formal specification in industry. IEEE Software, 13(3), May. Luqui, and Goguen, J. A. (1997). Formal methods: Promises and problems. IEEE [LG97] Software, January, pp. 73-85. IS0 (1989). Information Processing Systems - Open Systems Interconnection [LOTI LOTOS - A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour. International Standard IS0 8807. Milner, R. (1989). Communication and Concurrency. Prentice Hall. [Mi1891 [Muk95] Mukherjee, P. (1995). Computer-aided validation of formal specifications. Software Engineering Journal, 10, 133-140. [NHWG89] Nielsen, M.,-Havelund, K., Wagner, K., and George, C. (1989). The RAISE language, method and tools. Formal Aspects of Computing, 1,85-114. [ORS92] Owre, S., Rushby, J., and Shankar, N. (1992). PVS: a prototype verification system. Proceedings of the 11th International Conference on Automated [FJ98]

94

J. S. FITZGERALD

Deduction, (D. Kapur ed.), Lecture Notes in Artificial Intelligence 607, Springer-Verlag, pp. 748-752. Pfleeger, S . L., and Hatton, L. (1997). Investigating the influence of formal [PH97] methods. IEEE Computer, February. RAISE Language Group. (1992). The RAISE Specification Language. BCS [RAI92] Practitioner Series. Prentice Hall. RAISE Language Group. (1995). The RAISE Development Method. BCS [RAI95] Practitioner Series. Prentice Hall. Saiedian, H. (1996). An invitation to formal methods. IEEE Computer, 29(4), [Sai96] 16-17 April. Vissers, C. A., Bolognesi, T., Lagemaat, J. v.d. (eds.) (1994). LOTOSphere: [TB94] Software Development with LOTOS. Kluwer Academic Publishers. [VDM96] IS0 (1996). Information Technology - Programming Languages, their Environments and System Software Interfaces - Vienna Development Method Specijkation Language - Part I : Base Language. International Standard ISO/IEC 13817-1. Woodcock, J. C. P., and Davies, J. (1996). Using Z: Specification, Refinement and [WD96] Proof. Prentice Hall. [Win901 Wing, J. (1990). A specifier’s introduction to formal methods. IEEE Computer, 23(9), pp. 8-24.

3-D Visualization of Software Structure MATHEW L. STAPLES Millivision, L.L.C. 29 Industrial Drive East Norrhampton, M A 01060 USA

JAMES M. BIEMAN Department of Computer Science Colorado State University Fort Collins, Colorado 80523 USA [email protected]

Abstract A common and frustrating problem in software engineering is the introduction of new faults as a side-effect of software maintenance. An understanding of all of the relationships that exist between modified software and the rest of a system can limit the introduction of new faults. For large systems, these relationships can be numerous and subtle. The relationships can be especially complex in object-oriented systems that include inheritance and dynamic binding. Software visualization can potentially ease both impact analysis and general program understanding. Software visualization can facilitate program understanding by graphically displaying important software features. However, despite recent success in developing useful and intuitive graphical representations for certain aspects of software, current software visualization systems are limited by their lack of scalability-the ability to visualize both small- and large-scale software entities. This paper demonstrates that three-dimensional (3-D) graphics and a hierarchy of overlapping views can increase the scalability of software visualization. The hierarchy provides detailed information without sacrificing the “big picture.” Overlapping is used to provide context between high- and low-level views. A prototype system, Change Impact Viewer (CIV), tests these visualization mechanisms. CIV highlights areas of a system that can potentially be affected by a change to a selected function. The mechanisms, as implemented in CIV, show improvements in scalability over those provided by other systems, without decreasing usefulness or intuitiveness.

1. Introduction ........................................................ 2. Software Visualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVANCES IN COMPUTERS, VOL. 49 ISBN 0-12-012149-2

95

96 98

Copyright 0 1999 by Academic Press All rights of reproduction in any form reserved.

96

MATHEW L. S T A P L E S AND J A M E S M. BIEMAN 2.1 Software Understanding

........... ......

3. Impact Analysis

107

3.4 Approximation in Impact Analysis 3.5 The “Ripple” Effect. . . . . . . . . . 4. Scalability of Software Visualization 4.2 User Interface Issues

..

5.1 Static Analysis 5.2 Visualization F

6.3 Impact Analysis in CI 7. Conclusions and Future Wo 7.1 Extensions to CIV and Open Problems References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

140

1. Introduction

Throughout a software product’s life cycle, many different people are responsible for understanding the design details of the software code. New engineers face the difficult task of “coming up to speed” on the code before they can do any useful work. Learning the structure of new code is especially costly during the software maintenance phase, since maintenance programmers are often not involved in the original design and implementation. Design documents can help maintenance programmers understand the code, but after several maintenance cycles documents are often out of date and incomplete. Software visualization (SV) is one tool to aid program understanding. In the broadest sense, SV is simply the creation of a graphical model of a software system (or some aspect of a software system). While SV can be done manually by drawing diagrams such as flow-charts, the term “software visualization” usually implies automatic analysis of software followed by automatic creation of a graphical model. With any type of SV, however, the common goal is to facilitate understanding of some aspect of the software.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

97

Several SV systems have been implemented that provide useful and intuitive visualizations of certain aspects of software. A major problem that is common to these systems is a lack of support for scalability. Scalability, with respect to SV, is the ability to visualize both large- and small-scale software systems. The usefulness of most current SV systems tends to decrease as the size of the visualized software increases. This paper presents a method for increasing the scalability of SV through the use of 3-D graphics and a hierarchy of overlapping views. One of our hypotheses is that scalability of software visualization systems can be increased by applying the techniques that are used in cartography to display detailed information about large geographical areas. By using a hierarchy of views, a world atlas can contain views ranging in scale from the whole world down to individual cities and towns. Furthermore, each level of the hierarchy provides a different level of detail; the amount of detail shown in each view is inversely proportional to the scope of the view. Similarly, a software visualization tool that contains a hierarchy of views with multiple levels of resolution should be more scalable than a system that uses only one level of resolution. Also, as in cartography, overlap between views can be used to provide context between different views of the system. Another hypothesis is that the use of three-dimensional (3-D) graphics to display these hierarchical views will further increase scalability. By displaying views in 3-D, a simulated volume is created that provides more virtual space than is available in a 2-D display. Therefore, a 3-D view should appear less cluttered than a 2-D view that contains the same amount of information. Likewise, a 3-D view should be able to show more information than a 2-D view without increasing the amount of clutter. In order to test these hypotheses, we developed a prototype software visualization system that can graphically display useful software maintenance information. In particular, the system is designed to aid in visualizing change impact. Impact analysis (IA) (also referred to as change impact analysis) is the process of determining the potential effects of a software code change [17]. The prototype system, the Change Impact Viewer (CIV), can graphically display a range of impact analysis results using overlapping hierarchies of 3-D views. Section 2 provides some background on software visualization. Criteria are given for evaluation of SV systems and several existing systems are discussed with respect to these criteria. One of these criteria, scalability, is shown to be a common problem in existing systems. Section 3 describes principles of software impact analysis which are used to design the prototype CIV tool. Section 4 discusses in detail the problem of scalability in SV systems and describes the solution we used to design CIV. Section 5 describes the features of CIV and explains how they solve the problems

9a

MATHEW L. STAPLES AND JAMES M. BIEMAN

described in section 4. Section 6 comparing CIV with other existing systems. Finally, section 7 provides some conclusions and gives direction for further research.

2. Software Visualization Sofhare visualization (SV) is defined by Price et al. [16] as “the use of the crafts of typography, graphics design, animation, and cinematography with modem human-computer interaction technology to facilitate both the human understanding and effective use of computer software.” This definition includes both algorithm visualization and program visualization. In an algorithm visualization, a process is shown graphically, usually as an animation. This type of SV requires dynamic information such as can be attained from a run-time debugging program. For the purposes of this paper, SV is taken to mean program visualization, or static software visualization, unless otherwise stated. This type of SV requires only static information, such as can be attained with the front end of a compiler, and generally results in static views of the software system. Additionally, we define the following terms with respect to SV: “software system” refers to the software to be visualized; “programmer” refers to the writer(s) of the software that is to be visualized; “SV system” refers to the software that performs the visualization; “user” refers to the person creating the visualization through the SV system; and “information overload” describes the situation in which a visualization shows more information in one view than a user can easily understand.

’

2.1 Software Understanding SV should not be confused with the study of program understanding, although they are closely related. In SV, visualization is used as a tool to aid in program understanding. The study of program understanding, therefore, provides important background for designing useful visualization tools. Program understanding or comprehension involves the process by which a programmer learns about a software system at the code level. For large systems, this can be a difficult task that requires a large amount of time. Jerding and Stasko argue that the original developers have a mental picture or conceptual model of the software that they will transform into software

’

In [16] this person is called the visualizer, and the user is defined as the person using the resulting visualization to understand a software system. However, in a fully automated system, such as CIV, the visualizer and the user are one in the same.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

99

code [ 101. When other programmers read this code, they formulate their own conceptual model. However, some subtleties and semantic information will generally be overlooked. The lack of detailed understanding of the software can make it difficult to make changes to the software without changing the underlying design. Often, after many cycles of maintenance, the original design of a software system becomes badly obscured. Making changes that do not fit naturally into the original design can make further changes more difficult and will eventually make the software unmaintainable [22]. Jerding and Stasko also point out that the problem of program understanding is particularly difficult in object-oriented software. The objectoriented paradigm, they say, aids in programming and design, but also has the side-effect of making the resulting systems difficult to understand. Consider, for example, the task of tracing a function call. Tracing a call in a C program requires searching for the called function. Programs written in C++, however, may apply dynamic binding. The specific method that gets executed is determined at run-time, and could be any of a hierarchy of virtual functions. Dynamic binding may have been useful in the design, since it allows objects of different types to be treated in the same way, but it makes the code reader’s job more difficult. The reader must try to determine the specific abstraction that the virtual function represents in a variety of situations. A major goal of program understanding research is to determine the learning process that programmers use, so that appropriate support tools can be developed. Several models of how a programmer actually goes about this learning process are discussed by von Mayrhauser and Vans [23]. Some believe that the program understanding process is best described by a topdown model [19]. Programmers first gain a high level of understanding, and then gradually learn the details. This can be done by making hypotheses about the program, and then testing those hypotheses by further inspection of the code. Others believe that program understanding is best described with a bottom-up model [ 151. Programmers build a program model by studying the control flow. “Beacons” are used to group low-level parts into higher-level parts. Beacons are “cues that index knowledge” [23], for example, a reference such as “list->next ( ) ” is a beacon for a linked-list. Programmers also build a situation model which maps parts of the code to the real-world problem domain. Code fragments can be summarized with natural language to help understand the code at a higher level. For example, the code “tmp = *a ; *a = *b; *b = tmp; ” can be described as “swap a and b.” Von Mayrhauser and Vans [23] developed a hybrid model for program comprehension. They determined experimentally that programmers tend to use multiple models, and switch between them frequently. Programmers

100

MATHEW L. STAPLES AND JAMES M. BIEMAN

may start out with a top-down, high-level model, formulate hypotheses about that model, and then switch to a bottom-up approach to test that hypothesis about a particular part of the system. The use of multiple models of program understanding implies that a useful visualization tool for program understanding would present both high-level abstractions and low-level detail of the software system. Additionally, the SV system should support quick context switches between high- and low-level views of parts of the system. Optional static analysis queries would also be helpful for testing hypotheses about the software.

Software Visualization Criteria Computer visualization has been applied in a wide range of fields. Scientists use computer visualization to help understand everything from the structure of a DNA molecule to the terrain of Mars. Only recently, however, has computer visualization been used to visualize software systems. What are some of the reasons for this delay? A large part of the difficulty in providing intuitive visualizations is the lack of physical structure in software. The question immediately arises, “What does software look like?” According to Brooks [ 111, software has no visualizable structure: “Despite progress in restricting and simplifying software structures, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools.” Clearly, active researchers in SV take a less pessimistic view, but creating visualizations that are both useful and intuitive is nevertheless a difficult problem. Another problem common to many SV systems is information overload. A view may seem useful and intuitive for small, simple examples, but may quickly become too cluttered to understand for larger examples. We identify key criteria for evaluating SV systems based on the problems causing slow adoption of existing systems: 2.2

0

0

0

Usefulness: Does the visualization actually make the programmer’s job easier? A useful visualization should provide information that is not readily available by direct inspection of the source code. Intuitiveness: Is the visualization easy to understand? The visualization should match the programmer’s intuition about what the software “looks” like. Scalability: Does the visualization work well for large, real-world systems? The visualization should not become less useful or intuitive as the size of the visualized system increases.

We also look at the scope of SV systems to identify which aspects of the software an SV attempts to visualize. Often, an SV system will consist of

3-D VISUALIZATION OF SOFTWARE STRUCTURE

101

several views which each show specific aspects of the software. Another concern is whether or not empirical studies support the SV system’s usefulness, intuitiveness, and scalability.

2.3 Existing Visualization Tools Despite the pessimistic outlook of Brooks, there has been some reported success in visualizing various aspects of software systems. This section describes some of the better-known systems, and evaluates them based on the criteria given in section 2.2.

2.3.7 HP SoftBench Static Analyzer Hewlett Packard’s HP SoftBench [7] is a multi-user system designed to facilitate program development by incorporating the major software development tasks (program editing, configuration management, etc.) into a single environment. HP SoftBench Static Analyzer [8], which provides static 2-D views of various software relationships, is an integrated part of HP SoftBench. Some of the visualization features of the static analyzer include automatic creation of call-graphs, class-inheritance graphs and fileinclusion graphs. An example of a small call-graph is shown in Fig. 1. The SV features of SoftBench are very intuitive. Graphs such as the callgraph are familiar to most software engineers. The class-inheritance graph is usefu1 since it provides high-level information that is not immediately obvious from direct inspection of the code. The call-graph is also useful in that it enables the user to trace function calls more easily than by searching through the code by hand. This is especially true when the function calls span multiple files. The most powerful feature of SoftBench is its query engine, rather than its visualization abilities. It is primarily a query engine. Queries can be performed on specific identifiers, for example, “Show me all of the uses of variable y.” Results of these queries can then be shown in textual form and in a separate query graph. This type of analysis can speed up the process of testing hypotheses about the software. SoftBench’s SV features would be more useful if they were better integrated into this query engine. For example, it would be useful if the user could select objects in a graph, perform queries based on the selected objects, and then see the results graphically. SoftBench’s SV capabilities are both useful and intuitive for small systems, but they fail to work well for large systems. While the underlying query engine is scalable, the visualization features become less useful as the size of the visualized system increases. This is especially true for the call-

102

MATHEW L. STAPLES AND JAMES M. BIEMAN

FIG.1. A call-graph generated by HP SoftBench Static Analyzer.

graph. For example, Fig. 1 shows only 46 functions. Several other functions are off the screen, but can be seen by scrolling the view. For large numbers of functions, the view only shows a small portion of the entire graph at one time. In many cases, it is impossible to see a calling function and the corresponding called function simultaneously. The number of functions can be reduced by selecting a subset of the total number of functions in the program, but the selection process can be tedious. The other SoftBench graphs are less prone to information overload, since they show only classes or files, and there are fewer classes and files than functions.

2.3.2 lmagix 4 0 Imagix 4D, developed by the Imagix Corporation, contains a sophisticated 3-D code browser. This system is built with Tcl/Tk [14], which is a useful tool for developing X-Windows applications. Tcl is a script language that, together with the Tk toolkit, enables interesting graphical applications to be developed at a higher level than with C or C++. This makes it a good tool for rapid prototyping of SV systems. Figure 2 shows an initial Imagix 4D view for a small application. This graph shows the function, main, at the top of the window. Below main are the functions that main calls (laid out in a grid). Also shown (in the same grid as the called functions) are the data items accessed by the function. In

3-D VISUALIZATION OF SOFTWARE STRUCTURE

103

FIG. 2. Imagix 4D view of function main.

this way, a call-graph and a def/use graph are incorporated into a single view. Selecting a function shows the local call-def/use-graph of the function, and the parent (calling function) of the called function. Selecting a data item shows the data item at the bottom, with all of the functions that access it in a grid above it. A text viewer provides a hypertext code view with pointand-click navigation of the source code (similar to popular web-browser programs such as Netscape). Objects that can be shown graphically are underlined. Selecting these objects changes the main graphical view to focus on the new object, in addition to making a hypertext “jump” to the referenced location in the source code. A user can select between files, classes, or calls for a given view. For example, choosing classes switches the main view to an inter-class relational view. Like the HP SoftBench Static Analyzer, Imagix 4D has some static analysis query features. After selecting a class, a set of queries about that class can be made, such as, “show all super-classes of this class,” or “show all sub-classes of this class.” The query features are better integrated into the visualization system than those of Hp’s Static Analyzer: objects for queries are selected through the display, rather than by typing the name of an identifier in a separate window. Imagix 4D is a useful tool for code understanding, since it allows quick access between structures and their relations. However, it lacks a consistent

104

MATHEW L. STAPLES AND JAMES

M. BIEMAN

view hierarchy. Many different views of a particular object are possible depending on how the object was accessed. For example, if two different functions, A and B, each make a call to a third function, C, and the graph of C is selected through the graph of A, then the parent in the graph of C will be A. Accessed another way, the parent of C will be B. Thus, a user can easily get “lost” while navigating through the system. Imagix 4D is therefore most appropriate for a bottom-up approach to program understanding. Imagix 4D attempts to solve the scalability problem by decomposing the visualized system into small, easily visualizable parts. Each view consists of detailed information about a small part of the system, such as an individual function. In this way, Imagix 4D is capable of visualizing very large systems. Unfortunately, the “big picture” information is lost. Scalability has been increased, but at the cost of usefulness. It is unclear that the visualization of a single function provides more information than the accompanying text display of that function. The user may choose to ignore the graphical display and use only the text-based code browser. Nevertheless, Imagix 4D provides an intuitive graphical means of browsing source code. The tight coupling between the graphical display and the hyper-text code browser increases the intuitiveness of the visualization.

2.3.3 POLKA and Goofy Several prototype dynamic visualization systems have been developed using POLKA [21]. POLKA, or Polka-3D, developed at Georgia Institute of Technology, is an object-oriented system which allows programmers to develop 2 and 3-D animations without needing to be well-versed in 3-D graphics techniques. It provides classes for, “( 1) an entire animation (2) individual views or windows onto the animation (3) the entities which help define a view such as graphical objects and actions or motions.” As such, it is a general-purpose tool that can be used to build many types of visualizations. Goofy, designed at the University of Exeter, is a customization of POLKA which provides an environment for animating object-oriented and procedural features of C+t [6]. Goofy consists of a language with which an animation designer can define objects, define their movements, change their attributes, and choreograph events in multiple windows. Goofy is capable of displaying many types of animations for the same algorithm. For example, Ford conducted an experiment in which programming students used Goofy to create animations of their designs [6]. The students developed a wide variety of representations for the same constructs and algorithms. The results of this experiment were then used to formulate a model for the process of learning object-oriented programming.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

105

Although Goofy and POLKA are very flexible, they do not provide facilities for static or dynamic analysis of source code. Thus they are not fully fledged SV systems, but rather tools that can be used to build SV systems. The user must either create the animations by hand, or develop an automated system on top of them. For example, another system, cppinfo [ 5 ] , also developed at the University of Exeter, uses Goofy to automatically create static and dynamic views of C or C++ programs. Source code analysis was performed using newyacc.

2.3.4 Other Systems Twelve software visualization systems are described in [16]. The following provides a brief description of six selected systems: (1) BALSA shows multiple simultaneous animations of each running program. This was the first program to show multiple algorithms racing on a single display. A later Macintosh version (BALSA-11) included rudimentary sounds associated with algorithm events. (2) Zeus is the latest version of BALSA. Its primary feature is that it can animate parallel programs. Also, the most recent extension uses 3-D views to encode additional information. (3) A N I M , from AT&T Bell Labs, has a simple application programming language for creating animations. The user must insert statements into “interesting points” in the code. (4) The Incense prototype SV system, created by Myers at Xerox PARC in 1980, was the first SV system to automatically produce graphical displays of program data structures. In 1988 Myers developed a related production system called Amethyst at Camegie-Mellon to display both static and dynamic representations of data structures for Pascal programs. Amethyst was later integrated with MacGnome (a Pascal programming environment for Macintosh computers), which is now known as Pascal Genie. Pascal Genie has been used to teach data structures and algorithms. ( 5 ) The University of Washington Program Illustrator (UWPI) automatically provides visualizations for high-level abstract data structures (as opposed to concrete data structures which appear in the implemented code). It contains an “inferencer,” which suggests a number of possible abstractions for each data type found in the code. Each possibility is assigned a weight based on closeness of fit between the operations performed on that data type (in the code) and the operations allowed on that abstract data type. The abstraction with the highest fitness value is then chosen to be displayed. A separate “layout strategist” displays

106

MATHEW L. STAPLES AND JAMES M. BIEMAN

each abstraction in a manner appropriate to that abstract data type. The rule-base used by the inferencer is a good example of the potential use of artificial intelligence in software visualization. (6) LogoMedia allows programmers to associate non-speech audio with program events while the code is being developed. The system uses a Macintosh linked to a MIDI synthesizer. Sound commands can turn on MIDI instruments, play back samples or adjust the sound’s pitch and volume. Empirical studies suggest that this audio feedback may actually be intuitive and useful in debugging. Use of audio feedback is described as auralization; creating a mental picture through audio rather than visual cues. Many SV prototypes have been developed, but few have made their way to industrial use [16], perhaps because of a lack of empirical studies demonstrating real benefits from these systems. Dynamic visualizations such as Zeus and ANIM, can help users to understand algorithms, however, dynamic visualizations tend to be less automated and less interactive than static visualizations. They can be effective in producing presentations or animated documentation of software, but they require the creator of the animation to understand the software. This lack of automation makes many of the current SV systems unsuitable as stand-alone program understanding tools. Static visualizations lack run-time information. Thus, data structures such as linked lists are difficult to recognize statically. Some reasoning about run-time behavior is necessary for the programmer to get a full understanding of the software. These visualization systems exhibit one or two common problems. The visualized information may be obvious from looking directly at the code, so that programmers will not bother using the tool. Otherwise, useful information is shown, but the presentation is not easy to interpret. For example, function views in Imagix 4D show the called functions and the referenced data. For a single function, the code view contains the same information in addition to control-flow information adding context to the calls and references. There is no evidence that the 3-D view provides a better visualization than the hypertext code browser. Conversely, HP SoftBench can show a call-graph for the entire program, but the graph is so large that it is difficult to interpret. Because of scalability problems, most existing static SV systems work well for small, toy examples, but fail to work well for largerscale examples [16, 10,5]. All of the above systems have attempted to visualize software abstractly. The views created by these systems look nothing like the source code that they represent. Ball and Eick [2] have taken a different approach: they have

3-D VISUALIZATION OF SOFTWARE STRUCTURE

107

developed techniques for visualizing the code itself. Their approach begins with a “pretty printed” version of the source code. Color and indentation are used to highlight various source code features such as function definitions and loop constructs. Then, by scaling this view, the text becomes smaller and smaller until the text itself is no longer readable. Although the text cannot be read in this view, the highlighted properties can still be seen. A separate browser window can then be passed over the compressed code view in order to read the code (this works much like a micro-fiche reader). This type of visualization seems to be both intuitive and very scalable. They have been able to visualize systems with over a million lines of code. It is also useful in that metrics, such as the age (time since last modification) of each line of code, can be easily visualized. However, abstract relationships between high-level entities, such as classes, cannot be easily represented in this way. Abstract graphical representations of software entities have better potential to represent design-level information. Also there is no obvious reason why these two, fundamentally different, approaches to SV could not be used together to provide complementary views of large software systems.

2.4 The Need for Scalability Software visualization has the potential to reduce software engineering costs by easing program understanding. In order to realize this potential, SV systems must be designed that are not only useful and intuitive, but also scalable. The usefulness and intuitiveness of an SV system should not decrease as the size of the visualized software system increases. To date, many SV systems have been built, but most have not been widely used in industry. A major reason for this is their lack of scalability. Techniques for visualizing the code itself, such as those developed by Ball and Eick, have shown the ability to visualize large systems, but they also lack the ability to visualize relationships between high-level software entities. Abstract, relational views of software are desirable, but current systems either fail to work for large systems, or decompose large systems into small pieces and thereby lose the “big picture” information.

3. Impact Analysis Our prototype CIV system uses SV techniques to visualize the results of impact analysis. Impact analysis (IA) is defined by Arnold and Bohner [l] as “the activity of identifying what to modify to accomplish a change, or of identifying the

108

MATHEW L. STAPLES AND JAMES M. BIEMAN

potential consequences of a change.” Thus, one component of IA is the determination of the syntactic changes necessary to effect a semantic change. The second component of IA is the determination of the semantic effects resulting from a syntactic change. Since semantic information is difficult to express automatically, neither component of IA appears to be easily automatable. However, the second component can be approximated by determining the area of code in which the semantic effect could appear. That is, if an automated system can identify the parts of the system which are definitely not affected, then the programmer’sjob will have been significantly reduced. For the purposes of this paper, we assume that a desired syntactic change has been specified before any analysis takes place. A related, but separate issue is the problem of actually specifying the change in an interactive system. IA makes use of compiler theory. Many systems use techniques such as dependency analysis and program slicing to obtain information about change impact. Therefore, before discussing any specific IA techniques, the following common definitions from compiler theory, are presented.

Definition 1 A digraph G ‘2 (NG,E,) where N , is a nonempty set of nodes and E , is a (possibly empty) set of directed edges such that E , { N , x N , } . For all (u, v) E E , u is the source and v is the target. Definition 2 A walk in a graph G is a finite, non-null sequence of nodes W‘Y n , , n2, n k such that n iE N , for each i in 1 ... k , and (n;,n i +1) E E, foreachiinl...k-l . . . a ,

Definition 3 A flowgraph G I (N,, E,, no) where (N,, E,) is a digraph and no E N , such that there exists a walk from no to all other nodes in N,. no is often called the initial node. If m and n are two nodes in N,, then m dominates n if m is on every walk from no to n. Definition 4 A hammock graph G %f (N,, E,, no,n,) where both (N,, E,, no)and (AJ,,E;’, n,) are both flowgraphs. E;’ !!! [(a,b)l(a,b) E E , ] . If m and n are two nodes in N,, then m inverse dominates n if m is on every walk from n to n,. Definition 5 A control-flow graph (CFG) for a procedure in a program is a hammock graph in which norepresents the procedure’s entry point, n , represents the procedure’s exit point, and every node m E N , inverse dominates no. Nodes in N , represent program statements, Some procedures have multiple exit points, however, by creating an additional node, all such procedures can be represented by a CFG with a single entry and a single exit node. Definition 6 A call-graph for a program is a hammock graph in which each node in N , represents a procedure, no is the entry procedure (main), and n , is the exit procedure (-exit). Edges in E , represent procedure calls.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

109

Definition 7 A defluse graph DUG 2 (G, C,D , U), where G is a CFG, I: is a finite set of identifiers which name the variables referenced in the nodes of G, and D and U are functions N , -+9 ( C ) where D(n) returns the set of identifiers modified in node n and U(n)returns the set of identifiers used in node n. 8 represents the power set.

3.1 Tool Support for Impact Analysis Given a change to a particular function, one possible method of IA is as follows. The programmer begins by determining the local effects of the change. The programmer will then try to determine if the change could affect other areas of the code. In general, the programmer will search through the code for any indications of a possible undesired side-effect of the change before committing to the change. The programmer inspects functions that call the given function or use the same global or class-member data for potential impact. The inspection also includes functions that are called by the affected function and might execute a different control-flow path because of the change. Any functions found to be affected by the change must, in turn, initiate another phase of analysis. In the worst case, the effect can “ripple” throughout the entire software system. Manual IA is a time-consuming process. Thus, tool support can be very helpful. The simplest type of IA tool support is a keyword search using a text editor, or system utilities such as grep. After finding all initially affected objects, the programmer may need to expand the search one keyword at a time. For example, in order to investigate a defluse chain from a modified variable, the programmer must search for the first defined variable in the chain, then look at at all uses of that variable. This process must be repeated until the programmer is convinced that there are no unwanted side-effects. Not only is this process time-consuming, but it can also be error-prone. Errors can be introduced as side-effects of a modification. More sophisticated IA tools are needed to narrow the programmer’s search, and increase the accuracy of the resulting analysis. Clearly, programmers will benefit from tools that automatically determine the impact of a particular change on a software system. Unfortunately, such a tool requires program comprehension, which is a semantic problem similar to natural language comprehension. Complete IA involves answering fundamental semantic questions about a software system. It is difficult to determine if a change to a function changes its defined behavior in any way, but it is impossible to determine if the defined behavior is the desired behavior without semantic information. For example, a bug fix in a function will change the behavior of that function. If a calling function relied on the previous bug, then it would be negatively impacted by correcting the bug. If,

110

MATHEW L. STAPLES AND JAMES M. BIEMAN

however, the changed function’s desired behavior has not been changed, then the calling function may not be negatively affected. Without natural language interpreters that can read and understand design documents, many important IA questions can only be answered by a human. While no automated system will be able to fully solve the IA problem, there are subproblems which can be automated to greatly ease the maintenance programmer’s task. The results of automated IA systems are therefore approximate. Generally, the result of analysis is simply a subset of the system in which impact could potentially be felt. Conversely, the job of an automated IA program is to “prune” the parts of the system which are definitely not affected by a given change.

3.2 Program Slicing A program slice is the portion of a program that might affect the value of a particular identifier at a specified location in a program [24]. The location and identifier of interest define a slicing criterion. Program slicing is the process of generating a reduced program that only includes the source code that affects or is affected by the slicing criterion. A tool that can determine the parts of a system that can potentially be affected by a change will help to reduce the complexity of the impact analysis problem. Program slicing can determine a subset of a program’s text that implements a specified subset of the program’s behavior. For example, the subset of a program’s behavior that sets a particular variable’s value at a particular point in the control-flow graph will generate a program slice consisting of only the code necessary to produce that behavior. Any parts of the program that the given variable does not depend on can be deleted. The union of all slices of a program is the original program. Given a specific change, a program slice can be constructed based on the changed lines of code. The manual part of the impact analysis can then be restricted to this slice. Program slicing is based on dependence analysis. Dependence analysis is also a primary tool for impact analysis.

3.3 Dependence Analysis Most techniques for impact analysis use at least some aspects of dependence analysis, such as data-flow, or control-flow analysis. For example, a change to a given function is likely to affect those functions which are dependent on the given function. What does it mean to say that one function is dependent on another? Loyal1 and Mathisen [ 121 suggest that a procedure A is dependent on another procedure B if and only if one or more statements in A are dependent on one or more statements in B.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

111

There are several types of statement-level dependencies, and hence there are several types of procedure-level dependency. The three main types are data dependence, control dependence, and syntactic dependence. A statement A is data dependent on a statement B if the value of any variable in A is affected by the value of any variable in B. More precisely, A is data dependent on B if, given a def/use graph DUG = (G, C , D, U), there exists a walk from node B to node A in G and at least one identifier is in both D(B) and WA). A statement A is control dependent on another statement B if the execution of A is dependent on B . There are two main types of control dependence. Strong control dependence occurs when the execution of B can determine if A gets executed at all. For example, the statements in the else branch of an ifthen-else statement are strongly control dependent on the conditional if statement. Weak control dependence occurs when A is strongly control dependent on B and/or the execution of statement B could indefinitely suspend the execution of A . For example, statements which occur after the body of a while loop are weakly control dependent on the conditional of the loop, A statement A is syntactically dependent on another statement B if there is a chain of control and data dependence from B to A . For example, if statement A is control dependent on statement B , and B is data dependent on statement C, then A is syntactically dependent on C. The above definitions assume that the corresponding graphs contain both statements A and B. In the standard definition of a CFG, however, a single procedure is assumed. An inter-procedural CFG is needed to determine statement-level control dependency between two procedures. Similarly, an inter-procedural def/use graph is needed to determine data dependence between two statements in different procedures. Loyal1 and Mathisen introduce the concepts of inter-procedural control-flow and inter-procedural def/use graphs [12]. An inter-procedural CFG is a set of procedural CFGs with added arcs for procedure calls and returns. It is produced by combining procedural CFGs via the call-graph for the program. Each procedure has two special nodes in the graph: proc, and procf The call is made to proci, and the return arc is from procf An important aspect of this is that the calling context is saved in order to ensure that the calls return to where they were called from. For example, if two different procedures make a call to a third procedure, the call and return arcs are ordered such that the first return arc followed corresponds to the last call-arc followed. This correspondence, which mimics the call frames that would be placed on the stack at run-time, makes it possible to include recursive procedures in the inter-procedural CFG. An inter-procedural def/use graph is essentially the same as a procedural def/use graph, except that the procedural CFG which it contains is replaced

112

MATHEW L. STAPLES AND JAMES M. BIEMAN

by an inter-procedural CFG. Unlike the dependence analysis done in [24], variable names and variable instances are distinguished by calling context. This distinction is necessary in order to avoid conflicts between variables that have the same name, but different scope.

3.4 Approximation in Impact Analysis The impact of a change can be either automatic or potential [ 171. An automatic impact is an impact that will unconditionally be caused by a given change. Example changes with automatic impact are changing a procedure’s interface, modifying code which changes a procedure’s return value(s), etc. A potential impact is an impact that could possibly be caused by a given change. For example, a decision point in the control flow can make it impossible to determine statically if a particular branch is actually affected by a given change, Since impact analysis attempts to identify the potential, as well as the automatic consequences of a change, conservative, but safe approximations are often made [13,24,12,1]. Dependence analysis techniques based on compiler theory lead to the view that an IA system should err on the side of completeness. That is, an IA system should not exclude any components of the given software system that can potentially be affected by the given change. Unfortunately, conservative assumptions can lead to an over-estimation of the affected area. The usefulness of an IA system depends on its ability to prune the unaffected areas of the code. One way to do this is to allow the user to manually prune the impact as the analysis proceeds. Automated pruning of IA results remains a difficult problem. Jackson and Ladd [9] hypothesize that human users are more forgiving than compilers and can make use of incomplete results. In their words, we have taken the radical step of trying to maximize the accuracy of our tool’s output by compromising its soundness.” Their tool, Semantic D$f, compares two versions of a program and produces an impact report. By trying to capture the semantics of a change rather than making conservative assumptions about the syntax of the change, the system is able to recognize meaning-preserving changes, for example, renaming a local variable. However, in order to avoid inter-procedural analysis, which they claim is overly time-consuming, the system does make worst-case assumption with respect to procedure calls.

3.5 The “Ripple” Effect A common difficulty in making software changes is the “ripple” effect [l, 17,4]. This can occur in several ways, but the basic idea is that a

3-D VISUALIZATION OF SOFTWARE STRUCTURE

113

change in one procedure can require a change in another procedure which in turn requires changes in other procedures. For example, adding a parameter to a function will necessarily require a change to all calling functions. If those functions do not have the information required to pass this extra parameter, they will need to add a parameter to their interfaces. This type of change can cause a “ripple” of changes throughout the system. By changing a function’s interface, the ripple is initially caused by a syntactic change to the function’s interface. This only causes a required change to the immediate callers of the changed procedure. Determining if those procedures now need to change their interface is a semantic question. This means that dependency analysis alone will not be able to determine the extent of the ripple effect. If conservative assumptions are made, then the result of impact analysis will show the entire call-graph prior to the changed function. Consider the modification shown in Fig. 3. Error checking is added to the swap function to make it more robust. This change could affect all calling processes, since swap now returns a value that was not previously returned. Since it is now possible for swap to fail, it is also possibIe for the callers of swap to fail. The callers of swap may now need to add return values to their interfaces. However, this error condition may never occur since the calling functions always pass in proper values, and it might be decided to ignore the returned value. This is a case in which the potential impact of the change could ripple throughout the entire system, but might not have any real affect that a programmer would be interested in. Now we show how the impact of a change can be effectively visualized through scalability improvements.

Original Code:

Modified Code:

void swap(void *ar void *b)

ErrCode swap(void *ar void *b) {

void *tmp;

void *tmp;

tmp = *a; *a = *be *b = tmp;

if ( a == NULL 1 1 b == NULL) return Invalidparam; tmp = *a; *a = *b. *b = tmp;

1

return NoError;

1 FIG.3. A modification causing a potential ripple effect.

114

MATHEW L. STAPLES AND JAMES M. BIEMAN

4. Scalability of Software Visualization Scalability in software visualization can be improved by using multiple levels of resolution and 3-D graphics. Section 4.1 explains the problem of information overload and how it relates to scalability. Section 4.2 discusses user interface problems that can limit scalability. Section 4.3 introduces the concept of a multi-resolution visualization. This concept forms the basis of the hierarchical viewing scheme used by CIV. Finally, section 4.4 discusses how 3-D viewing can be used to reduce clutter and increase scalability.

4.1

Information Overload

Virtually all SV systems suffer from information overload. A view becoming too complicated or cluttered to be easily understood is generally the result of poor scalability. As programs get larger, more data needs to be displayed on computer screens that provide a fixed and relatively small amount of space. Two classic solutions are (1) scaling the objects to fit more of them on the screen, and (2) allowing the view to take up more virtual area than the screen. Both are partial solutions. Scaling causes objects to become too small to be easily read. Using the second solution, the user must scroll a small view port over a larger virtual view. As the virtual view becomes large, the user cannot observe the larger picture. An extreme example is a digitally scanned painting observed using a scrolling window that shows only one pixel at a time (scaled large enough to see). A user could not recognize the painting simply by scrolling this window around the image. A call-graph is a more realistic example. A call-graph of the entire system can be shown for a system with only a few functions. However, except for very small applications, the number of functions is prohibitively large to display a complete call-graph of an entire application. Compressing a large graph into a single view results in a cluttered, difficult to read diagram. Alternatively, the graph can be spread out over a large virtual space, which can be viewed by scrolling. Then call arcs may extend over large parts of the graph, making it difficult for users to determine where the arcs begin and end. Although such visualization schemes may work well on a small scale, they cease to be useful on a large scale. On a small scale, the single view could provide a “big picture” of an entire system. Unfortunately, as the number of functions increases, the view shows less and less of the complete system. Scaling and scrolling are not the only ways to deal with large amounts of information. Consider scale in a road atlas. A traveler planning a crosscountry trip begins with a map of the entire country. A road map of the entire

3-D VISUALIZATION OF SOFTWARE STRUCTURE

115

country does not show every road, but rather it shows only the major highways. More detail is provided by individual maps of the states, and even more by looking at county maps, city maps, etc. Similarly, a call-graph that shows all of the functions in a large system is analogous to an online road map of the entire country showing every neighborhood street. The information overload in such a view renders the view essentially useless. We propose a solution analogous to that used in maps. A hierarchy of views is created to allow detail to be shown without sacrificing the global, “big picture” information.

4.2

User Interface Issues

To display a subset of a system as a graph, the user must determine the portion of the graph to include. For a call-graph that displays each function as a node, there are two ways to determine this set interactively: the user selects each function individually, or begins with all functions and deletes any functions that are not desired in the graph. Both approaches are supported by HP SoftBench. Either approach can be tedious. Consider again the example of the driver planning a cross-country trip. If the driver has only county maps, he/she must first list all of the county maps needed for the journey. The alternative is for the driver to list all of the county maps that would not be needed. Both solutions are tedious. The process can be improved with an SV system that allows the user to select a single function and then the system generates a call-graph containing all functions which call or are called by the selected reference function (this is the approach used by Imagix 4D). Still, the user may want to know more than one level of call information at a time. This method of visualizing one function at a time provides an isolated view which does not explain how the reference function fits into the system as a whole. Another major problem is that a user who is not familiar with the software may not know what areas of the software are interesting with respect to the problem at hand. Just as a driver cannot be expected to know every county on a route from New York to Los Angeles before determining a higher level route (e.g. a list of states and interstate highways), a programmer cannot be expected to list all of the functions of interest before understanding the system at a high level.

4.3

Multi-resolution Visualization

A hierarchical viewing scheme should help solve the information overload problem. The detail in views can be limited by packaging the system into logical pieces. A hierarchy of views of the system should minimize the

116

MATHEW L. STAPLES AND JAMES M. BIEMAN

user's effort in creating the view and increase the user's understanding of the system as a whole. How can a call-graph be broken into logical pieces? Since software is generally designed at a higher level than that of individual functions, perhaps it should be visualized at a higher level also. Consider software written in C++. The object-oriented nature of the code provides a natural hierarchy which should be reflected in the visualization. Figure 4 shows such a simple hierarchical viewing scheme for a call-graph; Fig.4(a) shows a call-graph containing all functions in a small system, while Fig. 4(b) then shows the same call-graph containing only class-level calling information. For a set of hierarchical views to be useful, each view must make intuitive sense. Does a view using classes as nodes (as in Fig. 4(b)) make more intuitive sense than a view using functions as nodes (as in Fig. 4(a))? The basic idea behind object-oriented design is to view classes as independent entities which communicate through message passing. In practice, message passing is implemented via function calls. A call arc from a class, A, to another class, B, would literally mean that some method in A makes a function call to some method in B. The higher-level object-oriented view is that class A sends a message to class B. So, the class-level view (Fig. 4(b)) better matches the client/server object-oriented model than the call-graph that displayed each function as a node (Fig. 4(a)). Using the nodes to represent classes rather than functions makes the user's job of selecting an initial set of nodes easier. In the previous example the user had to select a set of functions. With a class-level call-graph, the user still needs to select a set of nodes (which now represent classes), but the number of choices has decreased significantly. While the class model aids the understanding the system at a high level, the user still needs to understand implementation details in order to perform actual maintenance on the system. The class-level call-graph does not show

5 ria-i

r ~ , ~ 4

cii\,i

runLJ

Ch.3

lU"'5

CI"4

IU"'?

FIG.4. Using modularity to simplify a call-graph. (a) Call-graph showing all function?; (b) higher-level call-graph qhowing class relationship.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

117

the function-level detail. The user needs a mechanism to move from a highlevel initial view to a lower-level view without displaying all of the functions in the system. Consider again the road atlas analogy. A map of the entire United States will not show city-level detail, but rather, separate views of the details of the cities are available. Because it is often difficult to determine how a separate, detailed view fits into a large-scale view, some maps show in-place intermediate blow-up views. These views help determine how the roads entering and leaving the city match up with separate detailed views. Intermediate views for software call-graphs can be created by expanding classes of interest to show their internal functions (see Fig. 5(a)). Function-level detail can be shown by creating a separate view of the internal methods of a class, or as is shown in Fig. 5(a), by expanding the class in place. The first type of class expansion is useful for showing the intra-class calling relationships, while the second is useful for showing inter-class calling relationships at the individual function level. By allowing multiple levels of resolution to be shown simultaneously, detail can be ignored throughout large parts of the system, and can be included where detail is desired.

4.4

3-D Viewing

Expanding classes in place can cause information overload when several classes are expanded in the same view, The viewing area (“real estate”) in a single two-dimensional display is limited. Any given pair of classes may contain enough methods to fill up the entire view. Three-dimensional graphics techniques help solve this problem. In the physical world, when real estate is limited, high-rise buildings are built. Similarly, the third dimension can be used to show internal details of classes, as shown in Fig. 5(b), without using up additional space in the 2-D plane. Furthermore, the original, high-level view’s layout does not have to be redone to account for each detailed view which be shown. Clearly, since the 3-0 view must be shown on a 2-D screen, the amount of clutter in the view has not really decreased. However, a 3-D view can be rotated interactively, so that the user can see the same view from many different angles. Since the view is contained in a simulated volume, rather than a flat plane, there is conceptually more room in which to show the same amount of information. The expanded classes in Fig. 5(b) no longer show the intra-class call relations; they show the inter-class call relations. Information has been lost in the translation from part (a) to part (b) of Fig. 5 , but a separate intra-class view can be provided. Furthermore, as long as intra-class information is available, it should not be displayed in the high-level inter-class view. The low-level intra-

118

MATHEW L. STAPLES AND JAMES M. BIEMAN

X

FIG.5. High-level call-graph with two classes expanded to show internal detail. (a) In-plane class expansion; (b) Class expansion along a third axis.

class information would distract from the displayed high-level relationships and further clutter the image. Similarly, in a road atlas, multiple blow-ups of major cities are usually available. A blow-up which shows the major routes into and out of the city may be shown in the corner of the state map, while a highly detailed map of the inner city would probably be on a separate page.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

119

Multiple levels of resolution and 3-D graphics are implemented in our prototype CIV system.

5. Change Impact Viewer (CIV) The prototype CIV implements solutions to the scalability problems described in section 4. We provide an overview here; more detailed information can be found in [20]. CIV builds hierarchies of 3-D views in which objects (classes, files, functions, or variables) are related through calls and data-flow. These relationships are shown as arcs between objects on the screen. The user can make change impact queries, such as, “What is the impact of changing the implementation of some specific function?” The system then shows the resulting impact by highlighting the arcs and nodes that might be affected by the change. CIV is an X-Windows/Motif application for analyzing C++ and C programs; it will run on any HP700 workstation. Graphics rendering for CIV is performed by SPHIGS (Simple Programmer’s Hierarchical Graphics Standard [18]).

5.1

Static Analysis

Both the impact analysis and the general visualization features of CIV make use of a static analysis sub-system, using a static analysis class library provided by Hewlett Packard. Static analysis is performed on a static database file. This file is produced with the SoftBench C++ compiler when given the proper command-line flag. Queries, such as finding all calls to a given function, are performed as read-only transactions on the database through the static analysis classes.

5.2

Visualization Features

CIV consists of two primary views which show inter-class and inter-file relations, respectively. From either of these views, a sub-view can be shown which shows the internal details of a specific class or file. Each of the four views can show a call-graph and/or a def/use graph. The interclass view also contains a graph of the inheritance relationships between classes. Color is used to distinguish between graphs-arcs in the call-graph are green and arcs in the def/use graph are orange. All views are displayed in 3-D, and can be viewed from arbitrary angles by moving the view point and orientation via the mouse. In both primary views, classes or files are laid out on the X-Z plane. Classes or files can then

120

MATHEW L. STAPLES AND JAMES M. BIEMAN

be expanded along the Y-axis. (This looks like the example shown in Fig. 5(b).) In this way, different parts of a project can be displayed with different levels of resolution. The basic layout of the primary 3-D views was inspired by previous work by Litau Wu [25]. A prototype system that he developed for a class project used 3-D graphics in a similar way. The class hierarchy was laid out on the X-Y plane, and member functions were shown along the Z-axis. This was used to visualize function reuse through inheritance. A major difference between his project and CIV, is the use of user interaction to dynamically expand or contract parts of a class along the third axis. Call and def/use graphs in CIV are updated whenever the resolution is changed. For example, a call arc exists between two classes if some method in one class calls some method in the other class. One or both of these classes can then be expanded to determine which methods are actually involved in the call. The next two sections describe each of the primary views and their subviews in more detail. They also provide several screen “snap-shots” of various views. Each view is a visualization of the same test system (an early prototype version of CIV).

5.2. I

Class Views

5.2.1.1 Inter-class Relational View The inter-class view displayed in Fig. 6 shows various relationships which exist between classes. Inheritance is shown as blue arcs (when displayed in color) between class nodes. The source of an inheritance arc is the derived class and the destination is the base class (this corresponds to the “is-a” relation, which exists between a sub-class and its base-class(s)). A call or def/use arc entering or leaving a class indicates that the source or destination of that arc is a member of the class. For example, a call-arc between two classes indicates that some method in one class calls some -XFOntSt~“~pXGCValusr -RECTRNGLE

-XmFlIeSelecti~nBaxCalIbackStruct

~ R O T R T E _ I N F O ~ S c r a o n

-POINT

m M R T R I X

w+--

-XChal‘Stwct

-POINTL3U

4

CANVAS-30

FIG.6. Inter-class relation default view. Blue arcs (when displayed in color) represent class inheritance (the “is-a” relationship). The source class is derived from the destination class.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

121

FIG.7. Inter-class view with call-graph shown.

method in the other class. Examples of a call and a def/use graph are shown in Fig. 7 and Fig. 8. Both the call and def/use graphs can also be shown simultaneously, but such a simultaneous display can create a somewhat cluttered view. As mentioned above, the internal parts of a class can be expanded along the Y-axis. Any or all of the following parts of a class can be shown: public data; public methods; protected data; protected methods; private data; and private methods. The given order of these options reflects the precedence in which they are displayed. Those listed first will be shown on top of the ones listed later (i.e. higher on the Y-axis). This order is maintained so that if, for example, the public data of a class is shown first, and then later the protected data is shown, then the public data would be moved up, and the protected data would be inserted underneath. The order is preserved in order to maintain a consistent interface. Figures 9, 10, and 11 show how various parts of classes can be expanded to determine how classes interact at the function level. Call-arcs in these examples are updated as classes are expanded. For example, Fig. 7 shows a call-arc from the GRAPH class node to the GRAPHICAL class node. This means that one or more methods in GRAPH call one or more methods in GRAPHICAL. After expanding the public methods of GRAPHICAL, as shown in Fig. 9, it becomes clear that GRAPH actually makes calls to four different constructors of the GRAPHICAL class. If any call-arc still terminates at the class node after the public methods have been expanded, then there are class methods (protected or private) that are still not shown. -XFontStrucf.rXGCValuc.

*ELTANGLE

-XmFiicSelestronBaxtallbackStrvct

ROTRTELINFO ( I r Screen

mXChaPStvuct

FIG.8. Inter-class view with def/use graph shown.

122

MATHEW L. STAPLES AND JAMES M. BIEMAN

RS_3D*. NODE-TYPE) FilsSslsctionBoxCallbackStruct

CANVAS-3D

IL

FIG.9. Inter-class view with call-graph and one class expanded.

5.2.1.2 Intra-class Relational View The intra-class relational views displayed in Figs 12 and 13 show internal relationships between the methods and data of a class. Method and data nodes are laid out in circles parallel to the X-Z axis. Each circle represents a specific part of the class, such as private data or public methods. The circles are separated along the Y-axis such that public methods are on top, followed by public data, protected methods, protected data, private methods and finally private data on the bottom. 5.2.2 File Views 5.2.2.1 Inter-file Relational View The inter-file relational view, displayed in Fig. 14, shows various relationships between files. The file view is similar to the class view; it groups functions together to form higher-

123

3-D VISUALIZATION OF SOFTWARE STRUCTURE

NODE:

:p s t T y p e ( v o i d )

NODE:

:getPos(u

OINT: :set
OINT::opPrator=(const

POINT&)

OINT::operator/(rnt)

-1ST-ELEMENT

NVRSL3D

FIG.10. Inter-class view with call-graph shown and two classes expanded.

level objects. While the class view more closely matches the hierarchy intended in the original object-oriented design, the file view provides additional information about class are implementation. By using both views, users get a better picture of how design and implementation interact. The file view allows the system to work for both C++ and standard C source code. Information about the source language is contained in the static database file, which enables CIV to distinguish between C and C++ source code. Therefore, CIV can provide the same file views for C source code as for C++ source code, and then simply disable class views for any systems not implemented in C++. Files can be expanded in the same manner as in the inter-class view. Global data, exported functions, and local functions can be displayed. Global data consists of any variables declared in a file’s scope. Exported

124

MATHEW L. STAPLES AND JAMES M. BIEMAN

FIG. 11. Inter-class view with def/use graph shown and one class expanded to show its public data.

functions are those functions whose prototypes are listed in a header file, or are otherwise referenced in other files. “Exported” is used here to mean that the function could be called from another file, but its use is not guaranteed. Public member functions are an example of functions which are exported from the file where they are defined. Local functions are functions that are not made public to other files. These functions cannot be referenced outside

hF~~~~?;i!#*’ NVAS_3D*) GRAPH (CRNVRS-3Dx) RRPH: :zoom ( d o u b l e ) otateZ(doub1e)

\

::lnitializeNodes(uoId) :compareNodeDepth(NODElr.NODEx*)

%

orm(MRTR1Xa)

*GRAPH:

@f!EH:

IGRRPH::height +GRAPH:

gctRWPPEnter *GRAPH:

:l s L a y o u t U p T o D a t s

1GRRPH::arcStorage

*GRAPH::nodeStorage +GRRPH::nodes +GRAPH:

:a r c s

0GRAPH::width $GRAPH: :num odes

:roots

FIG. 12. Intra-class relation with call-graph shown for class GRAPH. This class contains only public methods, private methods, and private data.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

.:

zoom (double)

lizeNodes (uoi d ) compareNodeDepth(NODE**, NODE**)

GRAPH: :w i d t h

FIG.13. Intra-class relation with def/use graph shown. RTRIX::operator=lconst

RIX::operator*(const

MRTRIXe)

POINT-3Ds)

,double, double, dauble.doub

FIG.14. Inter-file view with call-graph shown and one file expanded.

125

126

MATHEW L. STAPLES AND JAMES M. BIEMAN

of the file in which they are defined. As in the inter-class view, the spatial ordering of expanded parts is constant regardless of the order of expansion. Global data is always on the top, followed by exported functions and local functions. Call and def/use graphs can be shown as in the inter-class view. These graphs are also sensitive to expansion of files in the same way that the call and defluse graphs are sensitive to expansion of classes in the inter-class view.

5.2.2.2 Intra-file Relational View The intra-file view shows relationships between the internal functions and global data defined in a specific file. Similar to the intra-class view, function and data nodes are laid out in two circles parallel to the X-Z axis. The top-most circle contains the functions, and the bottom-most circle contains the global data. All other features of the intra-class view also apply to the intra-file view.

POINT: : s e t ( I n t , l n t )

POINT::opsrctor=(conft

POINT&)

POINT::operetor/(int)

POINT::opsrator*(int)

POINT:

:POINT(uoid)

POINT:

:POINT ( & n t , r n t >

UMKEILLESr=, m L I S T - E L E M E N l

FIG.15. Inter-class relation with call-graph and impact shown for a change to the function POINT :: POINT().

3-D VISUALIZATION OF SOFTWARE STRUCTURE

127

5.3 impact Analysis Features CIV can show the results of impact analysis queries. Queries are made by selecting a function, then selecting a change type from a list of possible high-level changes to that function. Change options include adding a parameter to the function’s interface, deleting a parameter, changing a parameter, modifying the function’s return value. A very conservative approach is now used to calculate change impact: the impact is always the transitive closure produced by following the call arcs backwards towards main. Limitations in impact analysis calculations result primarily from the limitations of the static analysis database. Although the impact analysis calculations are now very simplistic, and err on the conservative side, the visualization features of CIV make it capable of showing detailed IA information. Affected portions of the view (the current view in which the IA query was made) are highlighted to show

FIG.16. Inter-class relation with call-graph and impact shown for a change to the function POINT :: POINT( ). An affected class is expanded to show how it is affected internally.

128

MATHEW L. STAPLES AND JAMES M. BIEMAN

*, CANVRS_3D+> PH (FILE*, CRNVAS_3D*)

:display (uoid) ::read

(FILE*) RRPH::zoom(double)

GRAPH:

:mi

tializeNodes { v o l d ) ):compareNodsDepth(NODE**.NDDE**)

form(MATRIX8) "GRAPH:

&?tH:$#dN?$&t.r

*GRAPH: : h e i g h t

+GRRPH::isLayoutUpToDate *GRRPH::nodeStorage

*GRAPH: :arcs *GRRPH::arcStorags

@GRAPH::width

@GRAPH::roots eGRRPH::nodes 9GRAPH::numNodes

FIG.17. Intra-class relation with call-graph and impact shown for a change to the function GRAPH :: initializeNodes0.

impact. In addition, arcs which contribute to the impact are highlighted, so that the user not only knows what has been impacted, but also has information concerning how that impact occurred. For example, in a more sophisticated IA system, the impact might be felt through a def/use relation. In this case, the def/use arcs involved in the impact would be highlighted. Also, several types of impact could be shown by using multiple highlight colors or line styles. Currently, highlighting of objects (nodes) is performed by changing their color to red. Highlighting of arcs is accomplished by changing the thickness of the lines. In this way, the color of the arc-which is used to specify what type of relation the arc represents-is not changed. Figure 15 shows the change impact for a single class method. By expanding the affected classes in this view, the impact will be updated to show how each class was impacted internally as displayed in Fig. 16. Still more detail about the impact can be seen by performing the IA analysis in the internal class view as is shown in Fig. 17.

6. Evaluation of Results We evaluate our solution to the scaling problem as embodied in the prototype CIV system against a set of criteria, and we compare its performance with that of other existing systems.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

129

6.1 Overall Evaluation CIV can currently display classes, files, functions, and data as abstract objects. Four types of views are used to show inter-class, intra-class, interfile, and intra-file relationships. In each view, call and def/use graphs are used to show how objects interact through data and control-flow. The interclass view also contains a class-inheritance graph which shows the “is-a” relationships between classes. Results of impact analysis are shown by highlighting affected areas of the various graphs. Affected nodes are highlighted in addition to any arcs which contributed to the impact. The three evaluation criteria defined in section 2.2 are usefulness, intuitiveness, and scalability.

6.1.1

Usefulness

CTV is useful as a high-level code browser. By starting with the inter-class view, a user can quickly view the entire class hierarchy of the system. Then, by adding the call-graph, the user can view the entire call-graph at a highlevel. At this high level, the user can quickly determine which classes interact directly and which do not. By expanding class nodes, the user can then see how the classes actually interact at the method level. This same type of top-down analysis is not be possible via direct inspection of the source code. The user would have to search header files for class specifications, and then piece together the class hierarchy from the bottom up. Bottom-up code browsing is also possible using CIV. As will be discussed in section 7, a logical extension of CIV is to allow direct access to the source code through method nodes. In this manner, the lowest level of detail can be accessed through the high-level, inter-class view. Also, by opening a separate view for a particular class, the intra-class interaction can be seen. Then, multiple levels of detail can be shown simultaneously, giving the user a better understanding of how the low-level parts of the system interact at a higher level. Section 3.1 describes the usefulness of impact analysis. While the impact analysis features of CIV are not fully functional, the basic design of the system will support the following process. A user selects a node, and suggests one of several types of changes. The system will then show the area of the view which is potentially affected by the change. By highlighting relational arcs which contribute to the effect, the system will also show how the affected objects were affected.

6.1.2 Intuitiveness A qualitative argument demonstrates the intuitiveness of CIV. CIV is intuitive in that it contains call-graphs and def/use graphs which, aside from

130

MATHEW L. STAPLES AND JAMES M. BIEMAN

being displayed in 3-D, are similar to those drawn by hand in many design documents. Nodes are labeled, colored, and distinctly shaped so that the user can easily distinguish between classes, methods, and data. The concept of encapsulation is maintained by showing class methods as being internal parts of the class. Furthermore, classes can be viewed as either closed “black boxes” or expanded sets of functions, matching the basic premise of objectoriented programming-an object should have a public interface and a private implementation. The IA features of CIV are also intuitive. Visual feedback about change impact is more easily understood than the textual report that would be generated by a program slice. The purpose of a program slice is to determine a subset of the code that contributes to a specified subset of the program’s behavior. A visual representation of that subset should be more intuitive than a new version of the source code. In the best case, a visual display would be shown first, and then the text report could be studied. Then there would be some immediate recognition of the subset that the code represents.

6.1.3 Scalability By making use of the natural encapsulation which exists in object-oriented software, CIV is capable of showing full-system views of mediumsized programs. The largest system that has been visualized by CIV is CIV itself, which contains approximately 10,000 lines of code and 60 classes. Figure 18 shows the initial inter-class view for CIV. Note that CIV is currently not capable of distinguishing classes defined in third-party libraries from classes defined in the application code. Therefore, the system being shown in Fig. 18 actually contains about 150 classes. While the view in Fig. 18 exhibits information overload, it can be utilized by the user to gain helpful insight into the system. For example, the view shows that a few classes (e.g. Symbol-second to last row, and fourth from the right) serve as base classes for a wide range of other classes. As the number of classes increases, the inter-class view becomes more complex. However, the intra-class views maintain fairly constant complexity. That is, as systems grow large, the number of classes tends to increase much faster than the size of each class. This growth relationship is especially true when classes are reused. Rather than add new functionality to an existing class, designers may created a new, derived class which adds the new functionality. Figure 19 shows the internal view of a typical class in CIV. The use of the class hierarchy alone has not solved the problem, it has only postponed it. Higher-level grouping is needed to reduce the total number of objects that are shown in a single view. For example, since CIV

3-D VISUALIZATION OF SOFTWARE STRUCTURE

FIG.18. Inter-class view of CIV.

RAPH: :addEdge(NODE*, NODE*) PH::readEdge(ffstre RRPH::GRRPH(vord)

~ Q ~ ~ & & ! @ A( vPoHi d ) writeTo(ofstrearna) const

*GRAPH:

:--vptr

FIG.19. Intra-class view of class GRAPH in CIV.

131

132

MATHEW L. STAPLES AND JAMES M. BIEMAN

contains many small classes which are contained in only a few source files, the file view provides a less cluttered picture of the system. Figures 20 and 21 show a call-graph in the inter-file view for CIV. The use of higher-level grouping is discussed further in Section 7.

6.2

Comparison with Other Systems

The analysis done in the previous section was largely subjective. A more objective analysis can be performed through comparison with other existing systems. In this section, visualization features of CIV are compared directly with those of HP SoftBench for the same input data. A less direct comparison with Imagix 4D is also given, but due to the lack of a full, working copy, this system could not be tested with the same data. Other systems described in section 2 are not directly comparable with CIV due to differences in system capabilities.

6.2.1 HP SofiBench The HP SoftBench Static Analyzer was compared with CIV for two input systems: an early prototype of CIV containing about 2000 lines of code and 15 classes; and the full implementation of CIV. For comparison purposes, CIV generated all of the snapshots in the last section from the small system. We compare these snapshots to those generated by HP Softbench. CIV showed clear advantages in scalability. The

sa.C

FIG. 20. File view of CIV showing call-graph

3-D VISUALIZATION OF SOFTWARE STRUCTURE

_BRR: :newMenu(conzt

char*,aonst

133

char,char)

-BAR::addMenu(PULLDOWN-MENU*)

U_BRR::MENU_BAR(_WldgetRecr.const

char*)

dItern(const char+,_Wid~etClassRec * c o n s L C o n s t char,ci

Item(MENU-ITEM*)

U(_WidgetRec*,const

char+.const

char)

FIG.21. File view of CIV showing call-graph with file menu. C expanded.

figures from CIV show improved scalability and lower information overload than the snapshots generated by HP SoftBench. Figure 22 shows the call-graph and class-inheritance graph created by SoftBench for the small system. The call-graph takes up slightly more than three virtual screens which can be viewed in SoftBench by scrolling. The inheritance relationships between the classes are shown as a separate graph. In Fig. 7, CIV displays the entire class hierarchy in conjunction with a high-level view of the entire call-graph. More detail can then be shown by expanding classes of interest as is shown in Figs 9 and 10. Some scrolling of the image is required to see all of the methods in large classes, but the image can also be “zoomed out” to show the entire graph. In general, more information is shown in less space by CIV than by SoftBench.

134

MATHEW L. STAPLES AND JAMES M. BIEMAN

(4

FIG. 22. HP SoftBench call-graph and class-inheritance graph for small test system. (a) Upper left-hand corner of call-graph; (b)Class hierarchy view.

CIV can also visualize larger systems with less clutter than SoftBench. Compare Figs 18 and 19 generated by CIV with Figs 23 and 24 generated by SoftBench for the same system. Figure 23 shows approximately 3% of the entire call-graph, and Fig. 24 shows approximately 20% of the entire class-inheritance graph. Conversely, Fig. 18 shows about 90% of the entire

3-D VISUALIZATION OF SOFTWARE STRUCTURE

FIG. 23. Part of the call-graph produced by SoftBench for CIV

FIG. 24. Part of the class-graph produced by SoftBench for CIV

135

136

MATHEW L. STAPLES AND JAMES M. BIEMAN

class-inheritance and high-level call-graph view, and Fig. 19 shows 100%of the detailed internal view of a single class. So, while CIV exhibits information overload for the larger system, SoftBench has greater information overload problems. In addition to scalability improvements, CIV has the advantage that it shows the relationships between the call and def/use graphs and the classinheritance graph. With SoftBench it is not as clear how functions are grouped into classes. Also it is not clear how classes relate to each other at a high level, other than through inheritance.

6.2.2 lmagix 4 0 The visualization features of Imagix 4D provide primarily low-level views of functions. Unlike SoftBench, which shows a call-graph for the entire system, Imagix 4D shows the call-graph for only one function at a time. While

FIG.25. File inclusion graph generated by Imagix 4D.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

137

these function-level views are supplemented by the hyper-text code browser, the actual visualization does not provide any additional information. The functions called by a single specific function can be determined by simply reading that function’s code. In contrast, the high-level call information shown by CIV would require scanning the entire system to attain by hand. Class and file relational views are also provided by Imagix 4D. Figure 25 shows a file-inclusion graph produced by Imagix 4D (their class-inheritance graph is similar). Unlike CIV, files or classes cannot be expanded to see their internal methods and data. So, while these graphs provide useful information, it is unclear how they are related to the function-level views. Much like SoftBench, a user cannot easily determine how a particular method fits into the class view. By incorporating multiple relationships into single views, CIV clearly shows the interrelation between the relationships.

6.3 Impact Analysis in CIV The impact analysis features of CIV are not fully functional, because the

HP static analysis database does not contain the necessary control-flow information. High-level control-flow information such as function calling and def/use location is available; however, function level control-flow information, such as order of operation, cannot be determined. Without this level of control-flow information, standard dependency analysis techniques cannot be applied. While some amount of conservative estimation can be made through def/use information within the function, the lack of controlflow information makes pruning of the impact results difficult. CIV provides a solid foundation on which more sophisticated impact analysis systems can be built. Given more fully fledged I A features, CIV could be used both to help understand a system and to make changes with more confidence. For example, suppose a maintenance engineer wants to make a change to a particular return value in a function. Through CIV, he/she could quickly determine the parts of the system that would likely be affected by the change. Some of the affected functions may be expected by the user, but others may be a surprise. Often, effects are propagated in indirect ways that would not be obvious without a visualization tool. For example, suppose a method in class A is modified, and the effect is felt by a method in class B. This method affects another method in class B that in turn affects a method in class C. In this case, CIV would show at a high level that classes A, B, and C are potentially affected. By expanding these classes, it would be obvious how class C was affected through class B. The ability to quickly recognize these unexpected relationships makes CIV a powerful tool for software maintenance. Understanding all aspects of a change can help the user make changes with a minimum of unwanted side effects. In

138

MATHEW L. STAPLES AND JAMES M. BIEMAN

many cases, there are several possible source code changes that will produce the desired-effect. A system like CIV can greatly reduce the effort of choosing between these changes. 7. Conclusions and Future Work Most prior SV systems are not scalable, and thus cannot adequately visualize large-sized, real-world systems. Without scalability, acceptance of these systems by industry will be limited. The use of 3-D graphics together with a hierarchical viewing scheme can provide visualizations that are limited in clutter without sacrificing the amount of information shown. Evaluations using our prototype CIV system support the hypothesis that a hierarchy of views with multiple levels of resolution is useful for increasing scalability. Examples suggest that abstract information, such as the results of impact analysis, can be visualized at a high level for large systems. Quick access to low-level views then provides the missing details. Furthermore, by allowing expansion of objects within a view, in addition to providing separate low-level views, an intermediate level of detail is provided. This overlap of high-level and low-level information adds high-level context to the low-level view. The use of 3-D graphics provides a means of showing more information on the screen at one time. While individual 2-D images from the visualization may appear somewhat cluttered, the user can interactively rotate the view so that the information of interest can be seen clearly. The primary advantage of 3-D viewing is the ability to interactively manipulate the view. Impact analysis remains a difficult problem. Without a high degree of semantic understanding, IA systems can only produce approximate results. Since automated I A systems do not produce exact results, the IA process should be interactive in nature [ 171. Feedback with the user is necessary to prune the potential impact set as the analysis propagates through the system. By highlighting potentially affected areas of the system, our prototype CIV provides quick, intuitive feedback about the potential impact of a change. The user can quickly assess both where and how the impact of a change is felt. This makes it useful as an interactive tool for IA. Additionally, the IA results are intuitive at all levels of resolutions, since they show a subset of the currently displayed graph. This is easily interpreted as the “physical area” affected by the given change.

7.1 Extensions to CIV and Open Problems To visualize very large systems, the hierarchy of views needs to be extended. Systems need to be grouped at a higher level than is currently

3-D VISUALIZATION OF SOFTWARE STRUCTURE

139

supported by CIV. For example, classes can be grouped into logical subsystems. Unfortunately, determining these groups is a difficult problem. Classes that are related through inheritance might not be part of the same logical sub-system. For example, a class might be derived from both GRAPHICAL and LIST-ITEM base classes-logically, the derived class is meant to be part of the graphics subsystem, and not part of the dynamic storage sub-system of which LIST-ITEM is a part. The use of packages as in Java provides a language-defined mechanism for programmers to specify hierarchies of subsystems, which can be used in SV. Another problem with the addition of more hierarchical levels is the lack of additional spatial dimensions for expansion. One solution is to use inplane expansion similar to that shown in Fig. 5(a). Another possibility is to have the option of either expanding the classes in the groups along the third axis, or opening a separate inter-class view for the group. A number of simpler extensions can be added to CIV to make it more robust. First, the layout of classes in the inter-class view does not group related classes together-a simple grid is used. A more sophisticated layout scheme can replace the grid with an organized 2-D layout of the class hierarchy. This layout would increase cohesion in the inter-class view, and increase its intuitiveness. Techniques for this type of layout are described by Bertolazzi, Battista, and Liotta [3]. Second, function-level information could be added. The text of a function could be viewed in a separate text-window by clicking on a function object. The graphical display of CIV could be used to access a hypertext code browser similar to that used in Imagix 4D. This would provide lower-level information than is currently available, as well as a better logical connection between the source code and the visualization. The advantage of this over Imagix 4D is that the visualization would show higher-level information than the code view. Immediate access to the code of individual functions would provide better understanding of the relationships that exist in the higher-level call and def/use graphs. In this way, the code view and abstract visualization would complement each other. Dynamic analysis could also be incorporated into CIV by integration with a run-time debugger. Nodes and arcs could be highlighted as the execution progressed. This would provide high-level information that would not be immediately obvious in a text-based debugger. For example, when tracing into a function with a debugger, it may not be immediately obvious that the code being executed is in a different module or file. It may also not be obvious whether a modified variable is a class member or a global variable. Also, dynamic binding could be shown by highlighting a path through the class hierarchy from the called function to the inherited virtual function that is actually executed.

140

MATHEW L. STAPLES AND JAMES M. BIEMAN

Other simple improvements have been suggested. Curved arcs could be used in situations where multiple relationships exist between two nodes. For example, if two class nodes have both a call arc and an inheritance arc between them, then the inheritance arc could be drawn straight, and a call arc could curve below the plane. This would make it clear that two separate relationships exist between the two nodes. Another suggestion is to encode additional information in the size of the nodes, and thickness of arcs. For example, by making the size of a class node proportional to the amount of code in the implementation of the class (or the number of functions in the definition of the class), the user could quickly see which classes make up most of the system. Also, the thickness of a call arc between two classes could indicate the number of actual calls represented by the arc. Finally, empirical experiments need to be performed to more rigorously test our hypotheses. Experiments need to directly compare the usefulness, intuitiveness, and scalability of CIV with other existing systems. However, since these are highly subjective properties, they can only be measured indirectly. For example, the amount of time needed for an average programmer to become familiar with a new software system using each of a set of tools, can be used to indicate the relative usefulness of those tools. Repeating this experiment with software systems of increasing size would provide an indication of the relative scalability of the tools in terms of usefulness. REFERENCES Arnold, R., and Bohner, S. (1993). Impact analysis-towards a framework for comparison. Proceedings of the IEEE International Conference on Software Maintenance, pp. 292-301. Ball, T., and Eick, S. (1996). Software visualization in the large. Computer, April, pp. 33-43. Bertolazzi, P., and Di Battista, G. L. G. (1995). Parametric graph drawing. IEEE Transactions on Software Engineering, 21(8), 662-673. Duggan, G. (1995). Visualizing C++ programs. Hewlett Packard Application Development White Paper, April. Ford, L. (1993). Automatic S o f i a r e Visualization using Visual Arts Techniques. Research Report 279, University of Exeter, Exeter, UK, September. Ford, L. (1993). How Prograinmers Visualize Programs. Research Report 271, University of Exeter, Exeter, UK, March. Hewlett Packard, (1989). Exploring HP SoftBench: A Beginner’s Guide. Hewlett Packard, (1989). HP SoftBench Static Analyzer: Analyzing Program Structure. Jackson, D., and Ladd, D. (1994). Semantic diff A tool for summarizing the effects of modifications. Proc. IEEE Int. Conference on Software Maintenance, pp. 243-252. Jerding, D., and Stasko, J. (1994). Using visualization to foster object-oriented program understanding. Technical Report GIT-GVU-94-33, Georgia Institute of Technology, Atlanta, GA, July.

3-D VISUALIZATION OF SOFTWARE STRUCTURE

141

[ l l ] Brooks, F., Jr. (1987). No silver bullet. Computer, April, pp. 10-19. [12] Loyall, J., and Mathisen, S. (1993). Using dependency analysis to support the software maintenance process. Proceedings IEEE Int. Conference on Software Maintenance, pp. 282-291. [I31 Moriconi, M., and Winkler, T. C. (1990). Approximate reasoning about the semantic effects of program changes. IEEE Transactions on Software Engineering, 16(9), September. [14] Ousterhout, J. (1994). Tcl and the Tk Toolkit. Addison-Wesley Publishing Company. [ 151 Pennington, N. (1987). Comprehension strategies in programming. Proceedings of the 2nd Workshop on Empirical Studies of Programmers, pp. 100-1 12. [16] Price, B. A,, Baecker, R. M., and Small, I. S. (1994). A principled taxonomy of software visualization. Journal of Visual Languages and Computing, 4(3), 21 1-266. [17] Queille, J-P., and Voidrot, J-F. (1994). The impact analysis task in software maintenance: A model and a case study. Proceedings IEEE Int. Conference on Software Maintenance, pp. 234-242. [18] Sklar, D. F., and Brown, C. (1993). SPHIGS for ANSI-C, v1.0 edition, Computor Science Research Computing Network, March. [I91 Soloway, E., Adelson, B., and Ehrlich, K. (1988). Knowledge and processes in the comprehension of computer programs. The Nature of Expertise, (M. Chi, R. Glaser, and M. Farr eds.), A. Lawrence Erlbaum Associates, pp. 129-152. [20] Staples, M. (1996). Scalability and Software Visualization. Master’s thesis, Colorado State University. [21] Stasko, J. (1992). Three-dimensional computation visualization. Technical Report GITGVU-92-20, Georgia Institute of Technology, Atlanta, GA. [22] von Mayrhauser, A. (1990). Sofhvare Engineering: Methods and Management. Academic Press Inc. [23] von Mayrhauser, A., and Vans, A. M. (1995). Program comprehension during software maintenance and evolution. Computer, 28(8), 44-55 August. [24] Weiser, M. (1984). Program slicing. IEEE Transactions on Software Engineering, pp. 352-357. [25] Wu, L. (1993). A Tool for the Visua[izationof C t t classes, Methods and their Relations. Class Project, December.

This Page Intentionally Left Blank

Using Domain Models for System Testing A. VON MAYRHAUSER Department of Computer Science Colorado State University Fort Collins, CO 80523 USA [email protected]

R. MRAZ Department of Computer Science US Air Force Academy Colorado Springs, CO 8084 7 USA

Abstract Domain models [8, 9,251 have long been used as a basis for software development and reuse. We present a specialized, simplified domain model that has been used for system testing in industry as the framework for a system testing approach we call application domain-based testing. Sleuth, a test-suite generation tool, is based on this concept. We report on the domain analysis, the domain model components, and industrial experience of reusing domain models and tests generated with Sleuth.

2.1 Grammar-based Test Generation. . . . . . . . . . .

...................... .................. 7.1 Domain Reuse . . 7.2 TestCaseReuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVANCES IN COMPUTERS, VOL. 49 ISBN 0-12-012149-2

143

144 145 145 147 148 149 150 153 155 156 171 173 176 180 181

183

Copyright 0 1999 by Academic Press All rights of reproduction in any form reserved.

144

A. VON MAYRHAUSER AND R. MRAZ

8. Conclusions and Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgments ...................................................... References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

186 187 188

1. Introduction The system test is typically the last step before release or beta-test of a software product. System tests examine a software product against requirements and specifications [7,20]. Many testers also derive tests primarily from user manuals. When software development is based on a domain model, the software can be tested using the domain model specification and the specifics of the user interface [3,4]. To analyze, design, and implement a system, developers need detailed domain model specifications, welldefined abstractions, and rules for extending the domain model into new problem domains. In contrast, system testers may not need all features of the domain model and therefore could rely on a subset, especially since system testing is usually “black box.” In addition, when the objective is merely to generate system-level tests rather than automate both test generation and validation of executed tests, the domain model can be further simplified as it will not need information for test validation. This chapter explores the use of a simplified domain analysis technique and domain model as a framework for system testing. The domain model describes semantics of the application that are relevant for testing. It also captures user interface specifics, such as command language syntax or a formal, syntactic model of the graphical user interface (GUI) 1351. We propose a domain analysis technique and an associated domain model for testing software and software/hardware systems with a command language interface. The technique is also applied to a transaction processing system [36] to show that it is suitable for testing telecommunication systems and databases, as well. The purpose of the specialized domain model is to generate tests for a domain while accommodating a flexible set of test objectives. Test objectives are taken into account by building test subdomains and by adding test criteria rules to the test case generation method. Application domuin-bused testing addresses the need of software testers for a tool that supports their thought processes. Test generation addresses three levels of abstraction: the process level (i.e. how the target software commands are put together into scripts to achieve high-level tasks), the command level (i.e. which specific commands are included in the scripts), and the parameter level (i.e. particular parameter values used in command templates). The next section describes the approaches used in software testing. Section 3 introduces a mass storage device which was used in an extensive

USING DOMAIN MODELS FOR SYSTEM TESTING

145

empirical study of application domain based testing. Section 4 presents an explanation of the domain analysis for testing purposes, the components of the resulting domain model, and a model of the domain capture process. The application domain model (including the syntax) is the information the test generation tool uses to generate tests. Section 5 explains the test generation process. Section 6 presents a brief look at the test generation tool, Steurh [39], and the methods it employs [41]. One of the purposes of domain models is their reuse potential. This is no different when a domain model is used for testing. Section 7 explores the reuse potential of this approach to system testing and relates case study data from an industrial application at Storage Technology Corporation (StorageTek). Reuse occurred at two levels, the domain level and the test-suite level. Conclusions summarize our experiences with this system testing approach to date and point to open research questions in the area.

2. System Testing Approaches For systems with a command language interface, system tests consist of sequences of commands to test the system for correct behavior. Similarly, transaction-based or request-oriented systems can be tested by generating transactions or requests. Traditionally, test automation for both command language and transaction-based systems is based on a variety of grammars or state machine representations.

2.1

Grammar-based Test Generation

Grammar-based test generation represents each command using a grammar, generates sentences (commands) from the grammar, and runs the list of commands as the test case (for early work see [32,5]). When generating a test case from a context-free grammar, the generator has to decide which grammar productions to use and which choices within a production to select in deriving terminal symbols (the test case).

2.1.1 Generation Assuring Production Coverage Purdom [32] resolves this through test criteria rules: each production in the grammar is used at least once. In addition, the algorithm prefers short sentences when there is choice. In generating sentences, the algorithm uses two types of information, 0

the production rule to use next on any of the nonterminals so that the shortest terminal string can be derived; and

146

A. VON MAYRHAUSER AND R. MRAZ

the production rule to use next to introduce a nonterminal that also ensures that the shortest sentence is derived which uses that nonterminal in its derivation. The left column of Table I shows an example of a simple grammar for arithmetic expressions [13]. S is the start symbol, (E),( T ) ,and (P)are nonterminals, i,+, T , ( , ) are terminal symbols. The right column shows possible derivations. The last is the one that would be derived with Purdom's algorithm [32]. It is also the only sentence needed to fulfill his testing criterion, as it uses all productions of the grammar. Purdom used this method to test parsers.

2.1.2 Attribute Grammars When using grammars for test case generation, we also need to address command language semantics [6, 11, 15, 231. One way to do this is to use attribute grammars for test case generation [15, 401. The syntax and semantics of the command language are encoded as grammar productions. Test case generation is a single-stage algorithm. Duncan and Hutchison [15] used an attributed, context-free grammar to formally describe classes of inputs and outputs based on a design description for the purpose of generating large classes of test inputs and expected outputs. Test cases should be semantically meaningful. As in other grammarbased approaches, the basic syntax is given in the form of an EBNF (e.g. Table I). To this basic grammar, Duncan and Hutchison [ 151 add additional information to capture sematic rules and expected output. Attributes incorporate context-sensitive information, such as relationships between parameters of a command language (non-terminals of the grammar). When processing attributes, designators assign values to attributes. They are expressed as individual values, ranges, or Boolean conditions. Guards are Boolean expressions used in attribute processing. They can involve inherited attributes of a left-hand side nonterminal, synthesized attributes of symbols TABLEI CONTEXT-FREE

GRAMMAR AND SAMPLE DERIVATION [32]

Grammar

S-,(E) ( E )-j (E) + ( T ) (E)+(T) ( T )4 ( P ) T ( T ) 5 . ( T) - +( P) 6. (f')+((E)) 7. ( P ) + i

I. 2. 3. 4.

Example sentences i+i ( i + iT) i i T i ( i ) T i+i

USING DOMAIN MODELS FOR SYSTEM TESTING

147

to the left of the predicate in a production rule, or the value of the current terminal and any of its synthesized attributes. Also associated with the right-hand side of grammar productions are action routines. They produce the expected output associated with the generated test input (the sentence derived using the grammar). This is called grammar output value. In effect, the attributed grammar provides a partial specification of the system under test. This specification can get quite complex. Not surprisingly, this approach had scaling problems and thus could not be used for large systems [22]. As systems to be tested become more complex, the grammars do, too. This limits performance, but also means that for the average system tester these grammars are difficult to write and maintain and that the generation process does not follow the test engineers' thought processes, particularly in terms of testing goals and refinement of these goals at successive levels of abstraction. In addition, heuristics need to be defined to guide the generation process during sentence derivation in the choice of productions and attributes. Duncan and Hutchison [15] consider this an open problem related to grammar-based test generation. Table I1 shows an example of an attributed grammar to test a sort routine. In the first production, #N is a designator (used for choosing the length of the vector to be selected), the in clause specifies the choices for this selection. @init is the action routine that initializes the expected output (zero for all possible value buckets). sort-input is the nonterminal derived in this production. It is associated with the attribute ( N ) bound through the designator. The second production transforms this attributed nonterminal into the unsorted list by generating N elements in the range of 1. .MAXBUCKETS. As each value is generated, the action routine @put-terminal puts it into the appropriate value bucket. Then the terminal string end-input is generated and the action routine @put-end uses the knowledge of how many elements are in each value bucket to generate the sorted list (the expected output).

2.2

State Machine Based Test Generation

Transaction-based systems and state transition aspects of some other systems have been tested using state machine representations [12, 161. Test TABLEI1 ATTRIBUTED TESTGRAMMAR FORSORTPROGRAM [ 151 1. testcase +[#N 2. sort-input(N)

in O..MAX-N] @init sort-input(N) {N: [ # j in 1. .MAXBUCKETS] "element"(J)

+

@put-terminal(J)} "end-input" @put-end

148

A. VON MAYRHAUSER AND R. MRAZ

generation based on a finite state machine representation includes transition tour [26], W-method [ 121, and partial W-method [ 161, the distinguishing sequence method [ 181, and the unique-input-output method [34]. Their objective is to detect output errors based on state transitions driven by inputs. Not all methods can guarantee finding all transfer errors (i.e. when an incorrect state is reached). Finite state machine based test generation has been used to test a variety of applications, including lexical analyzers, realtime process control, protocols, data processing, and telephony. We use the W-method [ 121 to illustrate this approach to test generation. The W-method assumes a minimal finite state machine with a finite set of states, all of which are reachable, and a fixed initial state. Test sequences consist of two parts p E P and z E Z. P is the set of all partial paths through the finite state machine (including the empty path). P is determined by constructing a test tree. The distinguishing set Z is based on the characterization set W of the design underlying the finite state machine. W consists of input sequences that distinguish between every pair of states in the minimal automaton. Sequences in 2 consist of a sequence of characters from the input alphabet of the finite state machine that can be as long as the difference in states between the design and the minimal finite state machine. They end with a character from W. The resulting test sequences (and the associated outputs according to the finite state machine) are executed and the finite state machine output is compared to the actual output. Test sequences can detect output or transfer errors, given some restrictions on the number of states in the implementation. The partial W-method [ 161 improves over the W-method by reducing the length of the test suite. It does so by reducing the characterization set W to subsets W, for specific states i. State machine representations work well for generating sensible sequences of command types, but become cumbersome for generation of both sequencing as well as command details of systems with large and intricate command languages.

2.3

Frequency-based Test Generation

Automatic generation, whether based on grammars or state machines, requires making choices during the traversal of the representations. The choices are due to ambiguities as well as the purposeful inclusion of options in the representation. Choice is directed by incorporating selection rules of various types. As mentioned earlier, Purdom [32] integrates “coverage rules” for grammar productions to reduce choice. Maurer [27, 281 uses probabilistic context-free grammars that are enhanced by selection rules including permutations, combinations, dynamic probabilities, and Poisson distribution. The following is an example of a production that includes

USING DOMAIN MODELS FOR SYSTEM TESTING

149

frequency rules for value selection: bnumber + %32bit bit: 31 : 1, 1 : O

This production states that when deriving from the nonterminal bnumber the nonterminal bit is generated 32 times. When choosing a terminal value for each nonterminal bit, the value 1 is to be chosen 31 times more often than the value 0. Like [15], Maurer [27,28] also allows action routines to compute expected output of the test. In all these methods, selection is based on making choices relating to the representation of the command language or state machine.

2.4

Partition Testing

Alternatively, one can argue that choices should be made depending on the functional characteristics of the system. Functional testing according to [30] uses heuristic criteria related to the requirements. Each requirement is identified, related to a (set of) commands, and valid, boundary, and invalid cases are tested. So are heuristically determined combinations of commands. The method is manual.

2.4.7

Goodenough and Gerhart 17 71

Goodenough and Gerhart [ 171 suggest partitioning the input domain into equivalence classes and selecting test data from each class. In this approach, we divide possible input values into equivalence classes based on common effect. It is enough to test one input from each class. Classes can be subdivided further by including other criteria, such as executing the same portion of the code, or being part of the same algorithm, although this is no longer black-box testing as it would include knowledge of how functions are designed and implemented.

2.4.2 Category-partition Testing Category-partition testing [2,311 accomplishes this by analyzing the specification, identifying separately testable functional units, categorizing each function’s input, and finally partitioning categories into equivalence classes. Category partitioning starts with the functional specification, then goes through a series of decompositions of items and inputs that are related to the specifications to the level of individual subprograms to be tested. The first level of decomposition identifies functional units (e.g. a top level user command). The next step identifies parameters and environment conditions

150

A. VON MAYRHAUSER AND R. MRAZ

that affect functional behavior. Next, careful reading of the specificationidentifies categories of information that characterize each parameter and environment condition. Each category is partitioned into distinct choices (possible set of similarly treated values). These choices form the partition classes. Choices can be annotated with constraints to model relationships between categories. While the analysis is manual, a generator tool produces test cases from these (constrained) partitions. To avoid too many error test cases, choices can be marked [error],in which case they do not get selected, unless error recovery testing is a test objective. Others can be marked [ sing1 ] to avoid combining them with choices from other categories. Table I11 [31] shows an example of a test case with choices identified for a command that looks for patterns in a file. The left column identifies the category, the right identifies the choice selected for the category. Substituting values for each choice produces the test input. Richardson et al. [33] consider these approaches manual, leaving test case selection completely to the tester through document reading activities. Further, partition testing as a testing criterion does not guarantee that tests will actually uncover faults [ 19,38,45]. From a practical standpoint, a better approach is to combine different test generation methods with a variety of testing criteria. Examples are to combine exhaustive generation of some commands or parameter values with probabilistic or combinatorial criteria for others, which requires flexible command generation methods.

2.5 Al Methods in Test Generation 2.5.1 Planner-based Test Generation So far, few approaches to system testing use artificial intelligence methods. The most relevant is Howe et al. [21] which uses an A1 planning system (UCPOP) to generate system tests (black box testing). TABLE111 EXAMPLE TESTCATEGORIES AND CHOICES [31] Category pattern size quoting embedded blanks embedded quotes file name no. of occurrences in file pattern occurrences on target line

Choice many characters pattern is quoted severa1 one good file name exactly one one

USING DOMAIN MODELS FOR SYSTEM TESTING

151

The planner generates test cases in three steps: generate a problem description, create a plan to solve the problem, and translate the plan into test case notation. These three steps correspond to three modules: preprocessor, planner and postprocessor. The preprocessor develops a problem description based on user directions. The problem description consists of a problem name, domain knowledge, an initial state and a goal state. The problem name is generated automatically. The domain knowledge describes the command language semantics. The initial and goal states define the specific needs of a particular test case. The preprocessor incorporates knowledge about how command language operations relate to changes in the state of the system. The user indicates how many of the different types of operations should be included in the plan. Based on knowledge of the test domain, the preprocessor creates an initial state and goal state description that would require using the indicated commands. The initial state also includes information about system configuration and initial state information. The configuration information is taken directly from the knowledge base and the initial status information is randomly generated from the problem constraints. The planner constructs a plan to transform the initial state into the goal state. If a plan cannot be found within a set amount of time, the planner fails. In this case, the preprocessor generates different initial and goal states that satisfy the user’s requirements. The postprocessor translates from plan representation to command language syntax. The transformation is purely syntactic and straightforward. TableIV summarizes representation of domain knowledge in the A1 planner. The results are encouraging, in that the planner was able to come up with novel tests. Generation speed, and with it scale-up, are an issue. Possible further work to remedy this include investigation of hierarchical planning methods or subsumption as in CLASP [14].

2.5.2 CLASPI141 CLASP uses terminological plan-based reasoning to generate test scenarios and test scripts. This approach combines plan-based reasoning with regular expression processing. Subsumption helps to manage large collections of plans. CLASP implements a general approach for both plan synthesis and plan recognition. Testing is only one of its possible applications. Consequently, it does not include any guidelines or process how to derive a CLASP description for testing purposes.

2.5.3 KITSS KITSS [24] is a knowledge-based translation system for converting

152

A. VON MAYRHAUSER AND R. MRAZ

TABLEIV DOMAIN KNQWLEDGEAND A1 PLANNER REPRESENTATION [21] Domain knowledge Command sequencing rules Parameter binding Command language syntax

Command preconditions Command postconditions Parameter constraint rules

(within same command)

Planner representation Operator preconditions Operator effects Operators: One operator for each “path” in a command Postprocessor: translates planner output into command language syntax. Operator preconditions Operator effects Preprocessor: initial state generator Preprocessor: goal generator Preprocessor: supporting data structures Operator preconditions

informal English scenario descriptions of desired system behavior (informal test descriptions) into formal executable test scripts. Its premise is that language used in informal test scenarios is not really standard English, but a stylized technical subdialect and thus amenable to automated or at least machine-assisted natural language processing. In doing so, the translation system must also bridge abstraction gaps between the goal-oriented intent of the testers when writing informal test scenarios, and the specifics required in executable scripts. In addition, informal scenarios can have other problems such as missing steps, hidden or implied effects, underspecification, missing initialization and boundary conditions, and erroneous statements. KITSS includes a knowledge base describing telephony testing. Converting the English scenario into intermediate form (WIL) is accomplished with an adaptive statistical parser and a rule-based phrase converter. The statistical chart parser computes probabilities to rank alternatives due to grammatical ambiguity. User input adapts the parser to learn and define previously unknown language constructs. Scenario understanding and analysis is done on the intermediate representation (WIL) with the aid of a coarse black-box simulation of a telephone switch, a telephone domain theory, and a library of typical phone usage patterns. Table V shows an example of a test scenario as written by the tester and the corresponding WIL language statement (Kelly and Jones [24] do not provide the corresponding executable test script). This is a viable technique for translating some English documents into an intermediate language and from there into executable test scripts. This technique requires that relevant information in English is available. It also requires building a domain theory of the application that is fairly

USING DOMAIN MODELS FOR SYSTEM TESTING

153

TABLE V BEHAVIOR SCENARIO AND CORRESPONDINGWIL STATEMENT Scenario WIL

Place calls to station B3 and D1 and make them busy Busy-out station B3 Busy-out station D1

sophisticated. It does not handle graphical descriptions like syntax diagrams. Following a similar philosophy, Zeil and Wild [46] describe a method for refining test case descriptions into actual test cases by imposing additional constraints and using a knowledge base to describe entities, their refinements, and relationships between them. This is considered useful for test criteria that yield a set of test case descriptors which require further processing before usable test data can be achieved.

2.5.4 Neural Nets Automated test case generation can easily generate tens of thousands of tests, particularly when random or grammar-based methods are chosen. Running them takes time. To avoid running test cases that are not likely to reveal faults, a neural net has been successfully trained as a filter [ 13. After a subset of generated tests has been run, results indicate whether or not the test revealed a fault. The neural net is trained on test case measurements as inputs and test results (severity of failure) as output. This is then used to filter out test cases that are not likely to find problems. The results are encouraging for guiding testing.

3. Industrial Application-Robot Tape Library System testing based on a domain model has many applications. Experience with this testing approach spans a wide range of application domains. They include: mass storage devices at StorageTek (HSC, IXFP, Snapshot), a database query/update system for cable television and generation of SQL code, USWEST’s personal voice messaging system 1361 and a spacecraft command and data handling application [43]. StorageTek produces several mass storage devices for mainframes and distributed workstation environments. Access to the mass storage devices is through a command language. System administrators use commands to configure the mass store, set up volume libraries, and control device access. End-users access data, set up personal volume libraries, and configure their

154

A. VON MAYRHAUSER AND R. MRAZ

storage through command line requests. The Automated Cartridge System (ACS), a mass store for tape cartridges, and its Host Software Component (HSC)serve as the primary example [37]. The ACS maintains magnetic tape cartridges in multi-sided “silos” called Library Storage Modules (LSM). Each tape holds 350 megabytes. The ACS product line offers several LSM sizes ranging from small (6 feet tall, 8 feet in diameter) to large (7 feet tall, 12 feet in diameter) models. Inside the largest LSM, storage panels on inner and outer walls contain up to 6000 cells for tape cartridges. System operators enter and eject tapes through a Cartridge Access Port (CAP). A vision-assisted robot moves tapes inside the LSM. The robot effector houses a bar code reader, an optical vision system, and gripper sensors. All three sensors are used to identify tapes, pick up tapes, place them in cells, mount them in tape transports (tape drives), dismount tapes, and move them to/from the CAP. Control hardware for the LSM and robot and tape transports are housed outside the LSM. Tape transports are high speed tape drives that transfer data to/from the tapes. Figure l(a) shows a single LSM with tape drives, access port, and control unit. One Automated Cartridge System supports from one to sixteen silos. Figure l(b) presents a top-down look at an ACS with three LSMs. Tapes move between LSMs through pass-through ports. The silos in an ACS can be physically arranged in a variety of ways. Figure 2 shows some of the possible configurations of five LSMs. The ACS and its components are controlled through a command language interface called the Host Software Component (HSC).Each HSC supports from one to sixteen ACS systems. HSC commands manipulate cartridges, set the status of various components in the system, and display status information to the operator’s console. The command language consists of 30 commands and 45 parameters. Typical customers for mass storage systems like the ACS include financial institu-

Library Storage Module lLSMi

FIG. 1. Automated cartridge system with three LSMs [37].

USING DOMAIN MODELS FOR SYSTEM TESTING

155

FIG.2. Possible physical configurations of five LSMs.

tions, Internal Revenue Service, Social Security Administration, spacecraft ground station operators, and weather researchers. 4.

Building the Domain Model

Depending on whether the software to be tested already exists or is still under development, two possible ways exist to analyze a domain for system test: a priori domain analysis and reverse engineering domain analysis. A priori domain analysis develops the domain model as part of the functional specification phase of software development. Reverse engineering domain analysis, on the other hand, assumes that the software and its user manuals or functional specifications exist and develops the domain model based on that information. A priori domain analysis starts with domain objects, object attributes, their relationships, their actions, and rules for proper action sequencing (cf. Table VI). The last step is to represent the command language syntax. Syntax and some of the system specific values are the only parts of the application description that change between systems. Table VI indicates this by separating command language syntax from the remainder of the model with a double bar. Reverse engineering domain analysis develops the domain model starting with the syntax, adding semantic elements at each step, abstracting the objects and their behavior. Since many testers develop their tests after the software exists, rather than with the functional specifications, the latter is used more often. These domain models for testing are simplified versions of a complete domain model that could be used for software development. When syntax

156

A. VON MAYRHAUSER AND R. MRAZ TABLEVI STEPS IN A PRIOR1 DOMAIN ANALYSIS

Analysis step

Model component, data fields

Identify objects

object list for object glossary name, description Object element glossary name, definition, values, representation

Characterize object elements Associate object elements with objects

Determine actions and action classes on objects and object elements

Identify relationships between objects Determine constraint rules for object element values Identify preipostconditions for actions

Command language syntax

Object glossary entries for associated object elements by type parameter: attribute, mode, state nonparameter: event, state Object element glossary entry for associated object Action table command name, object elements necessary Object glossary list of commands using an object Script class table class name, list of command names Object hierarchy Object element inheritance rules Intracommand rules Scripting rules Object element value binding rules

EBNF or syntax diagrams

information is included, one could also consider them very rudimentary functional specifications with just enough information to generate semantically meaningful tests. In and by themselves, these domain models do not prescribe any specific testing criteria. This is intentional as system testers use a variety of strategies during a testing cycle. Thus a domain model for testing should be flexible and adaptable to a variety of testing objectives, from functional to load testing. Separating the domain model from how it is used during test generation provides this flexibility. The domain model provides the framework for what is to be tested, test criteria applied during test generation determine how testing is to be done. 4.1

A Priori Domain Analysis

Table V1 shows the steps in the a priori domain analysis. The first step identifies physical and logical objects in the problem domain. Following object-oriented analysisldesign (OOA/OOD), analysts apply a variety of methods to identify objects [lo]. The analyst can use any of the existing

USING DOMAIN MODELS FOR SYSTEM TESTING

157

OOA approaches to identify objects. The difference between 00A/OOD and this approach is in the level of detail and the type of operation. Application domain models for testing do not need as much information as is necessary for implementation. This specialized domain analysis for testing focuses on requirements documentation and its further analysis for object identification. Consider the StorageTek HSC-ACS robot tape library. Cartridge tapes, tape drives, and tape silos are objects germane to this application domain. Objects included in the model control or manipulate the application, or are obvious parts of the system. Table VII shows a list of all objects for the HSC-ACS domain. TABLEVII OBJECTS IN THE ROBOTTAPELIBRARY DOMAIN Object

Abbreviation

Description

Host Software Component

HSC

Operating system software used to control the robot tape library Online documentation Operator’s console A collection of one or more LSMs Set of scratch cartridges Commands robot A single “silo” where cartridges are stored Storage medium Contains volume information about all cartridges Reserved area for cartridges during LSM initialization Access door between LSMs Tape drive that reads/writes cartridges Racks located inside an LSM. Used for cartridge storage A special door to enter and retrieve cartridges A column of cartridge locations on the PTP A row of cartridge locations on a panel A column of cartridge locations on a panel A row of cartridge locations on a CAP A column of cartridge locations on a CAP

Documentation Console Automated Cartridge System Scratch Pool Library Management Unit Library Storage Module Cartridge Control Data Set

ACS LMU LSM CDS

Playground Pass-Through Port Tape Transport Panel

PTP

Cartridge Access Port

CAP

Pass-Through Port Column Row Column CAP Row CAP Column

When functional specifications are available, the command language has already been specified and the reverse engineering domain analysis described below is appropriate.

158

A. VON MAYRHAUSER AND R. MRAZ

Next, object elements define qualities and properties of the object. Object elements are similar to the concept of object attributes in 00A/OOD [lo]. Object attributes and object elements differ in the amount of information that is described, because test generation does not need as much information about an object when compared to the amount of information needed for implementation. Object elements often identify an object, its state or operating mode, or its value. These attributes may be user controllable or not. In the first case, they will eventually become parameters in the command language; in the latter, they describe the effect of system operation on objects (events, states). This gives rise to the concept of object element types. Application domain analysis classifies object elements into one of five mutually exclusive categories as shown by the leaf nodes in Fig. 3. The first level of classification determines whether the object element is controllable by the user or needed to submit requests to the system. These object elements will eventually be parameters of the application’s command language. Object elements related to command language parameters can be parameter attributes, mode parameters, or state parameters. A parameter attribute uniquely identifies an object. Mode parameters set operating modes for the system under test. State parameters hold state information for the object. For example, an operating mode may be “verbose” or “quiet.” A parameter state may be “tape drive A and B operational, use of C and D reserved.” Object elements which, while crucial for describing system operation, are neither controllable nor immediately visible to the user, are classified as nonparameters. They can be important for test case generation. A nonparameter event is an event caused by the dynamics and consequences of issuing a sequence of commands. A nonparameter state is state information that cannot be controlled through the command language. For example, a tape

FIG.3. Object element classification.

USING DOMAIN MODELS FOR SYSTEM TESTING

159

silo may become full as a consequence of system operation. We neither set a tape silo to f u l l with a command, nor do we need to use the state of the tape silo in a command. At the same time, one cannot load any more tapes into a full tape silo. This affects test generation. For example, for testing regular system operation, generating further tape loads after the silo is full does not serve a purpose. On the other hand, when testing error recovery, one would want to generate further loads into a full silo. Table VIII shows all object elements of the parameter attribute type for each object in the HSC-ACS. Table IX gives a subset of possible user-controllable operating modes. Table X lists possible types of new states for objects of the HSC-ACS that can be set by the user. Finally, Table XI lists an object glossary entry for the LSM object with all object element entries relevant for this object. The next step associates object elements with possible values in the domain. These values may have to be restricted further for particular system configurations and setups for the software under test. A glossary stores detailed information about each object element. An automated test generation tool must know the range of values for each element, the representation of each object element, and the default set of values for each object element. This information is needed for parameter value selection during test case TABLEVIII PARAMETER AITRIBUTESIN THE ROBOT TAPE LIBRARY DOMAIN Object Host Software Component Documentation Console Automated Cartridge System Scratch Pool Library Management Unit Library Storage Module Cartridge Control Data Set Playground Pass-Through Port Tape Transport Panel Cartridge Access Port Pass-Through Port Column Row Column CAP Row CAP Column

Attribute-id host-id msg-id console-id acs-id subpool-name station Ism-id volser dsn playgnd-cc ptp-id drive PP cap-id ptp-cc rr cc cap-n cap-cc

Explanation Host identifier Message identifier Console identifier ACS name Name for set of scratch tapes LMU name LSM name Cartridge name Data set name Name of playground column Pass-through port name Tape drive identifier Panel number CAP name Identifier for pass-through port column Row number Column number CAP row number CAP column number

160

A. V O N MAYRHAUSER AND R. MRAZ

TABLE IX MODEPARAMETERS IN THE ROBOTTAPELIBRARYDOMAIN Object Host Software Component

Mode baltol

Scratch redistribution level

comp-name

HSC component for which tracing is enabled/disabled Deferred mount processing On tape dismount: automatic or manual deletion of volume from control data set Automatic or manual deletion of duplicate volume New home cell possible on tape pass through or not Operating mode when journal becomes full Time interval between checks of number of scratch cartridges Threshold for warning when scratch pool becomes low Maximum number of cleans allowed Whether to scroll messages on operator screen Upper or lower case Automatic or manual selection of scratch volume Second time interval for checking when scratch pool is low Second warning level for low scratch pool Time to focus camera Whether to give warning message when mounting library volume on non-library device

deferred dismount entdup float full-journal inittime initwam maxclean mount-msg output scratch sectime secwam viewtime

Automated Cartridge System

Explanation

acs-scr-threshold

Set threshold for scratch pool on an ACS

acs-subpool-threshold

Set threshold for subpool on an ACS

Scratch Pool

subpool-threshold

Set threshold for tapes in scratch pool

Library Storage Module

Ism-scr-threshold

Set threshold for scratch tapes in LSM

Ism-subpool-threshold

Set threshold for tapes in subpool on LSM

USING DOMAIN MODELS FOR SYSTEM TESTING

161

TABLEX STATE PARAMETERS IN THE ROBOTTAPELIBRARY DOMAIN

Object

State

Host Software Component

Explanation

autoclean

zeroscr

HSC automatic tape transport cleaning on or off Unit affinity separation for GDG chains Unit affinity separation Basic or full Whether transports are available when no non-library drives exist Whether device selection is restricted

Cartridge Access Port

prefvlu

Preference for CAP

Library Management Unit

Imu-status

Up or down

Library Storage Module

Ism-status

Online or offline

gdg-sep separation service-level specvo1

generation. Table XI1 shows representative entries from the Object Element Glossary for the StorageTek HSC command language. For a complete object element glossary refer to [29]. The next step in the domain analysis is to show relationships between the objects. These relationships are captured in an object hierarchy. The relationships take the form of a structural, or “part-of,’’ hierarchy because the structural relationships indicate parts of the objects [ 101. For test generation, the main interest in object relationships is in how related objects affect possible values for their object elements. This is captured with rules about object element values. The rules take the form of object element constraint rules TABLEXI OBJECT GLOSSARY ENTRY FOR THE LSM OBJECT

Object Description Commands Parameter Attribute Mode Parameter State Parameter Nonparameter Event Nonparameter State

LSM Library Storage Module-a

single tape “silo”

DISPLAY MODify MOVE VIew Warn

Ism-id Ism-subpool-threshold Ism-scr-threshold Ism-status lsm-full

162

A. VON MAYRHAUSER AND R. MRAZ

TABLE XI1 ENTRIES FROM THE HSC-ACS OBJECT ELEMENTGLOSSARY Element Name Ism-id Full Name Definition Type Values Object Representation

Library Storage Module (LSM) ldentifier Names an Instance of an LSM within an ACS parameter attribute 000 ... FFF LSM Range

Definition Type Values Object Representation

Number of times a cleaning cartridge is used before ejecting mode parameter 10 ... 100

Definition Type Values Object Representation

Status of the Library Management Unit (LMU) state parameter UP 1 DOWN LMU Enumeration

Definition Type Values Object Representation

A dynamic event that results when the system journals become full nonparameter event NOT-FULL 1 FULL HSC Enumeration

Definition Type Values Object Representation

Status of a tape transport (tape drive) nonparameter state BUSY I AVAILABLE Tape Transport Enumeration

maxclean

HSC Range

Imu-status

journal-full

drive-status

where the choice of one object element value constrains the choices for another. The StorageTek HSC-ACS domain provides a good example for constructing an object hierarchy (Fig. 4 shows the complete object hierarchy for this application with objects (bubbles), object elements (inside the bubble), relationships and constraints arrow^).)^ Consider the ACS object. The figure lists object elements for all but the highest-level HSC object because these did not fit nicely into the diagram. HSC has 26 object elements. The majority are mode parameters. HSC modes set various operating modes of the HSC software.

USING DOMAIN MODELS FOR SYSTEM TESTING

163

FIG.4. StorageTek object hierarchy.

Each ACS supports up to sixteen LSMs, and this structural relationship is shown in the figure as an arrow from the ACS object to the LSM object. Each LSM contains panels, tape drives, cartridge access ports, etc. Arrows from the LSM to each object denote this structure. Annotations on the arcs denote parameter constraint rules. For instance, the choice of an ACS (i.e. a specific acs-id value) constrains choices for the LSM (i.e. possible Ism-id values). The specific choices depend on the physical configuration (e.g. the number of LSMs in an ACS and how they are interconnected). Figure 4 shows that this domain has 10 such inheritance rules. The exact specification of the rule can depend on the specific system configuration and parameter value syntax. Table XI11 contrasts the general rules of Fig. 4 with the specific rules used for an actual physical configuration of a robot tape library used by the system testing group at StorageTek to test HSC version 1.2. Figure 5 shows the hardware configuration of the HSC described in Table XI11 (except for panels, rows, and columns to avoid clutter in the figure). In some cases no rule was necessary, because the physical configuration allowed all values, or the architecture was the same (e.g. same layout of cartridge access port columns and rows for both cartridge access ports). The

TABLEXI11 EXAMPLE PARAMETER General rule

INHERlTANCE RULES FOR

Domain values

ROBOTTAPELIBRARY

Configuration-specific rule

Configuration-specific values

acs-id -+ Imu-id

ACS= OO..FF } LMU=( OOO..FFF)

None

Ism-id

LSM=(000..FFF)

acs-id=00 Ism-id E 1OOO,001) acs-id=01 -+Ism-id E (010)

lsm-id~(000,001,010)

ptp-id

F”T’P=(0..7 )

lsm-id=000 -+ptp-id E { 0 ) Ism-id=OOl-+ ptp-id E 0 )

ptp-id E ( 0 )

drive

DlUVE=(OOO..FFF]

lsm-id=000 drive E (AlO,A14,A20,A25, 29, 2 c 1 drive E (A10,A14,A17,. -20, 2 lsm-id=001 -+drive E (AlO,A14,A2O,A25,A29,A2C} A29,A2C,A2F,A32,A36 ) lsm-id=010 drive E { A17,A32,A36,A2F]

acs-id

-+

Ism-id

-+

Ism-id

acs-idE{OO,Ol} Imu-id€ { ODO,ODI,0CC, OCD,OCE,OCF ) -+

-+

-+

Ism-id

Ism-id

-+

pp

-

PP={ 00..19 I

cap-id

lsrn-id=OOO-+pp E (04,07,10,14,18) lsm-id=001 -+pp E {00,05,10,15,19] lsrn-id=OlO-pp E {02,08,10,12,15)

pp E (00..19}

lsm-id=000 cap-id E ( 000 ] lsm-id=001+ cap-id E (001] lsm-id=010 cap-id E { 010)

capid E {000,00l,OlO}

IT=( 00..14

-+

-+

PP+X

RR=(00.. 14I

ppE (00..041+X€ (00..041 p p E ( 0 5 . . 1 0 ) - + 1 ~(0S..09) ~ p p E { 1 1 . . 1 9 ) - + 1 ~(10..14] ~

PP +cc

cc=(00..191

PPE (O0..04]-,CC€ (00..04] ppE ( 0 5 . . l O ] + c c ~ (05..09) ppE {11..19] +cc E (10..14]

cap-id -+ cap-rr

CAP-RR=(o0,01 I

None

cap-rr E { 00,01]

cap-id

CAP-cc= { 00..06I

None

cap-cc E { 00..06 )

-+

cap-cc

I

USING DOMAIN MODELS FOR SYSTEM TESTING

ACS W

165

ACSOl

FIG.5. Hardware configuration for the HSC described in Table 13.

rightmost column gives the values used for the constrained object element of each rule. These values reflect subsets of all potential values by taking into account the set-up of the test environment (in this case the system was tested using actual hardware rather than a simulator and the values reflect this installation). Next, domain analysis identifies actions on objects. These actions usually manifest themselves in commands of a command language for the application. We usually start by asking What can one do with this object? Which other objects are involved? What are desirable actions for this application domain? For example, one would want to mount tapes into a tape d r i v e of a specific s i l o , move tapes between silos,etc. This provides a list of possible actions and the objects involved in them. Table XIV provides such a list for the HSC-ACS domain. For use in subsequent references, the left column gives the name of the action as it is specified in the HSC release 1.2. command language. An action may only need some of the object elements associated with an object, so it is important to identify which of these object elements are necessary. Table XV gives an example of the object elements associated The upper-case letters in a command name indicate required syntax, the lower-case letters are optional; e.g. CL or CLean denote the same command.

166

A. VON MAY RHAUSER AND R. MRAZ

TABLEXIV HSC RELEASE1.2 COMMAND DESCRIPTIONS Command name ALLOC CAPPref CDs CLean DISMount DRAin EJect

ENter Journal

Load MNTD MODify MONITOR Mount MOVe

OPTion RECover RELease RETry

SCRparm SENter

SET

Description Changes the Host Software Component (HSC) allocation options Assigns a preference value to one or more cartridge access ports (CAPS) Enable/Disable copies OF the control data set Schedules the cleaning cartridge to be mounted on a library controlled transport Directs the Library Storage Module (LSM) to dismount a cartridge Terminates an ENter command Directs the robot to take cartridges from a Library Storage Module (LSM) and places them into a cartridge access port (CAP) where they can be removed by an operator Used to place cartridges into a Library Storage Module (LSM) through a cartridge access port (CAP) while operating in automatic mode Used to establish the action taken by the Host Software Component (HSC) if both journals fill to capacity before a control data set backup or a journal off-load is executed Used to query the status of the current tape transport activity Set options on how the Host Software Component (HSC) processes the mounting and dismounting of library volumes Places a Library Storage Module (LSM) online or offline to all hosts Initiates monitoring of cartridge move requests from the programmatic interface Directs the robot to mount a volume onto a specified library controlled transport Directs the robot to move cartridges to selected destinations within the same Library Storage Module (LSM) or to any LSM within an Automated Cartridge System (ACS) Used to set or change general purpose options of the HSC Allows the operator to recover the resources owned by a host that becomes inoperable Used to free an allocated cartridge access port (CAP) Applies only to the JES.1 environment. It enables the user to restart HSC/JES.? initialization without restarting the HSC address space component Dynamically modifies the scratch warning thresholds and interval values for the host on which the command is issued Used to schedule the enter of a single cartridge using a cartridge access port (CAP) that is currently allocated for ejecting cartridges Used to activate/deactivate various functions within the HSC

USING DOMAIN MODELS FOR SYSTEM TESTING

167

TABLEXIV (CONTINUED)

Command name

Description

SRVlev

Used to specify the service level at which the Host Software Component (HSC) operates

STOPMN

Terminates the monitoring of cartridge move requests received from the programmatic interface

Switch

Used in dual Library Management Unit (LMU) configuration to reverse the roles of the master and standby LMUs

TRace

Enables/Disables tracing of events for selected Host Software Components (HSCs)

UEXIT

Permits you to invoke your own processing routines at particular points during HSC processing

Vary

Places physical Library Management Unit (LMU) stations online, offline, or standby

VIew

If video monitors are attached to the LSM, the VIew command enables the operator to visually inspect internal components of the LSM using the robot’s cameras

Warn

Used to establish the scratch warning threshold values

with some of the HSC-ACS actions. This step provides object glossaries and a set of actions with object elements needed to perform the action. Table XI shows an example of an object glossary entry for the LSM object. Table XVI illustrates an action table entry using the CLean action. Similar actions can be grouped and collectively referred to as action classes. For example, Table XVII groups all commands that perform setup operations for the HSC-ACS into a Set-Up class, all commands that inform of status and display information into a Display class. Actions that perform useful work are members of the Action class. Classes need not be disjoint. The Any class contains all commands. The next step is to look at each individual action and determine whether the object elements associated with it have to satisfy value constraints for sensible operation. An example of such a rule is “don’t copy a file to itself” which requires the names of the files in the copy command to be different. These types of rules are called intracoinmand rules. An intracommand rule specifies constraints between object element values that hold during the execution of an individual action. Constraints that are currently possible have the form precondition 4 constraint or (no precondition) constraint.A precondition can be an equality or inequality constraint of two or more object elements associated with an action. If the precondition is true, the constraint must hold. A constraint states value constraints for

168

A. VON MAYRHAUSER AND R. MRAZ

TABLEXV OBJECT ELEMENTS ASSQClATED WITH SELECTED CQMMANDS Object elements

Command name ALLOC CAPPref CDS CLean Dismount Display Drain Eject Enter Modify Monitor Mount Move Recover Release scrparm Senter Vary

acs-id Host-id, acs-id dsn drive-id, host-id volser, drive-id, host-id acs-id, command-name, host-id, Ism-id, console-name, subpool-name, volser cap-id volser, cap-id, acs-id, subpool-name, vol-count acs-id, cap-id Ism-id console-name volser, drive-id, host-id, subpoolname Ism-id, pp, IT,cc, volser host-id cap-id initwarn, inittime, secwarn, sectime, baltol cap-id Imu-id

the affected object elements in terms of equalities or inequalities. While a richer set of constraint operators is theoretically possible (relational operators to describe possible relationships between object element values), we have yet to encounter a need for them in practice. The HSC-ACS domain only has one intra-command rule (for the MOVE command). It prohibits moving a series of tapes within the same panel. It is written as ( Flsm-Tlsm) +Fpanel f Tpanel, meaning if source LSM TABLEXVI ACTIQNTABLE ENTRY FOR CLEAN Command name Objects Object elements

Intrd-command rule

CLEAN drive, host drive-rcmge drive-list host-id none

USING DOMAIN MODELS FOR SYSTEM TESTING

169

TABLEXVII SCRIPT CLASSES FOR THE STORAGETEK HSC DOMAIN

Script class Any

Mode Set-Up

Action

Commands Alloc Cappref Cds Clean Cappref Cds

Commpath Dismount Display Drain

Clean Journal Alloc Journal Scrparm Stopmn VXY Alloc Display Load Recover View

Eject Enter Journal Load Mntd Monitor Option Uexit

Mntd Modify Monitor Mount Option Scrparm Srvlev Commpath

Move Option Recover Release

Retry Scrparm Senter Set

Set Stopmn Trace Modify

Trace Uexit Cappref Set

Enter Senter

Move Dismount

Retry Eject

Commpath Drain Mount Release

Srvlev Switch Trace Uexit Warn Mntd Switch

(Flsm) and target LSM (TSM)are the same, then the source panel (Fpanel) and target panel (Tpanel)must be different. The next element of analysis concerns dynamic behavior rules for sensible application behavior in the domain. Preconditions identify the conditions that must hold before a command representing an action can execute. Postconditions list the conditions that are true after it executes. Preconditions define required state or mode for an action to be meaningful. For example, a specific tape must have been entered into a tape silo before it can be moved around or removed. They also may further constrain valid parameter values through parameter binding. Postconditions state effects on object elements and influence future action sequences or parameter value

;;ii3 State1

FIG.6. State transition diagram: MOUNT-DISMOUNT script rule.

170

A. VON MAYRHAUSER AND R. MRAZ

selection. We represent these conditions in the form of script or behavior rules and parameter binding rules. Scripts can be visualized as state transition diagrams (Fig. 6) or regular expressions. For example, the script rule in Fig. 6 could be represented as [MOUNT Any*DISMOUNT].

Once action sequencing has been defined, the sequence can be annotated with value selection rules for parameters as shown in Table XVIII. The first rule, p*, states that the value for parametery can be selected from any valid choice as long as it fulfills inheritance constraint rules. The second rule, p , restricts the value of parameterp to a previously bound value. The third rule, p-, denotes that parameterp can be selected from any valid choice except for the currently bound value of p . To illustrate, the MOUNT - DISMOUNT sequence is annotated with script parameter selection rules. MOUNT tupe-id" drive-id* Any* DISMOUNT tape-id drive-id

This rule states that the tape-id and drive-id values can be selected from any valid choice for the MOUNT action while the DISMOUNT action must use the previously bound value for the tape-id and the drive-id parameters. (The tape mounted in a drive must be dismounted from the same drive). Table XIX shows script rules for the HSC-ACS domain with parameter binding.4 At this point in the analysis, we still have not defined any syntax. Except for parameter value restriction in inheritance rules, all information is independent of the actual command language chosen. This makes it possible to associate different related or competing products with the current domain models by mapping object elements to command language parameters, actions to commands, and object element value sets to parameter value sets, and to identify to which degree the domain rules for object element values, action rules, and behavior rules manifest themselves in the command language. For test generation, we use the syntax of the command language as well as the domain model that represents the semantics of the application. The advantages of building such a domain model early in the development TABLE XVIII SCRIPT RULE:PARAMETER VALUE SELECTION Rule

Description ~

p* P p-

Choose any valid value fory Choose a previously bound value for y Choose any except a previously bound value f o r p

For practical reasons we let testers set n so as to give them more control in how many commands can be generated as a maximum between the two required commands.

USING DOMAIN MODELS FOR SYSTEM TESTING

171

TABLEXIX EXAMPLESCRIPT RULES WITH PARAMETER BINDING Command name

Script rule

Mount/Dismount

MOUNT [ tape-id*] [ drive-id*] (n/any) DISMOUNT [ tape-id] [ drive-id]

Enter/Drain

ENTER [cap-id*] (n/any) DRAIN [cap-id]

are: (1) the model can be reviewed early in the life cycle; (2) the model can guide command language development; and (3) one can complete the model further so that it will be useful for development purposes. Thus testers and developers will know early on what will be tested.

4.2

Reverse Engineering a Domain Model

The use of a domain model for testing is not restricted to software that was built using domain analysis or reusable components. Frequently, system testers need to test a system against a user manual. In this case the command syntax is given and they reverse engineer the application domain model for testing purposes. Figure 7 shows the process by which a domain is captured. This process is represented in the navigator utility of the domain management system component of Sleuth [41], a tool that supports application domain-based testing. The following explanation refers to the navigator utilities in Fig. 6 in parentheses to explain the relationship between domain capture and the navigator tool. We start with the syntax of the language (SDE), then extract parameters (OEE) and group them into objects (OTE). Each parameter in the command language is categorized according to the object it influences. This classification provides a first cut of the objects and their properties. To illustrate this process, consider Fig. 8. Two HSC commands from the robot tape library have parameters that relate to three domain objects Cartridge, Tape Transport, and HSC. This groups parameters by related object. For a complete grouping see Fig. 4 in which each bubble represents an object and the parameters in the bubble its object elements. The object elements for the HSC object are mostly mode parameters and are listed separately in Table IX. Next, each object element is classified by defining its object element type. We also have to identify possible parameter values for each object element (PVE). In Sleuth, objects consist of object elements and relate to each other. Relationships between objects produce the object hierarchy (OHE) (cf. Fig. 4). Arcs in the hierarchy are annotated with parameter constraint rules (PRE). Next we identify whether parameters of single commands constrain each other (ICE) (refer back to the rule for the MOVE command discussed earlier). Last, we determine scripting rules and parameter binding rules

172

A. VON MAYRHAUSER AND R. MRAZ

Legend SDE - Syntax Diagram Editor OEE - Object Element Editor OHE - Object Hierarchy Editor OTE - Object Table Editor PRE - Parameter Rules Editor PVE - Parameter Value Editor SET - Set Database SCE Script Class Editor SRE - Script Rule Editor ~

ICE - lntracommand Rule Editor

---+

-

used by relation

a - Ascribe rules to a command and its parameters b - Ascribe rules between pairs of commands c - Assign commands to scripting classes d - Extract parametersfrom Commands. e - Create abstract objects and assign object elements to them t - Order objects into one or more hierarchies. g - Assign type and value file name to parameters. h - Assign values to parameter value sets. i - Ascribe inheritance rules to parameter value Sets.

FIG.7. Process for reverse engineering a domain model.

(SRE). They are equivalent to those found in the a priori domain analysis (cf. Table XIX). Sleuth also allows sets of commands to be grouped together (SCE) as action classes (e.g. Action versus Display types of commands). Scripting rules may involve such classes of commands. The steps are the same as in the a priori analysis. Results for the HSC-ACS are in Table classes. This completes the domain model. Again, we have a language-dependent and a language-independent part of the model.

Q Cartridge

DISMount

{,

I ) cdrive-icb [l ,

CLean { I I

.

(

.

) I [l

FIG.8. HSC object and object element analysis.

USING DOMAIN MODELS FOR SYSTEM TESTING

173

5. Test Generation Process The domain model of section 4 serves as an abstract representation of the system under test. To make the domain model useful requires a process to automatically generate test cases based on that abstraction. The process must also consider testing strategies and test criteria used during a system test, and couple domain analysis and the domain model with test generation. We base this test generation process on the results of observing a team of system testers in industry. We investigated (1) how they tested their products, (2) the steps in their testing process, (3) needs for test automation, and (4) desirable features of an automated test generator. Figure 9 shows the input and output for each step in the test generation process. The domain model 0;; captures the syntax and semantics of version v of the system under test. The zero subscript identifies the domain model as the starting point from which all other models are derived (for example, those representing a competing software product by a different manufacturer). For instance, D ~ ” ’ * denotes the StorageTek HSC Release 1.2 domain model. The domain model is a persistent description of the software. It represents the default description from which test suites are generated. A domain model is needed for each new domain and every time a domain changes significantly. All testers share the domain model to provide a consistent view of the system under test. Sometimes test objectives call for test cases generated directly from D;. Such tests represent “valid” sequences of commands Currently, Sleuth captures that follow all syntax and rules defined in 0;;. the domain model using a reverse engineering process. Figure 7 shows the utilities which correspond to the domain capture activities. Often, testers want to test a particular system configuration or a particular feature. To achieve this, they build a test subdomain TSDY. The subscript j identifies the specific subdomain created, and the superscript identifies the Test Engineer Testing Strategy

A Priori Domain Anal sis

-\

FIG.9. Test generation process model.

174

A. VON MAYRHAUSER AND R. MRAZ

version of the system under test. Test subdomains may be a subset or a superset of the original domain model. A subset restricts the parameters and commands generated in a test case. For example, TSD;$’.’ is the Cartridge Access Port (CAP) test subdomain for HSC Release 1.2. In this test subdomain, only the following commands are turned on (activated and thus can be generated): Action class: Drain, Eject, Enter, Release, Senter. In addition, the set-up commands Vary and SRVLEV must be turned on to ensure that the LMUs are on-line, and the service level is FULL (a precondition to the Action class commands of this test subdomain). A superset of the domain model allows greater freedom in test generation by turning rules off (script rules, intracommand rules, or parameter inheritance rules). This is important for testing error checking and recovery features of applications. For example, should one want to test erroneous use of the CAP, one can turn off all rules for Action and Set-Up commands. Test suites generated for this test subdomain would try to eject tapes that have never been entered into the silo, and use devices that are either not on-line or not at the required service level. Test criteria also drive the creation of test subdomains. To illustrate, after changes to a system, regression testing rules [42] prescribe how to build a regression testing subdomain. In this case, the test criteria define what parts of the (modified) system must be regression tested, leading to the formation of a regression test subdomain. Sleuth provides a set of utilities to customize domain models into test subdomains. Table XX summarizes them. Test generation takes information from the test subdomain and directives from the tester to generate test suites, Ti”_,(k= 1,2,3,. ..,>.For instance, TABLE XX UTILITIES TO BUILDTESTSUBDOMAIN Domain model component

Utility

Purpose

Commands Script rules Intracommand rules

activate, deactivate activate, deactivate, edit activate, deactivate, edit

Define scope of test Test valid, erroneous sequences Test valid, invalid single commands

Syntax

edit syntax

Parameter values

edit branch frequencies edit

Model syntactically incorrect commands Control test emphasis

Parameter inheritance rules

activate, deactivate, edit

Reduce set, add new (invalid) values Test valid versus invalid operation

USING DOMAIN MODELS FOR SYSTEM TESTING

175

T ~ ~ ~ denotes !$, test #10 generated from the CAP subdomain for HSC Release 1.2. Test directives include: 0

0

0

Generate n commands of class or type c: this is the basic test generation directive. n Is the number of commands to generate, c is either the name of a command (like Move or Drain), or the name of a script class (like Action in Table XVII). Recall archived test suites: this enables use of legacy test suites, or tests generated by other means. It makes using Sleuth flexible, particularly with regards to other tools. Merge several test suites: this is used to simulate parallel requests from various sources where appropriate.

A test suite is the result of the test generation. It contains test scripts, test templates, and test cases. Test scripts are lists of command names. Test templates are lists of commands with place holders for parameters. A test case is a list of executable commands. Test scripts, test templates, and test cases are generated in three phases. This decision was made to allow reuse of tests at various levels of specificity. In the first phase, test directives are interpreted and the test script is generated taking scripting rules into consideration. The second stage creates a command template by selecting a specific instance of each command in the script. Parameters remain as place holders. The third phase uses parameter binding rules, intracommand rules, and parameter inheritance constraints to create a fully parameterized list of executable commands. In the development of the test generation module of Sleuth, we experimented with a variety of generation approaches, including context-free grammars [32], attribute grammars [ 15,401, probabilistic grammars [27,28], and A1 planning systems [21]. All of these have their advantages and disadvantages. Our selection criteria were that the methods selected should 0

0

show adequate performance for industrial use (scale up). This disqualified the A1 technique for the moment. We are, however, working on improving its performance, since a pilot study [21] showed that the Planner generated some innovative tests to achieve test goals; make changes to the domain model easy to deal with when testing subdomains are formed. Unlike some other sentence generation problems, our test generation problem encounters frequently changing grammars, if grammars are used. Those changes should not require the user to manipulate the grammar; rather, the test tool should perform this. The initial version of Sleuth [40] was based on attribute grammars. Empirical evidence suggested that while automated algorithms to percolate domain

176

A. VON MAYRHAUSER AND R. MRAZ

model changes into the grammar are, of course feasible, they are needlessly complex. The same is true for probabilistic grammars, and, we suspect, for some of the other approaches discussed in section 2.

As a result, we settled on a combination approach with different generation mechanisms for the scripting, template, and parameter value phases of test generation: 0

0

0

Phase 1: Commands are randomly selected from the set of currently allowable commands (those that are part of the current testing subdomain and possible with respect to scripting rules). The precise distribution can be influenced by the user to model operational profiles. Scripting rules are activated when a command is selected for generation that is part of a scripting rule. Phase 2: This phase generates a command template for each command chosen in phase 1. Command templates can be thought of as one path through a command’s syntax diagram. For every branch point in the syntax diagram, the generator makes a choice dictated by userdefinable frequencies (default: uniform). Phase 3: This stage selects the actual parameter values for each command. The test generator must fulfill all constraints: parameter binding from the scripting phase, intracommand rules, and parameter inheritance rules. The generator uses set operations (on parameter values) to compute the possible values at a particular point in the generation and then selects one of the values. If the set is empty, the generator chooses from a user-defined alternate set. Users often choose this set to contain a single value of “?” to alert them that their domain model has a fault, because the constraint was not satisfiable. A generation log provides information on how a particular set of values was chosen.

6.

Sleuth Test Generation Example

Sleuth supports all stages of application domain-based testing. It provides utilities to capture the domain-model through the reverse engineering process described in section 3.2. Figure 7 identifies the utilities for the domain capture activities. The Specification pull-down menu in Fig. 10 provides access to these utilities. The Configuration pull-down menu accesses the utilities of Table XX to build test subdomains. Sleuth acts as a test tool generation engine in that it uses the domain model to build a customized test generator for that domain. Every domain model thus results in a different test generator, making Sleuth capable of handling a wide range of application domains.

USING DOMAIN MODELS FOR SYSTEM TESTING

177

FIG.10. Sleuth main window.

Test generation uses the current test subdomain (the default is the full domain model) as the basis for generating tests. Test generation follows the three-stage approach described earlier. Figure 10 represents these three stages in the three panels of the main window labeled “scripting,” “commands,” and “parameters.” The scripting stage generates a list of command names. The user gives Sleuth high-level test generation directives such as “generate 100 MOVE commands” (@ 1 0 0\MOVE).The scripting rules cause Sleuth to generate the necessary additional commands to make the 100 MOVE commands meaningful (e.g. system setup, entering of enough tapes). The tester does not have to worry about this since the domain model ensures generation of command sequences that represent valid system operation. The tester saves the list of commands (the script) using the export button. The generate button starts the second phase of test generation. Table XXI shows the results of generating 20 commands in the first stage using the StorageTek Dtsc’.2domain model. Command #1 ,SRVLEV, ensures the correct service level before the test begins. ENTER is used to insert tapes into the ACS through the CAP door. This ensures a known set of tapes. In the first stage, Sleuth applied all scripting rules. For instance, the ENTER command requires a corresponding DRAIN command. Command #2 issues an ENTER command and Sleuth generated an appropriate D R A I N (command #20). Similarly, tape mounts and dismounts must be sequenced because

178

A. VON MAYRHAUSER AND R . MRAZ

TABLE XXI SLEUTH STAGE1 TESTGENERATION

Line num 1 2 3 4 5 6

7 8 9 10 11 12 13 14

15 16 17

18 19 20

Command name

Description

SRVLEV ENTER RECOVER MONITOR JOURNAL MOUNT CLEAN CAPPREF MOUNT UEXIT MOVE SWITCH JOURNAL SCRPARM DISMOUNT DISPLAY LOAD DISMOUNT EJECT DRAIN

System Set Up Enter Tapes for the Test

Mount First Tape Mount Second Tape Move tapes inside the ACS

Dismount Second Tape

Dismount First Tape

tapes must be mounted before dismounting. Sleuth generated two MOUNTDISMOUNT sequences in commands #6-#15 and #9-#18. The command template stage takes the list of commands and creates a command template for each command by selecting a path through the command’s syntax diagram.5 To archive the suite of command templates, the tester clicks on the export button underneath the command panel. Clicking on the generate button between the command and parameter panel (cf. Fig. 10) starts the last phase of test generation. Table XXII shows the results of generating command templates for the commands in TableXXI. Parameters are shown as place holders using square brackets. In the third phase, parameter values are selected based on the current system configuration taking into account parameter inheritance rules, intracommand rules, and parameter binding. The tester saves the command suite by clicking on the export button. Table XXIII shows the final test case for our example. Note that CAP 0 0 0 used to enter tapes in command #2 is released by DRAIN in command #2O. Likewise, the MOUNT-DISMOUNT command sequences of commands #6-#15 and #9-#18 select the appropriate tape

’

Sleuth allows command syntax to be represented and edited as syntax diagrams. Branches are associated with selection frequencies.

USING DOMAIN MODELS FOR SYSTEM TESTING

179

TABLEXXII SLEUTH STAGE2 TESTGENERATION Line num 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Command Template SRVLEVFULL ENTER [cap-id] SCRatch RECOVER [host-id] MONITOR PGMI, L= [console-name] JOURNAL FULL = ABEND MOUNT [drive] SUBpool ([subpool-id]) CLEAN [drive-id] [host-id] CAPPREF [prefvlue] 001 MOUNT [volser] [drive] UEXlT [nn-id] Load =LSLUX [uexit-id], Enabled MOVE Flsm([lsm-id]) Panel([pp]) Row([rr-ls]) TLsm([lsm-ls]) TPanel( [pp]) SWITCH Acs [acs-id] JOURNAL FULL = Continue SCRPARM DISMOUNT [volser-id] [drive-id] [host-id] DISPLAY COMMPath LOAD SLSMDQR DISMOUNT [drive-id] [host-id] EJECT VOLSER ([volser-ls]) DRAIN [cap-id]

drives and tape id. For command #11, Sleuth applied the intra-command rule for the MOVE command mentioned earlier. Sleuth can be used for functional testing of specific commands (the test subdomain includes the specific command to be tested and possibly other commands required due to scripting rules). Frequencies ensure that all syntactic options in a command are exercised, provided that enough instances of the command are generated. The user can also define frequencies such that test generation is biased towards specific options in a command (e.g. it may be desirable during regression testing to test modified parts of a command more often than unchanged parts). The metrics pull-down menu provides access to domain model usage information, i.e. how often each part of the domain model was used during test generation. This information is analogous to a coverage analyzer for white-box testing. The measures report on how often commands, rules, branches, and values have been used during test generation. System testing is supported by using the complete domain model and instructing Sleuth to generate a certain number of commands (we have seen system testers generate hundreds to thousands of commands on Monday morning and execute and evaluate the results for the remainder of the week). The domain model makes sure that dynamic behavior gets tested

180

A. VON MAYRHAUSER AND R. MRAZ

TABLExXIII SLEUTHSTAGE3 TESTGENERATION

Line num 1 2 3 4 5 6

I 8 9 10 11 12 13 14 15

16 17 18 19 20

Commands SRVLEV FULL ENTER 000 SCRatch RECOVER MVSH MONITOR PGMI, L=MVSH JOURNAL FULL=ABEND MOUNT A2F SUBpool (EVTISO) CLEAN A10 MVSE CAPPREF 9 001 MOUNT EVT280 A14 UEXIT 10 Load=LSLUX 11, Enabled MOVE Flsm(001) Panel(00) Row(02,03,04) TLsm(001) TPanel(l5) SWITCH Acs 00 JOURNAL FULL=Continue SCRPARM DISMOUNT EVTl8O A2F MVSE DISPLAY COMMPath LOAD SLSMDQR DISMOUNT A14 MVSE EJECT VOLSER (EVT180,EVT280) DRAIN 000

realistically. User-controlled frequencies force a desired operational profile. Error recovery in the midst of regular operation can be tested by defining a testing subdomain through intentionally breaking scripting rules, intracommand rules, or parameter inheritance rules, or by defining invalid parameter values, thus forcing erroneous behavior. In our empirical observations of system testers over the last four years, we have seen that testers restrict the domain model to a testing subdomain for a variety of reasons: test focus (e.g. testing a new type of tape drive controlled by the HSC), exclusion of commands that are undesirable for some reason (e.g. when a tester wants to run tests over night, excluding commands that would require (human) operator intervention is desirable), testing a specific type of workload, etc.

7. Reuse Scenarios and Experiences Testing based on an application domain model offers two types of reuse capabilities: domain reuse and test case reuse. Domain reuse refers to the amount of domain reuse possible when testing different systems in closely

USING DOMAIN MODELS FOR SYSTEM TESTING

181

related or overlapping application domains. Test case reuse relates to the amount of reuse for a test case under various circumstances.

7.1 Domain Reuse Complete domain reuse occurs when testers use an existing domain model with no change or modification to generate test cases for a new system or release. For example, IBM released MVS 5.1.1, a new version of the MVS operating system. StorageTek used the D~sc2~o.' domain model and its associated test subdomains to test HSC's operation with the new release. No changes were made to the domain model. Testers saved significant time by recalling and generating test cases very quickly. Partial Domain Reuse can be classified as to which portions of the domain model have to change and as to the extent of such change. Reuse is greater when fewer parts of the model require changes and the extent of changes is small. Syntax and parameter value sets are most prone to change. They are the least general to a domain and depend on an actual application. Partial domain reuse was found in three test situations: (1) testing competing systems, (2) test varying system configurations, and (3) testing successive system releases. Testing competing systems can reuse all parts of a domain model except for syntax and possibly parameter value files. An example of such a situation are two competing tape storage systems, StorageTek's HSC and IBM's 3594 and 3495 tape library systems. Testers used the DfsC2.O.'domain model as a basis for creating the DfM3594domain model. Since their physical configurations vary, most changes to the domain model occurred in the parameter value definitions and parameter inheritance rules. On the other hand, the command syntax of the two systems had a large intersection. Therefore, the testers were able to reuse many of the command syntax descriptions from the HSC domain. Second, we built a domain model for testing ACSLS (the UNIX environment version of HSC) running on competing workstations, Sun Microsystem Sparc and Hewlett Packard 9000. The ACSLS software was derived from the HSC system. Therefore, the D,HSc2.' domain model was reused to create the DtcSLs-' domain models. The functionality of the IBM and the Unix systems are the same, but the command language and some of the parameter value files are different due to the variations in naming conventions on those platforms. In this example, the changes to the parameter definitions and the command syntax are minimal so domain models DACSLS-SunoS 0 and D~csLs-Hpux are almost identical. One can also use the domain model to identify to which degree competing systems have the same features (which portions of the domain model are needed in both systems; we compare objects, object elements and actions).

182

A. VON MAYRHAUSER AND R. MRAZ

Testing varying system configurutiorzs of the same version of a system is a frequent testing task. At the same time, it only requires modifying the parameter value files and some parameter inheritance constraint rules if they relate to configuration-relevant values. The HSC provides an example for such a situation. A specific tape silo configuration (ACS) can connect one to sixteen silos. These configurations influence the LSM, tape transport, passthrough port, panel, cell row/column, and cartridge access port objects. Specifically, they affect which values are valid for LSM identifiers. Parameter inheritance constraints also change, because the specific connections between silos affect what panels, rows, and columns are available for tape storage. To test the wide variety of system configurations, testers would load the appropriate domain model and modify it for each configuration. For example, TSDg::io.' defines a test subdomain for a single silo configuration for the HSC 2.0.1 domain. TSDFf::.o.' defines a three LSM configuration. Testing successive system releases provides another opportunity for domain model reuse. The domain model for the previous release is used as a basis for the new domain model. We reused domain models for successive releases of HSC 1.2, 2.0, and 2.0.1. The first step compared command syntax diagrams for HSC 1.2 and HSC 2.0. Twenty-six commands required modifications to the syntax diagrams in the form of new keywords and new branches or command options. Similarly, the tester identified and updated the commands that changed between HSC 2.0 and 2.0.1. Five commands required keyword and option updates. It was also necessary to update the parameter value files for the hardware configurations. The tester changed the parameter files for the following parameters (cf. Table VIII): Ism-id, acs-id, drive, dsn, volser, station, cupid, host-id and subpool-name. To illustrate the nature of changes to a domain model between versions in more detail, consider one of the key enhancements between HSC1.2 and HSC2.0. StorageTek modified the ACS hardware to support multiple CAPS. This hardware modification initiated changes to the command line interface, HSC2.0. Specifically, it modified all commands in the A c t i o n script class that included the cap-id parameter (see section 4). Modifications included adding an option to the syntax diagrams to allow either a cap-id or a list of cap- ids.

At the parameter value level, there are changes in the cap-id format. The format provides backward compatibility to old CAP configurations and new functionality to the new CAP doors. HSC2.0 appends a " :0 0 " or r r : O 1 r r to each cap-id ( ( 0 0 0 ...FFF}). The first extension denotes an "old" CAP while the second designates the new CAP hardware. In addition, the new CAP doors can eject up to 9999 tapes in one EJECT command. Previously, HSC1.2 allowed a maximum of 100 tapes per EJECT

USING DOMAIN MODELS FOR SYSTEM TESTING

183

command. This was a minor change to a parameter value file. HSC2.0 also introduced a new system set up command: OPTION. This command specifies cap-ids to eject tapes when a CAP is unavailable. It also sets limits on how many tapes to eject. We included this command in the SETUP scripting class. Table XXIV compares HSC1.2 test generation with HSC2.0. We added the new command OPTION and set frequencies to ensure that Sleuth generated the updated command syntax and parameter value choices. The new OPTION commands in lines #2 and #3 show how new features can be added to an existing domain model when changes call for new scripting rules-in this case the new commands are part of the SETUP class. Command #3 also reflects the change in the maximum number of tapes ejected. In several commands, the new cap-id syntax is evident (e.g. 4, 10,22, and 23).

7.2 Test Case Reuse Test case reuse is the process of recalling and using a previously archived test case. The three-stage test generation offers three types of reuse possibiliTABLEXXIV DOMAINREUSEEXAMPLE Nurn 1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16 17 18 19 20 21 22 23

HSC 1.2

HSC 2.0

SRVLEVFULL OPTION REPATH (Yes) OPTION EJLirnit (9999) ENTER 001 :00 SCRatch ENTER 000 SCRatch RECOVER MVSH RECOVER MVSH MONITOR PGMI, L=MVSH MONITOR PGMI, L=MVSH JOURNAL FULL=ABEND JOURNAL FULL=ABEND MOUNT A36 SUBpool (EVT2) MOUNT A2F SUBpool (EVT180) CLEAN A2F MVSE CLEAN A10 MVSE CAPPREF 4 000 : 00 CAPPREF 9 00 1 MOUNT EVT297 A29 MOUNT EVT280 A14 UEXIT 04 Load=LSLUX 02, Enabled UEXIT 10 Load=LSLUX 11, Enabled MOVE Flsm(001) Panel(00) Row(02,03,04) MOVE Flsm(000) Panel(l8) Row( 10) TLsrn(000) TPanel( 14) TLsrn(001) TPanel( 15) SWITCH Acs 00 SWITCH Acs 00 JOURNAL FULL=Continue JOURNAL FULL=Continue SCRPARM SCRPARM DISMOUNT EVT180 A2F MVSE DISMOUNT EVT297 A29 MVSH DISPLAY COMMPath DISPLAY COMMPath LOAD SLSMDQR LOAD SLSMDQR DISMOUNT A36 MVSE DISMOUNT A14 MVSE EJECT VOLSER (EVT297) EJECT VOLSER (EVT180.EVT280) DRAIN 001 : 00 DRAIN 000 EJECT SCRTCH (010 :01) VOLCNT (99) SRVLEV FULL

184

A. VON MAYRHAUSER AND R. MRAZ

ties: tests are reusable as scripts, suites of command templates and suites of commands. Table XXV shows a list of possible reuse applications at all three levels of test case generation. Many of these were suggested by the test engineers at StorageTek.From this list we identified three reuse scenarios: (1) successive software releases, (2) multiple system configurations, and (3) varying test case construction. The following provides an overview of each class and describes how the test engineers at StorageTek use Sleuth to reuse archived tests. Even though the examples presented here are specific to the tape library, it is reasonable to assume that other systems will have similar reuse needs.

7.2.1 Scenario #1-Successive Software Releases Between releases, the command language may change. New commands may be added, obsolete commands may be deleted, and command syntax may be modified. In some cases, a new release may influence rules like intra-command rules or parameter constraint rules. At StorageTek, test engineers use HSC commands to generate tests for the robot tape library. These tests can be archived and recalled at all three stages of test case generation. For example, when a new release of the software is issued, archived test cases can be recalled at the Scripting level for reuse. Once the script is recalled, a command template can be generated using the TABLEXXV DOMAIN-BASED TESTING-REUSE APPLICATIONS Reuse Stage

Reuse possibility

~~

Reuse script

Regression testing Command syntax change New software release Stress test Creating new test scripts Operating system version

Reuse command template

Regression testing Domain specification change Domain configuration change Hardware configuration change Stress test Creating new command templates Parameter value change Regression testing Re-run test case Creating new test cases Stress test

Reuse test case

USING DOMAIN MODELS FOR SYSTEM TESTING

185

updated command syntax and semantic rules. Each command template can be used to generate tests for a wide variety of hardware configurations. StorageTek requires software to be upward compatible from release to release. Therefore, test cases that ran without incident on one release should run without incident on the new release. Sleuth provides utilities to recall test suites for this simple form of regression testing. This same reuse scenario can be used for testing applications on all its platforms and operating systems on which they are supposed to run. There may be many common commands with slight differences between the languages. For example, some commands may be needed for one operating system and not another. Using this same scenario, test cases can be recalled at the Scripting level, and new tests can be generated for various operating system versions. Since all test suites are identical at the Script level, we build uniform, comparable test suites for a variety of releases and platforms. Table XXVI shows an example of reusing the archived script entertapes. s. In the table, the script is used to generate command templates for HSC1.2 and HSC 2.0. The script could also be used for HP-UX OS, SunOS, HSC2.0.1, and IBM3594 domains. The utilization of archived scripts is typically very high. One script can generate a wide variety of command templates. In turn, each command template can generate several test cases.

7.2.2 Scenario #2--Multiple System Configurations The set of valid parameter values represents a configuration of the problem domain. It represents a configuration of logical objects or physical devices. The StorageTek robot tape library hardware can be configured in many ways. To test these configurations, testers execute tests on a Library Management Unit (LMU) simulator or on actual ACS hardware. ACS hardware can be configured in many ways. Testing on the actual hardware explores timing problems or real-time processing faults. Each ACS configuration needs a separate set of parameter value files and parameter constraint rules. TABLEXXVI TEXTCASEREUSE-SUCCESSIVESORWARERELEASES Archived script enter-tapes.s

HSC 1.2 template

HSC 2.0 template

MODIFY

MODIFY CAP ([cap-id]) ONline

MODIFY CAP [cap-Is] ONline

CAPPREF ENTER DRAIN

CAPPREF [prefvlue] 000 ENTER [cap-id] SCRatch DRAIN [cap-id]

CAPPREF [prefvlue] [cap-ls] ENTER 000 : 00 SCRatch DRAIN ([cap-ls])

186

A. VON MAYRHAUSER AND R. MRAZ

TABLEXXVII TESTCASEREUSE-MULTIPLESYSTEMCONFIGURATIONS HSC 1.2 Configuration 2

HSC 1.2 Configuration 1

Archived template mount-tapes.ct

ENTER [cap-id] MOUNT [drive] ([volser-id]) LOAD SLSLDQR DISMOUNT [volser-id] [drive-id] DRAIN [cap-id] [cap-id]

ENTER 002 MOUNT A10 (EVT185) LOAD SLSLDQR DISMOUNT EVT185 A10 DRAIN 002

ENTER 0 11 MOUNT A2F (EVT297) LOAD SLSLDQR DISMOUNT EVT297 A2F DRAIN 01 1

For this scenario, tests will be reused at the command template level. Upon recalling a command template, test cases can be regenerated based on the new configuration. Hence, a single command template can generate a test case for different configurations. This saves generation time, but more importantly, it makes test cases uniform and comparable because they test “the same thing.” Table XXVII shows how a single archived command template can be reused to generate test cases for multiple hardware configurations. In this example, the number of LSMs, tape drives, and tape volumes were changed in Hardware Configuration 1 and Hardware Configuration 2.

7.2.3 Scenario #3-Test

Case Construction

Often testers find a particular list of commands is good at detecting a certain error. Test engineers may also have a set of commands putting the system in a particular state before running a test case. It should be easy to recall such test cases and to include them in a new test suite. In Sleuth, this reuse scenario spans all three stages of test generation. A new test case can be constructed from a set of “building blocks.” One script might be included to put the system in a particular state, another might present a workload to the system, and a third might reuse a test that has been successful for a particular type of fault. Command templates can be included to create a larger test sequence. Finally, archived test cases can be included for a regression test. To support test case construction, Sleuth provides a directive to include archived scripts, command templates, and test cases.

8. Conclusions and Further Work We presented an approach to describing an application domain for testing purposes and showed the ways in which reuse of a domain model has been fruitful. While manual generation of test cases from such a domain model is

USING DOMAIN MODELS FOR SYSTEM TESTING

187

of course possible, its benefits are much greater when the domain model is coupled with an automated test generator. Sleuth is a test generator that bases test generation on a model of the application domain. It has been in use at StorageTek for several years. While building a domain model is clearly an effort, the potential for domain and test case reuse was realized for the test scenarios we encountered during practical use. How good is this method? In a recent case study [44] comparing testing with and without this method over a 12-week test cycle, we found that with domain-based testing, the tester found about 3.5 times as many errors. Postrelease incidence rate (tracked for 12 months after release) for the Sleuthtested version was about 30% lower. This gives us great confidence that testing based on a specialized model of the application domain not only offers significant opportunities for reuse of test artifacts, but also provides an effective and efficient testing environment. Further work is ongoing to answer a variety of questions and tester needs. The domain model currently does not represent the full system state. Adding this capability is desirable as it makes the model more complete. On the other hand a fully complete model would in effect be a simulator. Just how much state information is necessary is an open question. Validating test results is still manual. We are working on adding test oracle information to the domain model. This requires new analysis steps to determine the nature of the oracle. We also need to examine this method with existing domain analysis and domain models for software reuse [3,4]. Currently, the application of the domain model is restricted to applications with a command or transaction language as a user interface. Extending the approach to testing systems with a graphical user interface would require mapping actions, objects, and object elements into GUI concepts like push buttons, toggles, text fields, basic or option menus, etc. as an additional component of the model. Syntactic representation describes the precise ways of activating these constructs (e.g. via Xrunner code). Finally, we are in the process of automating test subdomain generation based on test objectives and developing testing criteria specific to testing against an application domain model. Application domain-based testing and Sleuth have been in operation in an industrial system testing group for over four years. Results support its usefulness in practice, indicating that even a relatively simple model can go a long way in improving system testing. ACKNOWLEDGMENTS Our research has been partially supported by the Colorado Advanced Software Institute (CASI), StorageTek, and the Air Force Institute of Technology. CASI is sponsored in part by

188

A. VON MAYRHAUSER AND R. MRAZ

the Colorado Advanced Technology Institute (CATI), an agency of the state of Colorado. CATI promotes advanced technology teaching and research at universities in Colorado for the purpose of economic development. REFERENCES [l] Anderson, C., von Mayrhauser, A., and Mraz, R. (1995). On the use of neural networks to guide software testing activities, Proceedings of the lnteriiutionul Test Conference, Washington, DC. October. [2] Balcer, M., Hasling, W., and Ostrand, T. (1989). Automatic generation of test scripts from formal test specifications, Proceedings of the 3rd Symposium on Software Testing, Analysis, and Verification, December, pp. 210-218. [3] Batory, D., and O’Malley, S. (1992). The design and implementation of hierarchical software systems with reusable components, ACM Transac,tions on Software Engineering and Methods, October. [4] Batory, D., Coglianese, L., Goodwin, M., and Shafer, S. (1995). Creating reference architectures: An example from avionics, Symposium on Soft Reusability, Seattle, Washington. [S] Bauer, J., and Finger, A. (1979). Test plan generation using formal grammars, Proceedings of the 4th International Conference on Software Engineering, pp. 425-432. [6] Bazzichi, F., and Spadafora, I. (1982). An automatic generator for compiler testing, IEEE Transactions on Software Engineering, 8(4), 343-353. [7] Beizer, B. (1990). Software Testing Techniques, 2nd ed. VanNostrand-Reinhold. [8] Biggerstaff, T. J., and Perlis, A. J. (eds.) (1989). Software Reusability, Volume I: Concepts and Models, Frontier Series, ACM Press. [9] Biggerstaff, T. J. (1992). An assessment and analysis of software reuse, In Advances in Computers, Academic Press. [ 101 Booch, G. (199 1). Object Oriented Design with Applications, Benjamin/Cummings. [ l l ] Celentano, A., Reghizzi, S. C., Vigna, P. D., Ghezzi, C., Gramata, G., and Savoretti, F. ( 1980). Compiler testing using a sentence generator, Software-Practice and Experience, 10,987-918. [12] Chow, T. S. (1977). Testing software design modeled by finite state machines, Proceedings of the 1.st IEEE Computer Software Application Conference (COMPSAC), pp. 58-64. [13] DeRemer, F. L. (1971). Simple LR(k) Grammars, Cornrnunicationsof the ACM, 14,453. [ 141 Devanbu, P., and Litman, D. (1996). Plan-based terminological reasoning, Artificial Intelligence, 84, 1-35 [ 151 Duncan, A. G., and Hutchison, J. S. (1981). Using attributed grammars to test designs and implementations, Proceeding of the 5th International Corlference on Software Engineering, pp. 170-177. [16] Fujiwara, S., von Bochman, G., Khendek, F., Amalou, M., and Ghedamsi, A. (1991). Test selection based on finite state models, IEEE Transactions on Software Engineering, SE-17(10) 591-603. [17] Goodenough, J. B., and Gerhart, S. L. (1975). Toward a theory of test data selection, IEEE Transactions on Software Engineering, SE-1(2), 156- 173. [18] Gonenc, G. (1970) A method for the design of fault-detection experiments, IEEE Transactions on Computers, C-19,55 1-558 June. [19] Hamlet, D., and Taylor, R. (1990). Partition testing does not inspire confidence, IEEE Transactions on Software Engineering, SE-16( 12) 1402- 1411. [20] Howden, W. E. (1987). Functional Program Testing and Analysis, McGraw-Hill, Software Engineering and Technology Series.

USING DOMAIN MODELS FOR SYSTEM TESTING

189

[21] Howe, A. E., von Mayrhauser, A., and Mraz, R. T. (1997). Test case generation as an A1 planning problem, Automated Software Engineering, 4,77-106. [22] Hutchinson, J. (1992). Privute Communication. [23] h e , D. C. (1987). The automatic generation of test data, Computer Journal, 30(1), 63-69. [24] Kelly, V. E., and Jones, M. A. KITSS: a knowledge-based translation system for test scenarios, Proceedings I Ith National Conference on Artificial Intelligence, Washington, DC, pp. 804-8 10. [25] Krueger, C. (1992). Software reuse, ACM Computing Surveys, 24(2), 131-183 June. [26] Naito, S., and Tsunoyama, M. (1981). Fault detection for sequential machines by transition tours, Proceedings of Fault Tolerant Computing Systems, pp. 238-243. [27] Maurer, P. M. (1990). Generating test data with enhanced context-free grammars, IEEE Software, July pp. 50-55. [28] Maurer, P. M. (1992). The design and implementation of a grammar-based data generator, Software-Practice and Experience, 23(3), 223-244 March. [29] Mraz, R. (1994). Automated testing of application domains, PhD Dissertation, Colorado State University, Computer Science Department, December. [30] Myers, G. J. (1979). The Art of Software Testing. Wiley Series in Business Data Processing, John Wiley and Sons. [31] Ostrand, T., and Balcer, M. (1988). The category-partition method for specifying and generating functional tests, Communications of the ACM, 31(6), 676-686 June. [32] Purdom, P. (1972). A sentence generator for testing parsers, BIT, 12,366-375. [33] Richardson, D. J., O’Malley, O., and Tittle, C. (1993). Approaches to specification-based testing, Proceedings of the ACM 3rd Symposium on Software Testing, Analysis, and Verification (TAV3),December, pp. 86-96. [34] Sabnani, K. K., and Dahbura, A. T. (1988). A protocol testing procedure, Computer Networks and ISDN Systems, 14(4), 285-297. [35] Shneiderman, B. (1987). Designing the U.ver Interface, Addison-Wesley, Reading, MA. (361 Shumway, M., and von Mayrhauser, A. (1996). Applying Domain-Based Testing and Sleuth to USWEST’S Personal Voice Messaging Services, Technical Report, Colorado State University, Computer Science Department, January. [37] StorageTek, StorageTek 4400 Operator’s Guide, Host Software Component (VM) Re1 1.2.0, StorageTek, 1992. [38] Tsoulakas, M. Z., Duran, J. W., and Ntafos, S. C. (1993). On some reliability estimation problems in random and partition testing, IEEE Transactions on Software Engineering, 19(7), 687-697 July. [39] von Mayrhauser, A,, Walls, J., and Mraz, R. (1994). Sleuth: A domain based testing tool, Proceedings of the International Test Conference 1994, October, CS Press, pp. 840-849. I401 von Mayrhauser, A., and Crawford-Hines, S. (1993). Automated testing support for a robot tape library, Proceedings of the 4th International Software Reliability Engineering Conference, November pp. 6-14. [41] von Mayrhauser, A., Walls, J., and Mraz, R. (1994). Testing applications using domain based testing and sleuth, Proceedings International Symposium on Sofmare Reliability Engineering 1994, November, CS Press, pp. 206-215. [42] von Mayrhauser, A., Mraz, R., and Walls, J. (1994). Domain based regression testing, Proceedings International Conference on Software Maintenance 1994, September, CS Press, pp. 26-35. [43] von Mayrhauser, A., and Mraz, R. (1995). The sleuth approach to aerospace software testing, Proceedings 1995 IEEE Aerospace Applications Conference, February, Snowmass, CO, pp. 61-75.

190

A. VON MAYRHAUSER AND R. MRAZ

[44]Figliulo, T., von Mayrhauser, A., and Karcich, R. (1996). Experiences with automated system testing and Sleuth, Proceedings 1996 IEEE Aerospace Applications Conference, February, Snowmass, CO, pp. 335-349. [45] Weyuker, E. J., and Jeng, B. (1991). Analyzing partition testing strategies, IEEE Transactions on Software Engineering, 17(7), 703-7 11 July. [46] Zeil, S. J., and Wild, C. A Knowledge Base for Software Test Refinement, Technical Report TR-93-14, Old Dominion University, Norfolk, VA.

Exception-handling Design Patterns WILLIAM G. BAIL Software Engineering Center The MITRE Corporation McLean, VA USA wbail@mitre. org

Abstract Achieving dependable behavior from complex software systems requires that the software logic be able to recover from anomalous conditions or exceptional states. Such conditions and states may arise from embedded defects in the code or from erroneous data provided to the software for processing. One technique for enhancing the ability of software to perform such recovery is the insertion of exception detection and handling features into the logic. Such features may depend on specific exception-handling language facilities or on general-purpose language constructs. This chapter provides an overview of design considerations necessary to implement such recovery, and presents a series of commonly used design patterns that have proved to be successful in enhancing dependable behavior.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exception-handling Concepts . . . Exception-handling Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exception-handling Design Strate 4.1 Allocation of Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Exception Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Global Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Local Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . Ineffective Exception-handling Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. 2. 3. 4.

...................... ................... ......................

191 193 195 197 198 202 210 217 22 1 222 229 237

1. Introduction

With the demand for increasingly reliable software systems and the corresponding increase in their complexity, much attention has been placed on techniques to improve the dependability of these systems. Recognizing that ADVANCES IN COMPUTERS, VOL. 49 ISBN 0-12-012149-2

I 91

Copyright 01999 by Academic Press All rights of reproduction in any form reserved.

192

WILLIAM G.BAIL

complex software systems cannot be developed without defects, focus has been placed on techniques designed to reduce the impact of such defects. These techniques include the insertion of logic to detect error states, to propagate messages indicating their occurrence, and to avoid (or reduce the impact of) system failures due to these states. At MITRE’SSoftware Engineering Center (SWEC) we have a technology focus on the assessment of the design of exception handling capabilities for large systems. Based on our experience we have formulated a set of design guidelines for use by projects in the development of highly dependable software systems. This chapter is an extension of a SWEC-developed tutorial: Exception Handling, or “When Bad Things Happen to Good Programs” [4], and summarizes the key aspects of exception handling design. While the core of the material is the same, there are extensive additions based on evaluations of large systems performed since the preparation of the tutorial in 1993. Note that there is a large body of related work on this topic. This chapter presents an overview. If the reader wishes to explore further, please refer to the references for additional material. This chapter contains five major sections: 0 0

0

0

Introduction-an overview of this chapter. Exception-handling concepts-an introduction to the basic concepts and terms used in this chapter. Exception-handling life cycle-a discussion of the activities associated with designing exception handling features across the software development life cycle. Exception-handling design strategies-a summary of the four major issues involved with the design of exception-handling features. These areas are:

- Allocation

of responsibility-an outline for allocating responsibility for performing exception handling activities between clients and servers; - Exception semantics-a description of defining the information to be communicated by the exceptions; - Global design patterns-a summary of the design issues associated with the role of exception handling design as a part of the system architecture (program-wide patterns for exceptions); - Local design patterns-a description of various design approaches for using language features for implementing exceptions.

0

InefSective design patterns-a delineation of ineffective design patterns for exceptions and their handlers.

EXCEPTION-HANDLING DESIGN PATTERNS

193

While most of the examples provided in this chapter are based on the Ada language, the underlying concepts are applicable to any language that provides exception handling, either explicitly (as does Ada) or implicitly through standard language features.

2.

Exception-handling Concepts

In this chapter we use the term exception handling to refer to a class of mechanisms and design approaches with the purpose of dealing with and mitigating the effects of embedded and latent defects in software. We refer to the client as the user of a capability provided by a server. As shown in Fig. 1, the client invokes a series of operations, each of which is performed by a server. If the server fails to carry out the requested operation, we say that it has encountered an exceptional condition. It may attempt recovery internally or it may send a message to the client indicating that the operation has failed. This message is called the exception, and sending the message is called propagation. There are many potential causes for exceptional conditions. These may be roughly classified into two main categories: 0

Software defects-erroneous logic in the code. Such defects may arise from many sources, including mistakes made by programmers, Client

Server

b FIG. 1. Relationship of client and server.

194

0

WILLIAM G. BAIL

mistakes in the design or in the requirements, or erroneous code produced by a compiler or application generator. Erroneous data-improper or unexpected data. Such data may be input by an operator, transmitted by another system, be corrupted by faulty hardware or by a noisy communications channel, or exist in databases used by the software.

If a software defect exists in the code, and this defect is executed, it may cause the software to enter into an error state, that is, a state of the program variables that is at variance from what was expected by the software design. In effect, the software defect has caused erroneous data to be present. When such an error state occurs, the server may be unable to carry out the operation. In such a situation, the component hasfailed. Exceptions are used to signal that component failures have occurred. If the failure is allowed to persist, it may extend from individual components to the system level, resulting in an overall systemfailure, observable by and impacting the users of the system. It could be argued that the software should be able to handle the occurrence of erroneous data, that the logic of the code should detect such data and avoid entering into an error state. Such avoidance is considered to be a key strategy in developing dependable software and is an integral part of designing exception handling features. In particular we define the following terms: 0

0

0

Exceptional condition: a software state of a system which is defined to be abnormal by some element of the system. Declaring an exception: the binding an identifier (name) to an exceptional condition. Raising an exception: the recognition in the software that a declared exceptional condition exists. Handling an exception: the software response to a raised exception.

Programming languages may provide explicit mechanisms for the definition, raising, propagation, and handling of exceptions. When using a language that provides such facilities, the term exception refers to the these mechanisms as well as other more general constructs used mechanism for identifying and reporting on exceptional conditions. Popular languages that provide such features include Ada, C++ [18], Eiffel [14], and Java [19]. A significant advantage to having such features is the separation of exception handling from normal processing, thereby reducing design complexity [ 16al. Exception handling generally involves three distinct functions: (1) Detection-the determination that the current state of computation is abnormal and unplanned.

EXCEPTION-HANDLING DESIGN PATTERNS

195

(2) Propagation-the notification to other portions of the software that an error state has been detected. (3) Handling-recovery actions to mitigate the effect of the error state. Possible actions include data correction, operator notification, and graceful termination (fail-safe). Exceptions therefore serve two roles:

(1) They provide a signal to the client that an operation (being performed by a server) has failed. (2) They supply information to the client about the failure. The client, at that point, has various options for continued operation, including:

(1) Correct the problem and retry (forward recovery [ 16al). (2) Roll-back to a previous state and continue ( b a c h a r d recovery [16a]). (3) Attempt correction and continue at a reduced capability (graceful degradation). (4) Skip the operation and continue. (5) Terminate execution under control (fail-safe). (6) Propagate the exception. (7) Record the exception to a logging file [ 151. (8) Do nothing. A combination of these options are also possible. For example, some systems commonly record occurrences of exceptions to a log file for later analysis, regardless of what other recovery is performed. Other systems attempt the operation a certain number of times before propagating the exception upwards to its clients.

3.

Exception-handling Life Cycle

Exception-handling design is a part of software design and is an activity that exists across all design phases. While the temptation is to treat it as a detailed design or coding issue, experience has demonstrated that unless the exception handling issues are addressed early, the resulting exception handling structures will be inconsistent across the system, resulting in unreliable and inefficient recovery. The approach to be taken for exception handling needs to be defined early in a software development project, and its design needs to be refined in concert with the design of the rest of the system. Issues such as the structure of exceptions, their semantics, their

196

WILLIAM G. BAIL

names and roles, etc. must be defined so that the software design may proceed. An early-defined approach allows the different parts of the system to base their exception-handling structures on a common design, facilitating effective and efficient behavior. Delaying the establishment of the approach will make it more likely that error handling will become piecemeal across the system, resulting in inefficient and ineffective control (often called ad hoc exception handling). According to John Goodenough from the Software Engineering Institute [9]: It is easy to think of exceptions as a kind of “add-on” feature of a software design, i.e., a facility whose use is left to the designers of individual modules and routines. In fact, exceptions are used most effectively only if the strategy guiding their use is developed in the earliest stages of a design. Moreover, effective use of exceptions requires attention throughout a design.

Likewise, according to Phillipe Kruchten [ 111: Defining error-handling strategies is an important part of software design and implementations that is often neglected, primarily due to lack of experience. The most important requirement is to define a consistent strategy or set of strategies, together with some decision criteria, to be used systematically over the whole application rather than relying on individual tastes and skills that can result in a very inconsistent blend of techniques.

Consequently, just as traditional system design extends from the architecture level to the detailed level, exception design has the same life cycle (see Fig. 2 ) . The decision about the kind and extent of exception handling structures to include in a software design must be based on the requirements allocated to that software. Expectations of high reliability require the use of exception mechanisms. If the user is expected to play a role in determining action

Software Design

Architectural

Exception Handling Design Issues

Definition of behavior

Global design patterns Local design patterns Global allocation of Local allocation of responsibility responsibility

FIG.2. Exception-handling design life cycle

EXCEPTION-HANDLING DESIGN PATTERNS

197

based on exceptional conditions, then the requirements must reflect this responsibility and the design must include the appropriate provisions to support this interaction. If, on the other hand, the requirements do not expect dependable behavior (such as for prototype development), the need for including exception handling features may be absent. Incorporating such features regardless of the overall specification of the product will result in wasted effort and increased cost. Development projects establish their general design policies early in a project. These policies are documented in various ways, such as Software Development Plans (SDPs) or Software Standards and Procedures Manuals (SSPMs). In the same way, the exception handling portions of the system need to be established early, in a policy statement. In such policies, the goals of the exception handling features of the system are defined, and the general design approaches to be used are established. This policy needs to be developed in concert with the software requirements to ensure that the policies address the same types of issues and are consistent with the behavioral goals of the software product. As the project progresses into architectural and detailed (procedural) design, the top-level and detailed design of the exception handling system is also refined. The way that exceptions are defined and propagated, standards of interaction are all established, and approaches to recovery are all established. These design decisions need to reflect the exception handling policies established during the requirements analysis phase.

4.

Exception-handling Design Strategies

There are four main topics that must be covered when designing exception handling for a system: 0

0

0

0

Allocation of responsibility-the assignment of error handling responsibility in the detection, propagation, and correction of error states (exception-handling protocols). Exception semantics-the conditions which the exceptions are to signal. Global design patterns-the overall structure of exceptions across the system to be developed. Local design patterns-(implementation mechanisms)-the specific language features that will be used to implement the exception handling logic.

In the next four sections we examine these issues and provide guidance for making tradeoffs appropriate for the system to be developed. The examples provided are all based on Ada 83.

198

WILLIAM G.BAIL

4.1 Allocation of Responsibility When designing exception handling structures for a system, it is necessary to allocate responsibility for taking action when exceptional situations occur. Such actions may include detection of error state, raising and propagation of exceptions, recovery, and continued operation. The responsibilities are allocated between the various clients (who request services from the servers) and the servers (who supply the services to the clients). The clients may include the users of the software, other systems, and components within the system. Each of these categories requires different treatment. One important decision that needs to be addressed is whether active or passive fault detection is to be employed [15]. With passive fault detection, the system does nothing about error detection until an error state occurs during execution. At that point, it reacts by performing some form of recovery. With active fault detection, the system performs periodic checks to determine if an error state is likely to occur (such as by checking argument values for legality). While passive error detection will not consume resources checking for dangerous conditions, it is likely to consume extensive resources as it performs recovery, Active error detection, on the other hand, may introduce inefficiencies as it performs checks, but it avoids that overhead associated with exception detection, propagation, and recovery. For active fault detection, the use of auxiliary functions is common (section 4.1.2). If the responsibilities are not allocated at the beginning of design, it is less likely that cohesive and consistent exception-handling behavior will be realized. If different software components do not share a common view of how to handle error states, system failure is likely. Allocation of responsibility takes place at two levels: the architectural design level, where responsibilities are defined across the different layers and major subsystems, and the detailed design level, where responsibilities are defined within the components. At all levels the resulting design decisions must be consistent to ensure that exception handling works effectively. Affected design elements include internal and external interfaces, since they form the basis for the propagation of exceptions across the system. The key decisions to be made include: 0

0 0 0

Who is responsible for detecting the exceptional condition (client, server, or both)? Who is responsible for propagation of the exceptions? Who performs recovery and where the recovery is to be accomplished? Are auxiliary functions needed, what types are to be provided, and who uses them (client or server)?

EXCEPTION-HANDLING DESIGN PATTERNS

199

The design of exception-handling features depends on the results of these decisions. Once defined, the design process can proceed confident that all parts of the system will adhere to the same conventions.

4. I. I

Detection, Propagation, and Recovery Responsibilities

By establishing responsibility for detection, propagation, and recovery, two types of impact may be avoided: 0

0

Missing actions-if the policies for taking action are not clearly defined, a client may assume that the server will be handling an exception, and the server may assume that the client will take action. In this case, no action will be performed, and the exceptional condition may not be detected, propagated, or handled. Duplicate actions-both the client and server may decide to take action. In this case, at best there will be an impact to the processing efficiency. At worst, the repeated attempts at recovery may further damage the program state resulting in system failure.

One way that the system could fail is due to inconsistent assumptions between the client and server. The server may attempt to perform a service and discover that the necessary resources were not present. A reasonable reaction would be to pass a status message back to the client, indicating that the requested operation failed. In this case the server is assuming that the client will check for the message and perform appropriate recovery. The client, however, may assume that the server would perform recovery, and will fail to take action, resulting in a system failure. For example, consider a function which is to write a series of messages to a file. A client may invoke the function, passing to it the message to be written. The file, however, may or may not be open. The server, rather than opening the file, returns an error code, assuming that the client will detect the error code, determine what went wrong, open the file, and re-invoke the function. The client, however, assumes that the server will detect whether the file is open or not, and fails to examines the error code, or fails to examine it for the file not open condition. Another way that the system could fail is if the client and server have different views about default decisions to be made. Consider a client that wants to display text on a screen. At some point, the color of the text needs to be defined. Suppose the client found itself in a situation where the color had not been defined yet it calls the server to display the text. The server could make an assumption about the default color to use, and display the text in this color without providing any information back to the client. The client, however, may not want the default color chosen, and would have chosen a different color had it known that the color had not yet been selected.

200

WILLIAM G.BAIL

A third failure mode could be caused by incompatible conventions between the client and the server. The client may assume that the server will indicate an error by passing a status parameter, while the server may instead rely on a language-based exception mechanism. If an exceptional condition is reached, the client will be expecting a status parameter, but an exception will be raised and potentially missed. The key basis for allocating responsibility is determining the appropriate place where recovery needs to take place. The context of the client or server, specifically the information available, determines the extent and success of the recovery actions. By allocating responsibility to a context where insufficient information is available, the effectiveness of the recovery will be compromised. If modest recovery goals are established, the basis for the decision would then shift to the efficiency of recovery processing, recognizing that not as much information is necessary to support the level of recovery planned. 4.1.2 Auxiliary Functions Auxiliary functions provide support for exception handling activities. These are called auxiliary functions because they do not directly support the required behavior of the software, but are instead used solely for exceptional conditions. There are two main categories of such functions: 0

0

Detection functions-used to detect exceptional conditions and avoid the raising of exceptions. Recovery functions-used to support various levels of recovery after exceptions are raised. Such functions include: - informational functions - logging functions - repair functions - rollback functions.

A detection function is a predicate that verifies that conditions are safe for the invocation of an operator. Such functions allow testing for conditions that must be true for an operation’s successful execution. One advantage of providing predicates for use by clients is the gain in efficiency. Raising and handling exceptions is generally costly in terms of processing time. If clients are able to determine that an exception will be raised if they invoke a server’s operation in advance of that invocation, then this cost of the exception can be avoided. Detection functions may be essential to allow clients to avoid entering into an exceptional condition. With the appropriate predicates, clients can take appropriate action before invoking operations. The use of predicates,

EXCEPTION-HANDLINGDESIGN PATTERNS

20 1

however, does not guarantee avoidance of exceptions. The responsibilities for their use must be defined so that both clients and servers can adhere to the protocols. Also, in multiple threads of control unless critical regions are set up, the predicate may mislead a client about a future state. If responsibility is not explicitly allocated, redundant tests may be performed by client and server. Overkill in provision and use of predicates can result in cluttered normal processing. When deciding whether to require that a client make use of a detection function, the following issues need to be assessed: 0

0 0 0

0

Whether detection functions will be available or required. The scope of visibility for the functions. The level of (in)efficiency that can be tolerated. The desired level of redundancy (duplicate actions performed by both server and client). Whether shared data will be used.

As an example, consider the following code where the package Stack has provided predicates for client use. package Stack i s f u n c t i o n Is-Full r e t u r n Boolean; procedure Push (Item : Item-type); f u n c t i o n Is-Empty return Boolean; procedure Pop return Item-Type; end Stack;

There are three alternative ways of designing detection function usage:

(1) Clients must use the functions Is-Full and Is-Empty prior to using the Push and Pop operations. (2) Servers use the functions prior to completing the operations. In this case, the functions can be moved to the package body since they do not need to be visible to the client. (3) Both clients and servers use the functions, thereby providing a level of redundancy as a safety-net. The provision of functions must be tempered by the complexity of doing so. In certain situations the predicate can be just as or more complex than the intended operation for which the predicate is testing. If the predicate is actually the operation itself in disguise then the operation is performed twice, perhaps with a severe performance penalty. Predicates should provide a

202

WILLIAM

G.BAIL

useful, cost effective capability. Duplication of function or complex processing that can result in performance impacts should be carefully considered.

4.2

Exception Semantics

When exceptions occur, they provide information about the exceptional condition to the client. Clients may use this information to perform recovery, to terminate execution, or to take other action. It is necessary to ensure that the exceptions provide the appropriate amount and type of information needed by the client so that the required level of recovery can be successfully accomplished. Clearly, for some types of recovery, detailed information may not required (e.g. fail-safe). For other types (correction of state), detailed information is essential. There are two aspects of information that need to be considered:

(1) Category of exception-the exception may indicate the location where the exception originated (origin-based),the cause of the exception (cause-based), the recommended action to be taken (recoverybased), or some combination of the three. Which of these should be selected needs to be based on the nature of the error condition that caused the exception and the needs of the client for recovery. ( 2 ) Granularity of exception-the amount of information carried by an exception. The granularity may range from fine-grained (providing detailed information about the exception, perhaps including its origin and its cause) to coarse-grained (providing general information, perhaps simply indicating that an exception occurred). The primary basis for deciding the type and granularity of information to be communicated is the type of recovery to be performed by the client. If a simple termination is desired, then detailed information about the exception may not be needed. However, if the exceptions are too coarse-grained, the information available to the client may be insufficient to effectively perform any recovery action because of an inability to discriminate between multiple causes for the exception. Exceptions that are coarse-grained tend to blur the distinction between origin, cause, and recovery, since in the extreme case, a coarse-grained exception simply indicates that an error state was encountered. If correction and recovery is planned, then additional information must be supplied so that the client may take appropriate action. The more information communicated, the more the client knows about why the exception was raised, and the more that the client can do about performing recovery. As would be expected, the more information, the more processing

EXCEPTION-HANDLING DESIGN PATTERNS

203

overhead and complexity is added to the logic to process the exception. If the exceptions are too fine-grained (i.e. carry too much information), the amount of processing overhead necessary to maintain the information may impact the performance of the system (see Fig. 3). This tradeoff is the basis for deciding on the appropriate leveI of granularity needed for exceptions in a system. The first part of the decision involves determining the appropriate responses for the clients throughout the system. Once these have been identified, then the corresponding granularity of the exceptions can be established. In summary, the benefits to providing information include:

(1) The efficiency and effectiveness of recovery may improve as more information is provided to support the recovery. (2) Additional information facilitates defect removal if the exception information is preserved. The costs to providing information include:

(1) The consumption of additional processor and memory resources to handle the information. (2) The increase of design and code complexity associated with defining and interpreting the information, potentially raising cost of development and the risk of faults. Deciding the level and type of information to be carried by exceptions involves balancing the costs of the information against the benefits.

Range of Granularity Coarse

Less

Fine

<

) More

Benefits Information communicated Level of recovery possible

costs Complexity Processing overhead FIG.3. Range of granularity.

204

WILLIAM G.BAIL

There are two key elements that need to be evaluated as a part of making this tradeoff (1) The purpose for which the client is to use the exception information. (2) The efficiency of processing that is needed (or the inefficiency that can be tolerated).

Selecting an inappropriate granularity can result in ineffective recovery and inefficient error processing. However, the risk of too little information is insufficient recovery. The tradeoff involves balancing the amount of information provided about the error state against the amount of processing needed to identify this information. The result of the decision will be reflected in the exceptions that are declared as well as in the way that the exceptions are handled and raised. Choosing a level of granularity that is inconsistent with the needs of the clients can result in inefficiencies and even failures. In general origin-based exceptions are used when it is important for the client to know where the exception was raised, that is, the operation that failed. Circumstances that favor origin-based exceptions are those where the recovery actions differ depending on the operation, even if the same circumstances caused the failure. Cause-based exceptions are used when the condition causing the exception is more important than where the exception occurred. Such concerns are typical for sets of related operations which may have similar failure modes, and the recovery is common across these operations. An example is the predefined Ada package Text-10, which contains operations for different classes of I/O, including character, string, integer, floating point, fixed point, Boolean, enumeration types. This package defines a set of seven exceptions which may be raised for multiple operations supplied by the package. Mixed-base exceptions are used when knowledge of both the operation and the cause are needed for recovery or further action. These granularity issues are summarized in Table I. In the situation where a fine-grained exception is reported but a coarsegrained exception is needed, the user will collapse exceptions and handle in a single handler thereby ignoring the discrimination. This can introduce unnecessary detail for the user to contend with; forgetting one exception could easily happen when granularity is too fine. If, however, a coarsegrained exception is reported but a fine-grained exception is needed, then the user will need to provide additional processing to determine the operation where the exception occurred. This creates complexity in normal processing. Unfortunately, the user may not be able to compensate for lack of granularity. The supplier may need to provide information through another

205

EXCEPTION-HANDLINGDESIGN PATTERNS

TABLE I SUMMARY OF GRANULARITY ISSUES

Range of granularity Base of exception Origin based

Cause based

Recovery based

Reason to select as basis Recovery actions differ depending on operation

Recovery actions differ depending on cause

Criteria for granularity

Coarse-grained General

Fine-grained

Specific

Purpose

Client needs to know that an exception occurred

Client needs to know that an exception occurred in a set of related operations

Client needs to know where the exception occurred

Possible granularity

Mapped to general set of operations

Mapped to similar operations

Mapped to specific operation

Example

Stack-Failed

control-failed actions-failed

pop-failed push-failed

Purpose

Client needs to know that an exception occurred

Client needs to know general type of exception occurred

Client needs to know what caused the exception

Possible granularity

Mapped to general set of causes

Mapped to similar causes

Mapped to specific causes

Example (Text-10)

10-failure

Status-Error Mode-Error Use-Error

Mode-error-in-file Mode-error-out-file

Client needs to know that an exception occurred

Client needs to know the general type of recovery action needed

Client needs to know what action to take to recover

Mapped to general recovery options

Mapped to sets of recovery classes

Mapped to specific recovery options

Reinvoke

Update arguments and reinvoke

Rename input file and reinvoke

Recovery Purpose actions independent of operation and origin Possible granularity Example

mechanism such as global data. The supplier is implicitly obligated to provide the granularity chosen; the user is obligated to handle exceptions provided.

4.2.7

Coarse-grained Exceptions

With coarse-grained exceptions, the information communicated to the client is at a general level. Neither the specific location where the exception

206

WILLIAM G. BAIL

is raised nor the cause of the exception is specifically identified. At the most coarse level, the exception simply indicates that an exception has occurred. With such an approach, the client’s options for recovery are limited to propagating the exception or terminating execution. When recovery is considered to be infeasible or not recommended (such as in a fail-safe situation), the use of coarse-grained exceptions may be the most efficient design choice since little overhead is consumed in providing and interpreting additional information. With such exceptions, client code may appear as in the example: Procedure Coarse-Grain is

... ... ...{sequence of ...

Begin

statements}

Exception raise; End CoarseGrain;

At a less coarse level of granularity, an exception may signify that an error has occurred in a set of operations or was caused by a general set of causes. The goal with this level is to facilitate a moderate amount of recovery, made possible by informing the client about the nature of the exception. No more information may be necessary. In the following example of an origin-based exception, the exception Stack-Error notifies the client that an error state has occurred during the execution of one of the associated operations. generic type Item is private; package Stack is type Stack is limited private; procedure Move (From : in out Stack; To : in out Stack); procedure Clear (The-Stack : in Out Stack); procedure Pop (The-Item : out Item; The-Stack : in out Stack); procedure Push (The-Item : in Item; The-Stack : in out Stack); Stack-Error : exception; private

...

end Stack;

In this approach, all anomalous conditions associated with stack operations

EXCEPTION-HANDLING DESIGN PATTERNS

207

are reported by a single exception. To handle this exception, a client may have code like: with Coarse-Stack procedure Use-Coarse-Stack(the-item: Integer) is package Int-stack is new Coarse-Stack(integer); the-stack : Int-stack.stack; begin Int-stack.clear(the-stack); Int-stack.push(the-item, the-stack); except ion when Int-stack.stack-error =>

....

end Use-Coarse-Stack;

When this exception is raised, the client cannot discern which operation failed, but does know that the exception was raised by one of the operations defined in package Coarse-Stack. Alternatively, coarse-grained cause exceptions can be declared for the same package: generic type Item is private; package Stack is type Stack is limited private; procedure Move (From : in out Stack To : in out Stack); procedure Clear (The-Stack : in Out Stack); procedure Pop (The-Item : out Item; The-Stack : in out Stack); procedure Push (The-Item : in Item; The-Stack : in out Stack);

Stack-Overflow : exception; Stack-Underflow : exception; private

...

end Stack;

In this example, the cause of the error is indicated by the exception that is raised, although the specific operation is not identified. With the cause identified, a recovery scheme is suggested to the client.

4.2.2 Fine-grained Exceptions With fine-grained exceptions, the information communicated to the client is at a specific level. This information may indicate the specific

208

WILLIAM G.BAIL

origin of the exception, the cause of the exception, a specific recovery action, or a combination of all three. With fine-grained exceptions, the client’s options for recovery are expanded, assuming that the information can be used to perform appropriate recovery. However, there is additional processing overhead associated with providing and handling fine-grained exceptions. In addition, the complexity of the code is increased. A fine-grained origin-based exception may be implemented as shown in the following example. generic type Item is private; package Stack is type Stack is limited private; procedure Move (From : in out Stack; To : in out Stack); procedure Clear (The-Stack : in out Stack); procedure Pop (The-Item : out Item; The-Stack : in out Stack); procedure Push (The-Item : in Item; The-Stack : in out Stack); Move-Error : exception; Clear-Error : exception; Pop-Error : exception; Push-Error : exception; private

...

end Stack;

The user, when encountering an exception raised by this package, will be informed about the specific operation in which the exception originated. Handling of these exceptions is more complicated as shown in the following example: with Fine-Stack procedure Use-Fine-Stack(the-item: Integer) is package Int-stack is new Fine-Stack(integer); the stack : Int-stack.stack; begin Int-stack.clear(the-stack); Int-stack.push(the-item, the-stack); except ion when Move-Error =>

...

EXCEPTION-HANDLING DESIGN PATTERNS

209

when Clear-Error =>

... ... when Push-Error ... when OTHERS => ...

when Pop-Error ==> =>

end Use-Fine-Stack;

Fine-grained cause-based exceptions can also be defined: generic type Item is private; package Stack is type Stack is limited private; procedure Move (From : in out Stack; To : in out Stack); procedure Clear (The-Stack : in out Stack); procedure Pop (The-Item : out Item; The-Stack : in out Stack) ; procedure Push (The-Item : in Item; The-Stack : in out Stack); Move-Underflow : exception; Move-Overflow : exception; Clear-Error : exception; Pop-Error : exception; Push-Error : exception; private

...

end Stack;

4.2.3 Combining Origin-, Cause-, an< Recovery-based Excep ti0 ns In some situations, it may be beneficial to define exceptions that combine origin-, cause-, and recovery-based exceptions. Providing such semantics allows more options for the user, but may result in more complexity in the logic required for handling the exceptions. If, for example, the client wants to be concerned with only the cause then its handlers will be clustered by cause for all operations, effectively nullifying the information conveyed concerning origin and recovery. Thus the level of granularity provided must be dealt with in handling even when the granularity is not required by user.

210

WILLIAM G. BAIL

package Stack i s t y p e Stack i s l i m i t e d p r i v a t e ; procedure Copy (From-the-stack: i n Stack; To-the-stack : i n o u t Stack); procedure Clear (The-stack : i n o u t Stack); procedure Pop (The-stack : i n o u t Stack); f u n c t i o n Top-of (The-stack : i n Stack) r e t u r n Item;

...

Copy-Overflow : e x c e p t i o n ; Push-Overflow : e x c e p t i o n ; Pop-Underflow : e x c e p t i o n ; Top-of-Underflow : e x c e p t i o n ; private

...

end Stack;

4.3

Global Design Patterns

When designing exception handling capabilities for a system, it is necessary to define its global structure. That is, on a broad scale, the error handling interactions between the different parts of the system need to be coordinated to ensure consistency and efficiency. This planning needs to coincide with software architectural design, and its results need to be reflected in the internal interfaces between the major components and architectural layers. There are two aspects to these interactions: 0

0

Factorization-involves extracting exceptions from the same modules as the operations which raise the exceptions, and combining them in separate modules. This design issue also needs to be considered as a part of the detailed design phase. Partitioning-involves defining the ways that exceptions are propagated between architectural elements of the system. Generally some form of partitioning is necessary to ensure that propagated exceptions make sense in the context of the client, since their significance changes as they flow between architectural elements. Partitioning has two flavors (see Fig. 4):

- Horizontal partitioning-involves

the interplay of exceptions between subsystems or components within the same architectural layer;

EXCEPTION-HANDLINGDESIGN PATTERNS

21 1

Horizontal partitioning

Layer I

al panitianing

Layer 3

lzE%-e%e

FIG.4. Horizontal and vertical partitioning.

-

Vertical partitioning-involves the interplay of exceptions between subsystems or components within different architectural layers.

4.3.1 Factorization With factorization, exceptions are moved from individual packages and moved into separate components. With this approach, exceptions may span operations and classes. The benefits of factorization include:

(1) (2) (3) (4)

Higher visibility Better management of exceptions Simplified handling Streamlining of name space

There is however a drawback, in that with factorization the granularity of the exceptions tend to coarsen, and identification of the specific cause or origin becomes more difficult. In this approach, exceptions are defined that cover operations within multiple packages. Factorization can be employed when the operations have the same types of error conditions and the recovery modes from these conditions are common across the packages. This approach allows for finegrain detection but high proliferation of unique instances of equivalent exceptions. For example, operations associated with stack and queue data structures have similar error conditions: overflow and underflow. Before factorization, they may have the following appearance:

212

WILLIAM G. BAIL

package Stack is package Queue is type Queue is limited private: type Stack is limited private: procedure Copy (From: in Queue; procedure Copy (From: in stack; To : in out Queue): To : in out Stack): procedure Clear (Item : in out Stack): procedure Clear (Item : in out Queue): procedure Pop (Item : in out Stack): procedure Pop (Item : in out Queue):

...

...

Overflow : exception: Underflow : exception: private

Overflow : exception: Underflow : exception: private

end stack:

end Queue:

...

...

Factoring the exceptions will produce a new package containing the exception, with both original packages using this package as a resource. By doing so, the exceptions are placed at a higher level of visibility, similar to what can be seen in Ada predefined 1/0packages. Any package that needs these exceptions uses the exception package to identify the exceptions; commonality has streamlined the name space. package The-Exceptions is Overflow : exception; Underflow: exception; end The-Exceptions;

The original packages will then have the appearance: with The-Exceptions; with The-Exceptions; package Queue is package Stack is type Queue is limited private: type Stack is limited private: procedure Copy (From: in Queue: procedure Copy (From: in Stack: To : in out Queue): To : in out Stack): procedure Clear (Item : in out Stack); procedure Clear (Item : in out Queue); procedure Pop (Item : in out Stack): procedure Pop (Item : in out Queue); private

private

end stack:

end Queue;

...

...

The cost of such visibility and convenience is the loss of granularity. Multiple operations in both packages will raise the same exception for the same reason but the client cannot distinguish between the operations or the packages. When fine-grain discrimination is required during elaboration, factorization is critical to avoid anonymous exception propagation. For generic packages, the factorization of exceptions can eliminate the need to handle multiple instantiation-specific exceptions when the same action will be taken in all cases. However, when it is necessary to discriminate by

EXCEPTION-HANDLINGDESIGN PATTERNS

213

instantiation, such factorization will eliminate the granularity needed. When the semantics of an exception are shared by multiple packages (units), factorization across those packages can streamline the handling of exceptions. However, such generalization may lead to complexity for clients if more discrimination is needed. If exceptions are defined within the generic package, there will be one exception set per instantiation. In this case the client must provide handlers for each instantiation. If it is important to be able to isolate the exception to a specific instantiation, then they should not be factored. In this example, exceptions are embedded within a generic spec: generic type Item is private; package Stack is type Stack is limited private; procedure Copy (From-the-stack: in Stack; To-the-stack : in out Stack); procedure Clear (The-stack : in out Stack); procedure Pop (The-stack : in out Stack);

...

Overflow : exception; Underflow : exception; private

...

end Stack; with Stack; procedure Use-Stack is package Int-stack is new Stack(integer); package Char-stack is new Stack(character); begin

...

except ion when Int-stack.overflow => -- report integer stack overflowed when Char-stack.overflow; -- report character stack overflowed end Use-Stack;

If the cause of an exception is needed in a general sense, but we do not need to know the specific instantiation, then factoring out the exceptions to an exception package can result in more streamlined exception handling at the cost of ambiguity in determining the exact origin of the problem.

214

WILLIAM G. BAIL

In this example the exceptions placed in a separate package package The-Exceptions is Overflow : exception; Underflow: exception; end The-Exceptions; with The-Exceptions; generic type Item is private; package Stack is type Stack is limited private; Overflow : exception renames The-Exceptions.Overflow; Underflow : exception renames The-Exceptions.Underflow; procedure Copy (From-the-stack: in Stack; To-the-stack: in out Stack); procedure Clear (The-stack : in out Stack); procedure Pop (The-stack : in out Stack);

...

private

...

end Stack;

The client provides a single handler regardless of the origin of the exception: with Stack; with Queue; procedure Use-Stack-and-Queue is package Int-stack is new Stack(integer); package Char-queue is new Queue (character); begin

...

exception -- Exceptions can be referenced by queue or stack, -- but not both since names are aliases for one -- another. A s a result o n l y cause an be determined. when Int-stack.overflow => -- report something overflowed when Char-queue.underflow; -- report something underflowed end Use-Stack-and-Queue;

Raising exceptions during elaboration of a package body has implications for other exception processing. If the exceptions are declared in the package specification, and the elaboration fails, then any discrimination as to cause of exception will be lost. The exception will propagate anonymously because the package has not been successfully elaborated. If granularity of exceptions is important during package body elaboration, then factorization

215

EXCEPTION-HANDLING DESIGN PATTERNS

of exceptions to a separate exceptions package will ensure the cause of exception is propagated. It is not necessary to use the language’s built-in exception handling features to perform factorization. One viable approach is to define a set of packages that manage special variables used to maintain information about exceptional conditions. Access to these variables may be controlled through the definition of access functions and by defining the status variables as local to the package. This idea is further described in later sections.

4.3.2 Partitioning Partitioning involves defining how exceptions propagate across layers or subsystems within applications. In general, when exceptions propagate outside of their immediate context, their meaning takes on a different significance. Partitioning therefore involves defining how the exceptions are mapped to forms compatible to the context in which the exception is propagated. Partitioning has two flavors: 0

0

Horizontal partitioning-involves the interplay of exceptions between subsystems or components within the same architectural layer. Vertical partitioning-involves the interplay of exceptions between subsystems or components within different architectural layers.

Establishing partitions requires a mapping strategy which defines how exceptions propagate across components. When defining maps, it is important to differentiate between direct exceptions, which are raised by the component which is performing the propagation, and indirect exceptions, which are received by the component which must then decide whether to propagate and how. Maps may be 1-1, where every exception received is propagated, or filtered, where exceptions may be captured. There are four general types of mapping strategies that can be selected (see Fig. 5): 0

Preserved-preserved maps maintain the exceptions across component boundaries without change. These are the simplest, but involve a risk of Refine

Generalize

Translate

FIG.5 The four types of exception maps.

Preserve

216

0

0

0

WILLIAM G.BAIL

causing an inappropriate exception that loses meaning in its new context. Preserved maps are usually chosen for direct exceptions, and are 1-1. Translated-translated maps convert exceptions to forms that are relevant to the client component. Such maps often involve a simple name change, and are 1- 1. Generalized-with generalized maps, groups of exceptions are mapped into a single exception. This map dilutes the semantics of the exception, thereby increasing its granularity. These maps are 1-1. Refined-refined maps perform filtering on exceptions. As such, these maps not 1-1, in that not every exception is propagated. With these maps the server performs internal recovery before propagating any exceptions.

With preserved maps, upon receiving an exception, a module may perform some cleanup, but will then propagate the exception unchanged up to its client. This approach makes sense only when the client has an understanding of the exception that is raised. A preserved map has the general pattern: Client

Server

Procedure Client is

procedure Server-op is

... Begin ... server-op ...

Exception When exp-a =>

...

When exp-b =>

...

when Others =>

...

... ...

Begin

proc-service

...

Except ion When exp-a => {some repair} raise; When others => raise; End ;

End

With translated maps, exceptions that are received by a module are renamed before they are propagated back to the client. This approach is used when the client requires the same level of granularity but requires a different semantics. With generalized maps, exceptions that are received by a module are mapped to fewer different exceptions. This approach is used when the client requires a lower granularity and when the semantics needs to be altered to adapt to the client.

EXCEPTION-HANDLING DESIGN PATTERNS

217

With refined maps, exceptions received by a module are processed, with recovery attempted. Once recovery internally is no longer possible, a new exceptions is propagated to the client. This approach is used whenever a shift in context occurs, and a collection of exceptions needs to be interpreted prior to propagation. It is important to define appropriate maps for exceptions as they cross component boundaries. If they are not mapped in a way that signals the appropriate message, unexpected side-effects may occur such as: 0

0

0

Anonymous exceptions-locally declared exceptions are allowed to propagate out of scope. A client receiving such an exception may not be prepared to handle it appropriately. Failure to resume normal processing-the exception may not be properly handled by clients as it propagates, resulting in system failure when the exception propagates to the top level of the system. Premature termination-the exception condition may be masked prior to completing action for the condition, resulting in a continued error state and eventual system failure. 4.4

Local Design Patterns

At the programming-in-the-small level, the specific implementation mechanisms that are to be used for exceptions and their handling must be identified. Several approaches to the design of exception handling structures have been used. Many of these approaches have evolved as standard practice and have fallen into use as idiomatic structures, that is, usage of common general-purpose language constructs to implement error handling logic. In addition, the use of built-in language facilities that are specifically for exceptions are also prevalent. These approaches can be generally classified as data-based, control-based, value-based, and language-based. In this section we examine the first three of these approaches. Detailed treatments of the exception handling features of programming languages can be found in the reference manuals for those languages [18, 14, 19,201. The different categories of local design patterns are listed in Table 11.

4.4.1

Data-based

Data-based approaches rely on the use of program variables to support error handling, with predefined values being used to detect or propagate error states. With these approaches, the variables are used to convey information about the exceptional conditions. There are two major variations: distinguished values and status parameters.

218

WILLIAM G. BAIL

TABLEI1 CATEGORIES OF LOCAL DESIGNPATTERNS

Error Handling Function Category Data-based Control-based Value-based Language-based

Approach Distinguished values Status parameters Label parameters Procedure parameters Conditionals/predicates Selectors Built-in exception mechanisms

Detection

Propagation

J J

J J J

J

J

J

J

J

J J J

Handling

4.4.1.1 Distinguished Values In this approach, variables that exist in the program and are used for normal processing are augmented with unique values. These unique values are predefined with specific meanings and are used to communicate the occurrence of exceptional conditions. As such, they piggy-back on variables that also carry legitimate values.

Definition Distinguished values: a convention that associates one or more values in the range of a computation with reporting on the status of the computation. Distinguished values are used to detect error states when such states are indicated by a notification from another modules, as well as to propagate error notifications, by setting the distinguished value for other modules to read. Generally, if the returned value is not one of the distinguished values, then the computation has been successfully performed. The language C when used in an UNIX environment often uses distinguished values as a way of indicating to the client that a called function failed in its processing. The function may return a positive integer or 0 as a result (e.g. a process id) or a negative value to indicate failure. For example: int pid; pid

/ * integer variable to store process id returned by vfork * /

/ * spawn a process, get process id or status * / / * -1 is a distinguished value => vfork failed * / perror ("vfork"); / * report the error * /

=

vfork();

if (pid == -1)

/ * else proceed

... * /

More than one distinguished value may be set aside to indicate failure. Depending on the defined conventions in any system or environment, any number of distinguished values may be used to provide additional details of exceptional conditions. Finer levels of granularity require defining multiple distinguished values so that the client may distinguish between causes for the error condition.

EXCEPTION-HANDLING DESIGN PATTERNS

219

For this approach to work effectively, the client and server must be consistent in their use of the distinguished values. If different portions of a program rely on different conventions, problems can arise. Care must be exercised, since this approach can cause problems in nested function calls when the return value is not checked prior to its use in the larger expression. For example: Varl

:=

Function2 (Function1 (Some-Value));

In this case, if Functionl fails and returns an error code, the client will not detect it, but will provide this error code as the argument value to Function2. This example points out the primary weakness of this approach, in that the same mechanism is used to provide the result of the operation as well as its status. Such abstraction overload can increase the risk of defects and can make the program more difficult to comprehend.

4.4.7.2 Status Parameters A status parameter is a separate parameter used to convey information on the status of a computation. Status parameters are often referred to as return codes. This approach is different from a distinguished value since the parameter’s sole use is as an indicator of the success or failure of the requested computation. Status parameters may be either fine or coarse grain. They may simply report success/failure: procedure Pop (From: in out Stack; To: out Integer ; Failed: out Boolean);

or they may provide detail on an exceptional condition: type Math-Status is (OK, Underflow, Overflow,

Illegal-Argument, Internal-Error); procedure Sin (Of : Radians; Result : out Radians; Status : out Math-Status);

This approach presents some minor problems for strict functions (e.g. forced to return records with a status component or use pass by reference), but avoids the problem of having to define a distinguished value. Status parameter are used to detect error states when such states are indicated by a notification from another modules, as well as to propagate error notifications, by setting the distinguished value for other modules to read.

4.4.2 Control-based The control-based approach for exception handling is based on the idea that upon the detection of an error state, the control is passed to a predefined

220

WILLIAM G.BAIL

section of code that has been written specifically to handle such errors. This approach places a strong reliance on programmer conventions, with little compile-time consistency-checking in many cases. Because of the support provided by modern programming languages, the exception handlers may be textually remote from the point of where the exception was raised, making the process of understanding the code more difficult. In addition, multiple paths of control are defined which, in some cases, could be widely diverging. What happens when the handler procedure returns control to the code that identified an exceptional condition is not defined. However, it is more difficult for the programmer to ignore exceptional conditions, a useful effect. As such, control-based approaches are used for propagation and handling of error states, and are generally not useful for detection of error states. There are two main types of control-based exception handling: label parameters, and procedure parameters.

4 . 4 2 7 Label Parameters Some languages permit labels to be passed as parameters. Control can branch to the label passed as a parameter as decided by the called function (the server). In order to ensure a consistent use of these features, it is necessary for the developers to define consistent conventions across a system so that one or more label parameters can be used to indicate where to transfer control if a specific condition occurs. The following example is from Fortran77 1/0 services: CLOSE (lO,STATUS=‘DELETE’, ERR=666) where: 10 is the unit to be closed 666 is the label to branch to if an error occurs

4.4.22 Procedure Parameters Some languages permit procedures to be passed as parameters. Control can branch to the procedure passed as a parameter as decided by the server (the called procedure). As with label parameters, it is necessary to define consistent conventions across a system. The following example is in Pascal: Client I := Tryit (X, Handlerl);

J : = Tryit (Z, Handled);

Server function Tryit (X : real; procedure Err-Exit (Msg: String)) : Real begin if X = 0.0 then Err-Exit (“Oargument”);

If a value of 0.0 is passed as input, the function Tryit will invoke the supplied error routine, either Handlerl or Handler2.

EXCEPTION-HANDLING DESIGN PATTERNS

4.4.3

221

Value-based

Value-based exception handling techniques are primarily used for the detection of error states through the use of predicates to examine the program state and to select alternative program states. The forms usually drafted include conditional statements as well as selector or case statements, and are generalized forms of the previous cases examined above. They are similar to status parameters except that they are not associated with a function’s return code. As such, there is more flexibility for defining and manipulating them across a system, including managing them as global variables. When specific variables are designated as exception indicators, one effective approach is to create a unique service package encapsulating the variables, and to control access to these variables by providing access functions. This approach is described to more detail in section 4.3.1, Factorization.

5.

Ineffective Exception-handlingDesign Patterns

When designing error handling features in a system, it is important to make optimum use of whatever language features are available. Lack of experience with these features could lead to ineffective use and even to degradation of program behavior. In this section we examine several ineffective design patterns involving built-in language features that should be avoided. Note that this taxonomy addresses error-prone usage patterns in Ada. These guidelines are general, however, and can easily be extended and applied to other languages. It is crucial to understand the semantics of all features in the language of implementation. Since exception handling interacts with many other language features, it is important to understand these interactions and the ramifications so that problems with the exception handling can be avoided. Many if not all of the error-prone patterns can be avoided with either a better understanding of the language semantics or more attention to detail. Although it is not possible to say that these error-prone patterns should not be present in an application, each instance of a pattern should be examined to be sure that it is achieving its desired function. There are in general two types of ineffective design patterns: 0

0

Exception-bused patterns-those that misuse the language’s exception mechanisms. Feature-interaction bused-those that interact with other language mechanisms to corrupt the exception-handling processing.

222

WILLIAM G.BAIL

5.1

Exception-based

The set of exception-based ineffective design patterns is summarized in Table 111. In these patterns the language’s built-in exception handling mechanisms are misused. 5.1.1 Predefined Exceptions Languages that provide exception handling features generally include a set of predefined exceptions that cover specific erroneous conditions. Proper use of these predefined exceptions is essential to preserve their effectiveness, and to ensure that their use is consistent across multiple systems. 5.1.1.1 Explicit Raising of Predefined Exceptions A predefined exception generally should be raised only implicitly (that is, through the built-in language mechanism) to avoid confusion. If an application detects a condition that will, if uncorrected, result in the implicit raise of a predefined exception, the programmer should: (1) Correct the condition and continue processing, or (2) Raise a user-defined exception.

TABLE111

INEFFECTIVE EXCEPTION-BASED DESIGNPATTERNS Category

Design Pattern

Predefined exceptions

Explicit raising Renaming Function fall-through Unset out parameters Null handlers Inadvertent mapping Nested block statements Default handlers Anonymous exceptions Object declaration initialization Propagation of exceptions by package bodies

Handlers

Propagation

EXCEPTION-HANDLINGDESIGN PATTERNS

223

Consider the following example: procedure Explicit-Raise is begin <sequence-of-statements>

...

if then raise Constraint-Error; end if ;

...

end Explicit-Raise;

Removing the predicate will have no effect on the behavior of this code, since the exception will be raised anyway. If the programmer goes to the effort of detecting this condition, then the code should take advantage and correct the problem before the exception is raised (and thereby avoid the inefficiencies inherent with such raises). Alternatively, the programmer can raise a user-defined exception that is differentiated from the predefined one.

5.1.1.2 Renaming of Predefined Exceptions Predefined exceptions should not be renamed. Such renaming creates aliases that obscure the handling of the predefined exceptions and may potentially dilute their semantics. The renaming of user-defined exceptions is acceptable, since such exceptions are under the control of the developers. For example: procedure Renaming is Local-Constraint-Error

:

exception renames Constraint-Error;

begin <sequence of statements> raise Local-Constraint-Error; end Renaming;

5.7.2 Exception Handlers Careful design of exception handlers is essential to ensure efficient and appropriate recovery. There are several commonly-seen design patterns that should be avoided to ensure optimal recovery.

5.1.2.1 Function Fall-through In Ada, if an exception handler for a function ends without executing either a return or a raise, control drops through the bottom of the function, raising the predefined exception Program-Error. Consider the example:

224

WILLIAM G. BAIL

function Fall-Through return Integer is begin <sequence of statements> exception when Trivial => return 0; when others => Put-Line ("Problem in Fall-Through"); end Fall-Through ;

While such an event can also occur in normal code, the absence of a return statement is much more obvious and is therefore more readily caught. In exception handlers, the multi-exit and go-to aspect of exceptions complicates inspection. This mistake results from simple oversight, but with potentially big consequences. This problem has been observed many times in real project code.

5.1.2.2 Unset Out Parameters When a handler does not propagate an exception, care should be take to set (or reset) the values of all our or in out parameters. If the handler does not set the values for these parameters, the calling subprogram may attempt to use these values erroneously. If the others handler in the following example is executed, callers of Unset-Out will have no indication that a problem occurred, yet the values could be in an indeterminate state with Text-10; procedure Unset-Out (Paraml : out Typel; Param2 : in out Type2 ) is begin <sequence of statements> except ion when Exception1 => raise; when others => Text-IO.Put-Line ("Problem in Blah"); end Unset-Out ;

5.7.2.3 Nu// Handlers A null handler stops the propagation of an exception (or possibly all exceptions if the handler uses the keyword others.Experience has shown that the effect of a null handler is typically not the desired behavior in an application since it effectively nullifies the benefits of having raised the exception, and raises the risk of continued erroneous execution. The following example shows a typical null handler. procedure Null-Handler is begin <sequence of statements>

EXCEPTION-HANDLING DESIGN PATTERNS

225

exception -- Block the exceptions from being propagated when others => null; end Null-Handler ;

There are however situations where such a structure would be justified: 0

0

Multi-language interaction-if an application that is written in C calls a component written is Ada, it is necessary to ensure that no exceptions propagate from Ada into C, since such exceptions cannot be handled by the C program, and will therefore result in failure. Preservation of firewall-firewalls are used to isolate different sections of code to ensure that they do not interfere with each other. One advantage is that failures in one section will be less likely to cause failures in other sections. In such a case, a null handler may be necessary to preserve the integrity of the firewall.

5.1.2.4 Inadvertent Mappings In an inadvertent mapping, a userdefined exception is raised, but is potentially overridden by local exception handling in response to the rise. Note that instances of inadvertent mapping could execute for long periods of time before yielding an unexplained propagation sequence that violates the hierarchies. Layers of exceptions allow for filtering of information as propagation proceeds (refer to section 4.3) but inadequate attention to mapping can result in unwanted, unexpected, and unpredictable side-effects. In the following example, the Error-in-Logic exception is raised. The procedure proceeds to log this exception using Logging-Procedure. However, within the logging procedure, the call to Text-I0 may itself raise another exception which is reraised by Inadvertent-Mapping. The intent was to raise Error-in-Logic. procedure Inadvertent-Mapping is begin

...

--

An error in logic is detected raise Error-in-Logic;

...

exception when Error-in-Logic => Logging-Procedure; raise ; end Inadvertent-Mapping;

226

WILLIAM G. BAIL

procedure Logging-Procedure is begin Text-1O.Open (...);

...

-- Text-I0 calls may raise Mode-Error, Status-Error, etc. -- mapping the original exception into an 10-Exception Text-1O.Close ( . . . ) ; end Logging-Procedure;

5.1.2.5 Nested Block Statements Block statements in exception handlers are one technique for preventing inadvertent mappings. However, the use of nested block statements in exception handlers can result in unexpected run-time behavior due to the complexity of the handler. All instances of nested block statements should be closely examined to ensure that the desired behavior will result. Consider the following example in which the procedure blocks the propagation of any exception that called procedure Logging-Procedure may raise. procedure Blocking is begin

...

--

An Error-in-Logic is detected raise Error-in-Logic;

...

exception when Error-in-Logic => begin Logging-Procedure; raise; exception when others => null; end ; end Blocking ;

In the next two examples the procedure blocks the propagation of any exception that Logging-Procedure raises, but ensures that the primary exception, Error-In-Logic, is propagated: procedure Not-Blocking1 is begin

...

--

An Error-in-Logic is detected raise Error-in-Logic;

...

except ion

EXCEPTION-HANDLING DESIGN PATERNS

227

when Error-in-Logic => begin Logging-Procedure; raise; except ion when others => raise Error-in-Logic; end ; end Not-Blocking1 ; procedure Not-Blocking2 is begin

...

--

An Error-in-Logic is detected raise Error-in-Logic;

...

except ion when Error-in-Logic => begin Logging-Procedure; except ion when others => Null; end ; raise ; end Not-Blocking ;

5.7.2.6 Default Handlers A handler of the form “when o t h e r s => raise”is semantically equivalent to not having an exception handler. Handlers of the form “when Some-Exception => raise” are default handlers only if there is not an “ o t h e r s ” handler or if the “ o t h e r s ” handler is a default handler. The examples below illustrate default handlers which can be used to show that a frame expects to encounter exceptions, but there is no explicit processing at that level. Benchmarking the object code of one compiler revealed that the additional code needed to implement the default handler resulted in unacceptable code expansion. This problem could be avoided if all optimizers checked for this pattern: with Text-10; procedure Example-1 is begin <sequence of statements> exception -- this is a default handler and could be removed when Text-1O.Mode-Error => raise; end Example-2;

228

WILLIAM G.BAIL

with Text-10; procedure Example-2 is begin <sequence of statements> exception -- this is a default handler and could be removed when others => raise; end Example-2;

In the next example the handler for “Text-1O.Mode-Error” is not a default handler because the “ o t h e r s ” handler maps any exceptions that it catches to “Something-is-Really_Really_Wrong” with Text-10; procedure Example-3 is begin <sequence of statements> exception -- this is NOT a default handler and it would change -- the functionality to remove it when Text-IO.Mode-Error => raise; when others => raise Something-is-Really-Really-Wrong; end Example-3;

5.1.3 Propagation Finally, there are several patterns to avoid that involve the propagation of exceptions. These patterns include: 0 0

0

Anonymous exceptions Object declaration initialization Propagation of exceptions by package bodies

5.1.3.1 Anonymous Exceptions Exceptions are statically declared in a declarative region, and their scope (visibility) is the same as that region. However, an exception may dynamically propagate arbitrarily up a call sequence, including out of the exception’s scope. If such a propagation occurs, then the exception is called anonymous, and can only be handled by the handler construct when o t h e r s =>. Consider the following example: procedure Do-It is Local-Bogus : exception ; begin <sequence of statements>

EXCEPTION-HANDLINGDESIGN PA‘TTERNS

229

raise Local-Bogus; exception when Local-Bogus => raise; end Do-It;

Ada 95 [20] has included new exception handling features to provide more visibility into exceptions that propagate outside of their scope. While the exception name may not be visible, additional information can be obtained through the use of three functions provided as a part of package Ada.Exceptions. Specifically: 0 0 0

Function Exception-Identity returns the identity of the exception, Function Exception-Name returns the name of the exception, Exception-Information returns information about the exception occurrence.

5.1.3.2 Implicit Anonymous Exceptions Exceptions declared in a package specification are part of the abstraction and should be handled while the exceptions are still in scope. This problem was particularly noted in the reuse of common code. It is important that exceptions that are part of an abstraction be handled in the scope that is most appropriate. In this example, “Application-Function. Do-It” should have handlers that for exceptions that could propagation from “Int-Stack. P u s h :” package Application-Function is procedure Do-It (X : Integer);

...

end Application-Function; with Stack; package body Application-Function is package Int-Stack is new Stack(1nteger); procedure Do-It (X : Integer) is begin

... ...

Int-Stack.Push(X); end;

-- Exceptions from Int-Stack can be -- handled by name in this frame

end Application-Function;

5.2.

Feature-interaction Based

The set of feature-interaction based ineffective design patterns is summarized in Table IV. With these patterns, the exception-handlingfeatures interact with other language mechanisms to corrupt the exception-handlingprocessing.

230

WILLIAM G.BAIL

TABLEIV INEFFECTIVE FEATURE-INTERACTION BASEDDESIGNPATTERNS Design pattern

Category ~~

Generics Derived types Tasking

Optimizations System-level features

~

Exception declarations Elaboration failure Multi-path propagation Infinite task server Dependent tasks Return codes Suppression of range checks

Recursion

5.2. I

Generics

5.2.1.7 Exception Declarations When exceptions are declared in the specification of a generic package, each instantiation creates a unique set of exceptions unless the exception declarations are a renamed as described in a previous example. Defining a package that declares the exceptions and then renaming these exceptions in the generic package achieves a generalized result. Deciding on common names across instantiations or unique ones per instantiation is application-dependent. The issue involves granularity of the name space: with Stack-Exceptions; generic type Item is private; package Stack is type Stack is limited private; Overflow : exception renames Stack-Exceptions.Overflow; Underflow : exception renames Stack-Exceptions.Underflow; procedure Copy (From-the-Stack : in Stack; To-the-Stack : in out Stack); procedure Clear ( The-Stack: in out Stack); ( The-Stack: in out Stack); procedure Pop

... ...

private end Stack;

231

EXCEPTION-HANDLINGDESIGN PATTERNS

5.2.1.2 Elaboration Failure Although the elaboration of any program unit can fail, the nature of dynamic generic instantiations results in more elaboration failures than nongeneric units. A common defect in the design of generic packages (which can also occur in nongeneric packages) is to propagate exceptions declared in the package specification as an indicator that elaboration of the package body has failed. Such propagations will be anonymous (see the discussion on anonymous exceptions): generic t y p e Mystery i s p r i v a t e ; package Risky-Generic i s Elaboration-Failed : e x c e p t i o n ; <sequence of declarations> end Risky-Generic; package body Risky-Generic i s <sequence of declarations> begin <sequence of statements> i f Some-Condition then raise Elaboration-Failed; end i f ; end Risky-Generic;

A defect in this design is that the exceptions will not be propagated to the handlers for the frame that declared the exceptions, but to the dynamic parent of the frame; a frame can never handle the elaboration failure of any program unit it declares with Risky-Generic; procedure Example-Failure i s package Risky-Instantiation

i s new Risk-Generic (INTEGER

);

begin <sequence of statements> except i o n when Risky-1nstantiation.Elaboration-Failed => -- Although we have a test for Elaboration-Failure, if -- the exception is only raised to indicate elaboration -- failure, it will never be propagated to this handler, -- but to the caller of Example-Failure end Examplepailure;

...

5.2.2 Derived Types The derivation of a type results in the implicit declaration of any subprograms defined for the original type. However, the exceptions propagated by

232

WILLIAM G. BAIL

the implicitly declared subprograms are the same exceptions propagated by the explicitly declared subprograms. One solution, that requires extensive manual effort, is to rename exceptions in the same scope that the derivation occurs: Exception-A renames Packl.Exception-A; package Packl is type Type-A is (Valuel, Value2, Value3); Exception-A : exception; -- Phunc may propagate Exception-A; function Phunc (Arg : Type-A) return Type-A; end Packl;

Perhaps in a distant file far far away ... with Packl; package Pack2 s type Type-B is new Packl.Type-A -- There is now a derived function Pack2.Phunc of the form -- function Phunc (Arg : Type-B) return Type-B; -- but it w 11 raise Packl.Exception-A end Pack2;

5.2.3 Tasking 5.2.3.I Multi-path Propagation Exceptions propagated from accept statements propagate to both the enclosing frame in the task and the entry caller. To ensure that appropriate recovery action is performed, it is crucial that responsibility for action be allocated appropriately, whether it be the task body, the task caller, or a combination of both. task DOA is entry Rendez; end; task body DOA is begin accept Rendez do begin --Block Statement-<sequence of statements> exception when others => raise; end; --Block Statement-end; -- of rendezvous code <sequence of statements> except ion when others => raise; end DOA;

EXCEPTION-HANDLING DESIGN PATTERNS

233

5.3.3.2 Infinite Task Server If an exception propagates to the outer scope of a task body during execution, the task terminates. If the terminating task was not in rendezvous when the exception propagated, there is no notification of the task termination (not even to the parent scope of the task declaration). The next time an attempt is made to rendezvous with the now terminated task, the entry call raises “Tasking-Error” in the caller. In this case, no additional information regarding the cause of termination is available to the caller. task DOA is entry Rendez; end; task body DOA is begin loop begin accept Rendez; <Sequence of Statements> exception when Low-Priority-Exception => -- Perform Recover Actions end;-- Block Statement end loop; except ion when High-Priority-Exception => -- Perform Recover Actions and Send Notice that Task is Dying raise; -- The exception will not propagate out of the task body end DOA;

5.3.3.3 Dependent Tasks A frame cannot be exited until any dependent tasks are terminated. This restriction implies that exception propagation can be delayed arbitrarily. In the previous example, “Really-Important-Exception” is handled by aborting the dependent tasks so that it can immediately propagate. The propagation of all other exceptions is delayed until the task “ D o i t ” terminates through its own control flow: procedure Doit is task Hold-On is ; task body Hold-On is begin <Sequence of Statements> except ion when Really-Important-Exception =>

...

...;

234

WILLIAM G.BAIL

---

Abort task Hold-On so that the Really-Important-Exception can propagate abort Hold-On; raise; when others => raise; -- Exceptions will NOT propagate to callers of -- Doit until the task Hold-On terminates end Doit:

5.2.4 Optimizations

6 11.6 of the Ada 83 LRM permits optimizers to reorder expression evaluation but not assignment. If the evaluation of “A/,” occurs before any of the assignments to the variable State, the variable State will be undefined when the exception handler is executed. It is therefore necessary to exercise caution when using the optimization features of compilers, since such optimization may adversely affect the behavior of the exception handling. Consider the example below. Two compilers may have dramatically different behavior if one of them performs optimization. One compiler may result in the variable State equaling 2, while an optimizing compiler may result in State’s value being unknown. with Text-10; procedure Surprise is A : integer := I ; B : integer := 2; C : integer := 0; X : integer ; State : integer ; begin State := 1; X := A/B; State := 2 ; -- will raise a predefined exception X := A/C; State := 3 ; -- Reference x so it cannot be optimized away Text-IO.Put-Line (“X = & integer ‘Image ( X ) ) ; ‘I

5.2.5 System-level Features 5.2.5.7 Return Codes The code fragments in the next example present what appears to be a reasonable approach for integrating assembly return codes with Ada exceptions. However, the implementation of

EXCEPTION-HANDLING DESIGN PATTERNS

235

Raise-on-Class is crucial. In this implementation, any unexpected return codes will be ignored by the procedure, allowing the system to proceed in a possibly unsafe state. procedure Raise-On-Class (Class : integer) is begin case Class is when 1 => raise Status-Error; when 2 => raise Mode-Error; when 3 => raise Name-Error; when 4 => raise UseError; when 5 => raise Device-Error; when 6 => raise End-Error; when 7 => raise Data-Error; when 8 => raise Layout-Error; when -1 => raise System-Error; when others => null; end case; end Raise-On-Class;

The redesigned procedure ensures that an exception is raised for any non-normal status code: procedure Raise-On-Class (Class : integer) is begin case Class is when 0 => n u l l when 1 => raise Status-Error; when 2 => raise Mode-Error; when 3 => raise Name-Error; when 4 => raise Use-Error; when 5 => raise Device-Error; when 6 => raise End-Error; when 7 => raise Data-Error; when 8 => raise Layout-Error; when -1 => raise System-Error; when others => raise Unknown-Error; end case ; end Raise-On-Class;

5.2.5.2 Suppression of Range Checks Some optimizations performed during compilation involve removing redundant constraint checks. The effect of this removal is equivalent to inserting an implicit pragma suppress. Sequences of assignments within the same subtype can have con-

236

WILLIAM G. BAIL

straint checks removed as long as no assignment is made that may be out of the subtype range. Use of ’address can allow modification to a variable without the compiler’s ensuring that the constraint check is still redundant: with Text-10; use Text-10; with System; procedure Constraint-EG is subtype Week is integer range 1..7; A, B, C : Week := 1; Ra : array (Week) of integer ; package Int-I0 is new Integer-I0 (INTEGER); use Int-10;

Implementation may be either a pragma interface or an Ada body. procedure Add-2 ( Input : Week; Victim : System.Address); begin Add-2 ( 3 , A’Address); Add-2 ( 6 , A‘Address); B := A; Ra (8) := 666; Put ( “Ra (B): ) ; Put (Ra(B) ) ; New-Line; end Constraint-EG; I’

In the following example, a C routine increments a variable by 2, but the parameter is of mode “in” (uses ’address), so the potential change in value is not considered by the optimizer. The example routine in Ada achieves the same effect by using “Unchecked-Conversion” to convert the Systen2.Addre.w to an access value for an integer with Unchecked-Conversion; procedure Add-2 (Input : Week; Victim: System.Address) is type Ptr is access Week; function Convert is new Unchecked-Conversion (System.Address, Ptr); Victim-Ptr : Ptr := Convert(Victim); begin Victim-Ptr.all := Input + 2 ; end Add-2;

5.2.6 Recursion It is possible for exception handlers to be written that perform indirect recursive calls. Such behavior needs to be avoided to avoid erroneous behavior. This pattern has actually been seen in one large C31 application. In

EXCEPTION-HANDLINGDESIGN PATTERNS

237

the following example, a raised exception results in recovery procedures Cleanup and Shutdown being called. In Cleanup, if any exception is raised, procedure Shutdown is called. However, in Shutdown, if any exception occurs, Cleanup is called. begin <sequence of s t a t e m e n t s > exception when others => Cleanup; Shutdown; raise; end ;

procedure C l e a n u p is begin <sequence of statements> exception when others => Shutdown; raise; end C l e a n u p ;

procedure Shutdown is begin <sequence of statements> exception wben others => Cleanup; raise; end Shutdown;

REFERENCES (11 Sinha, S., and Harrold, M. J. (1998). Analysis of Programs with Exception-Handling Constructs. ICSM. [2] Berlin, L. (1990). When objects collide: Experiences with reusing multiple class hierarchies. Proceedings of OOPSLA ’90,pp. 181-193. [3] Booch, G. (1987). Software Engineering in Ada, 2nd edn, Benjamin/Cummings Publishing Co., Inc., Menlo Park, Ca. [4] Bundy, G., Howell, C., Mularz, D., and Winner, B. (1993). Exception Handling, or “When Bad Things Happen to Good Programs”. Tutorial materials, the MITRE Corporation, McLean VA. [5] Bundy, G. N., and Mularz, D. E. (1993). Error-Prone Exception Handling in Large Ada Systems, MTR 92W0000227, The MITRE Corporation, McLean, VA. [6] Bundy, G. N., and Mularz, D. E. (1993). Error-prone exception handling in large Ada systems. Proceedings of Ada-Europe, Paris, France. [7] Cui, Q. (1989). Data-Oriented Exception Handling. PhD Thesis, University of Maryland. [8] Goodenough, J. (1975). Exception handling: Issues and a proposed notation, Communications of the ACM, December, 683-696. [9] Goodenough, J. B. (1991). Using exceptions: Some design issues. Net note, March. [lo] Howell, C., and Mularz, D. E. (1991). Exception handling in large Ada systems. Proceedings of the Washington Ada Symposium (WAdaS’91),McLean, VA, pp. 90-101. [11] Kruchten, P. (1990). Error handling in large, object-based Ada systems. Ada Letters, September/October, 10(7), 9 1- 103. [12] Levin, R. (1977). Programming Structures for Exceptional Condition Handling. PhD Thesis, Carnegie-Mellon University. [13] Liskov, B., and Snyder, A. (1979). Exception handling in CLU. IEEE Transactions on Software Engineering, November, 546-558. [14] Meyer, B. (1988). Object-oriented Software Construction, Prentice Hall, New Jersey, pp. 144-155. 1151 Pfleeger, S . L. (1998). Software Engineering Theory and Practice. Prentice Hall, New Jersey, pp. 222-228. [16] Rook, P. (1990). Software Reliability Handbook. Elsevier Applied Science, London and New York. [16a] Moulding, M. (1990). Software fault tolerance. In Software Reliability Handbook (Paul Rook ed.), Elsevier Applied Science, London and New York, pp. 83-110.

238

WILLIAM G.BAIL

[17] Schaefer, C., and Bundy, G. N. (1993). Static Analysis of Exception Handling in Ada, submitted to Software Practice and Experience. March. [18] Stroustrup, B. (1991). The C++ Programming Language, 2nd edn. Addison-Wesley, Reading, MA, pp. 293-324. [I91 Comell, G., and Horstmann, C. S. (1997). Core Java, 2nd edn, SunSoft Press, pp. 423-454. [20] I S 0 (1995). 1SOIlEC 8652 :1995 Information Technology-Programming Language -Ada. International Standards Organisation,Geneva.

Managing Control Asynchrony on SIMD Machines-a Survey NAEL 6. ABU-GHAZALEH Computer Science Department State University of New York at Binghamton Binghamton, NY 13902-6000, USA [email protected]. edu

PHILIP A. WILSEY Computer Architecture Design Laboratory Department of ECECS PO Box 2 10030 University of Cincinnati Cincinnati, OH 45221-0030 USA

Abstract The Single Instruction Multiple Data (SIMD) paradigm has several desirable characteristics from the perspective of massively-parallel algorithms. However, its restricted control organization makes it only useful for a small set of applications that fit this restricted model. The alternative for other applications has been to use Multiple Instruction Multiple Data (MIMD) organizations, which are much more expensive and difficult to use. In addition, MIMD machines are inefficient on fine-grained applications, which require frequent interaction among the processing elements (PEs). This paper surveys research efforts that seek to reduce the inefficiencies associated with managing control-parallelism on SIMD machines.' These efforts are organized into three major categories: (1) advances made within the SIMD model; in particular, autonomous features allowing the PEs to locally modify the operation of some instructions, (2) architectures that have attempted to retain the advantages of the SIMD model, while enriching its control organization to allow better support of control-parallelism, and (3) the concurrent-interpretation model: a centralized-control model that shares the control unit at the instruction level (instead of the thread level, as per the SIMD model), allowing efficient support of control-parallelism on a centralized-control organization.

' This work is partially supported by a grant from the UC Research Challenge program. ADVANCES IN COMPUTERS, VOL. 49 ISBN 0-12-012149-2

239

Copyright 01999 by Academic Press All rights of reproduction in any form reserved.

240

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

2. Background . . . . . . . 2.1 Parallel Algorith 2.2 Parallel Architec 2.3 MIMD Organiza

............

243

................

241 251

.........

..........

1. Introduction

Parallel processing has established itself as the key enabling technology for the future of high performance computing. A parallel machine can be abstracted as a collection of processing elements (PEs) connected through some form of communication network. Parallel machines have been built along two major architectural formats: Multiple-Instruction streams MultipleData streams (MIMD) machines and Single-Instruction stream Multiple-Data streams (SIMD) machines (Flynn, 1966). The chief difference between the two formats is the control organization. The control on MIMD machines is local to each PE. Thus, the PEs on MIMD machines are stand-alone serial processors, with a control unit, local memory, and data path. On the other hand, SIMD machines have a central control unit that broadcasts a single stream of instructions to the PEs for concurrent execution. With most of the hardware targeted towards data manipulation, SIMD machines are smaller and less expensive to build than MIMD machines (Bridges et al., 1992). MIMD and SIMD machines are suited for distinct modes of operation and, consequently, for distinctly different types of applications. Because MIMD machines maintain a one-to-one relationship between control units and data paths, they have a control organization that efficiently supports general control-parallelism (i.e. a distinct control sequence may be applied to each data path). However, because the control is distributed, explicit and

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY 241

often expensive synchronization mechanisms have to be employed in order to coordinate access to shared data and guarantee correct execution (Hwang and Briggs, 1984). Fine-grained applications spend much of their time synchronizing their activities, rather than doing useful computation. SIMD machines operate in lock-step, with fine-grained synchronization implicit at the instruction boundary. There is no hardware or software overhead for synchronization; it is enforced by the execution model. Unfortunately, because SIMD machines possess a single control unit, they can only sequence a single thread of execution. If the PEs require different control patterns, each distinct pattern must be broadcast from the control unit separately-time-sharing the use of the control unit and resulting in poor utilization of the PEs. This phenomenon, called the SZMD overhead, occurs whenever control parallelism exists in the application. The SIMD overhead restricts the utility of SIMD machines to applications that fit SIMD’s restrictive control organization. With the arrival of mainstream massively-parallel processing, it has become increasingly apparent that most of the available parallelism is datalevel parallelism. More precisely, most exploitable massive-scale parallelism occurs due to the availability of numerous data points that can be processed concurrently, rather than numerous functions that execute concurrently to solve a problem. In addition, in applications where functional parallelism exists at a massive scale, it is virtually impossible to write, coordinate, and debug thousands of concurrent interacting functions. Since SIMD machines have been built specifically to take advantage of data-level parallelism, the move to massive parallelism strengthens their appeal. Unfortunately, SIMD machines are only capable of operating efficiently on applications that are strongly synchronous (because of the SIMD overhead). In an extensive survey of massively parallel applications Fox found that more than 50% of the applications studied were loosely synchronous or asynchronous (Fox, 1989). Moreover, since many applications have phases of execution that are alternately synchronous and asynchronous, there is considerable interest in having a platform that supports both types of parallelism efficiently (Cantoni and Levialdi, 1983; Chandy et al., 1995; Dhagat et at., 1995; Fox, 1989). In the remainder of this paper, the term general massively parallel application is used to denote an application containing both data and control parallelism. Ultimately, the role of a computer architect is to match the architecture to the needs of the application domain within specified cost and physical constraints. Neither SIMD nor MIMD machines match the needs of general massively parallel algorithms well. SIMD machines are an ideal choice for synchronous applications with no control parallelism; MIMD machines are best suited to control parallel applications where little synchronization is

242

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

necessary. A few years ago, it was suggested that in the quest for very high performance, two alternative paths exist (Hennesy and Patterson, 1996). Either the MIMD machine cost and size will drop sufficiently to allow these machines to scale to massive configurations, or the SIMD organization will advance sufficiently to overcome SIMD's restricted control organization and the architectural factors causing the low per PE performance. These paths are illustrated in Fig. 1. Unfortunately, for several reasons, the research community has only seriously pursued the path originating from the MIMD model, introducing fine-grained synchronization and communication support to MIMD configurations and awaiting the VLSI technology improvement to allow higher levels of integration (Kranz et al., 1994; Kuskin et al., 1994). The alternative approach of enriching the control organization of SIMD machines was largely ignored, to the degree that several opinions were recently voiced to the effect that the SIMD model is "dead" from the perspective of general massively parallel processing (Parhami, 1995; Hennesy and Patterson, 1996). Meanwhile, SIMD-based machines offering groundbreaking peak-performance to cost ratios for a limited application domain continue to appear: Terasys PIM (Gokhale e# al., 1995), MGAP-2 (Zhou et al., 1995), Adaptive CNAPS (Adaptive solutions 1996), Oxford A236 (Oxford Micro Devices, 1996), Chromatic mPACT (Chromatic Research Inc., 1996), ISATEC Systola (ISATEC, 1996). Number of PEs lOOk

f I

"El-dorado"

MasParMP-2

/

l---4L 0

Sequent Symmetry

1

1'

Cray-YMP

1 MFLOP

1 GFLOP

performance per processor

FIG. 1. The parallel processing landscape a few years ago. (Adapted from Patterson, David, and Hennesy, John ( 1996) Computer Architecture: A Quantitative Approach, (2nd edn), Morgan Kaufmann, Fig. 8.46, p. 748.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

243

TABLEI ORGANIZATIONAL TAXONOMY CATEGORIES Category ~~

Example ~~

~

PE autonomy

SIMD evolution

Concurrent subsystems Algorithm and programming model innovations Beyond the SIMD model

Multiple SIMD machines Strongly synchronized machines Barrier machines Virtual data parallel machine

Concurrent interpretation and operation level sharing of control

Large-grain interpretation General instruction level interpretation The shared control model

This paper surveys the research efforts that have taken the second approach of enriching the SIMD control organization. We organize these efforts into three major categories (Table I). The first category (section 3) includes the optimizations to the SIMD model (and the data-parallel programming model) that have been made within the SIMD paradigm. While early machines applied the single instruction identically across all the PEs, recent SIMD machines allow the PEs to have some freedom in the application of the instruction. In addition, extensions to the data-parallel programming model and innovative programming techniques for better management of control parallelism are overviewed in this category. The second category (section 4) includes architectures that have enriched the SIMD control organization for better management of control parallelism. Two major approaches are identified: Multiple-SIMD architectures, and architectures based on more liberal synchronization models. Finally, the third category (section 5 ) considers the concurrent interpretation approach. Original studies of this paradigm viewed it as a different model for programming SIMD machines that is more suitable for expressing control parallelism. However, it may be viewed as a different model for sharing a centralized control subsystem. Before embarking on these discussions, we present some background material (section 2) about parallel programming models, and discuss in more detail the advantages and limitations of the MIMD and SIMD organizations.

2.

Background

In this section, an overview of some of the concepts central to parallel algorithms and architectures is presented. There is a strong relationship

244

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

between an architecture and the algorithms suitable for it. Efficient parallel processing requires a good understanding of this relationship (Duff, 1983; Hayes, 1988; Snyder et al., 1985; Uhr, 1982). This discussion focuses on the control organization aspects; there are many more general discussions available in the literature (Cypher and Sanz, 1994; Fountain, 1987; Hord, 1990, 1993; Jamieson et af., 1987).

2.1

Parallel Algorithms

Parallel processing is the cooperation of several processing elements for solving a problem concurrently. The move from serial processing to parallel processing introduces many problems that have no direct counterpart in the serial processing domain. Thus, parallel algorithms and programming models continue to be a subject attracting considerable research (Fox, 1989; Fox and Angus, 1990; Jamieson et al., 1987). Because of the close coupling between algorithm needs and architectural features, parallel algorithms and programming models have a direct impact on any study of parallel architectures. An application consists of a collection of tasks, sequenced according to a task-graph. Informally, the problem of mapping an application to a parallel machine can be broken into three parts: (1) isolating the candidate tasks for parallel execution, (2) mapping the tasks to the PEs in a way that minimizes execution time, and (3) mapping the data space to the local PE memories in a way that minimizes communication and synchronization overhead. Infrequently, a clear, intuitive, mapping from application to algorithm presents itself. However, there are generally many candidate implementations for a given application, and the problem of finding an efficient implementation is difficult (Cvetanovic, 1987; Nation et al., 1993). A parallel algorithm embodies the traditional notion of an algorithm (a solution strategy for the problem), in addition to the mapping steps discussed above. There are several characterizing properties of parallel algorithms that can be used to guide architecture design. Some of the key properties that directly influence the architecture design are: (1) The type of parallelism utilized by the algorithm. There are two chief forms of parallelism: data parallelism and fuizctional, or control parallelism. Data parallelism is utilized by decomposing the data domain into small segments that are assigned to the PEs for concurrent processing. On the other hand, functional parallelism results from the existence of unique functions that can be carried out concurrently (and, to a lesser degree, from variability of the execution paths followed by the same function when applied on different data).

MANAGING CONTROL ASYNCHRONY ON SlMD MACHINES-A

SURVEY

245

Functional parallelism and data parallelism do not represent mutually exclusive concepts. The majority of massively-parallel algorithms utilize data parallelism with limited functional parallelism (Fox, 1989). (2) The granularity of tasks. The granularity of a task is a measure of the frequency of communication relative to the computation time of the average task in the algorithm. Granularity also characterizes the synchronization behavior: Fine-grained applications synchronize often and, therefore, have low granularity. Accordingly, the ability to carry out fast communication is an important property required by applications with fine-grained parallelism, including massively-parallel applications. (3) The degree of parallelism. This property determines the number of processing elements that can be used effectively to speed up a given code segment. Algorithms utilizing functional parallelism generally have a small degree of parallelism, while those utilizing data parallelism have a degree of parallelism that varies with the data set size. (4) Data mapping and access patterns. The data set for the application has to be shared among the processing elements. Memory accesses to local memory are faster than accesses to a shared memory or a remote location. The data mapping and access patterns define the needs for the memory organization and the communication properties of the host architecture. There are other important characteristics of parallel algorithms that are less related to the topic of this paper. Interested readers are referred to studies that specifically address algorithm characterization (Fox and Angus, 1990; Jamieson et al., 1987).

2.2 Parallel Architectures and Control Organization The von Neumann model of computation is used in most serial computers (Fig. 2). Its main elements are a control unit, a data path (ALU and registers), and some memory.2 The control unit fetches an instruction from memory, decodes it, fetches the operands (from the register set or memory), then sends the necessary signals to the data path to cause the execution of the instruction. The control unit may be hard-coded, for fast control, or microprogrammed, for flexibility and ease of design (Hayes, 1988; Hennesy

* In contemporary microprocessors, “memory” refers to a complex hierarchy (of caches, main memory, and secondary storage) that is used to optimize access to instructions and data. Typically, a subset of the cache resides on-chip (Hennesy and Patterson, 1996).

246

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

FIG.2 . Von Neumann-based serial processor.

and Patterson, 1996). The stream of executed instructions and the control hardware necessary to sequence it are called the instruction stream, while the succession of operands for these instructions and the data path necessary to manipulate them is termed the data stream. An instruction cycle is the time required for all the stages of fetching and executing an instruction to conclude. Most recent microprocessors have hard-coded control and utilize instruction-level parallelism to minimize instruction cycle times (Hennesy and Patterson, 1996). Flynn (1966) classifies parallel architectures according to the multiplicity of the control and data streams. The basic, von Neumann, serial processor is classified as a Single-Instruction stream Single-Data stream (SISD) processor. Parallel configurations are obtained by increasing the multiplicity of the instruction streams (MISD), data streams (SIMD), or both (MIMD). The relationship between the instruction streams and the data streams is called the control organization. Parallel operation requires multiple data streams. Thus, parallel machines can either be SIMD or MIMD according to this classification. SIMD machines, for example the Connection Machine CM-2 (Hillis, 1985), consist of a single control unit that guides the operation of all processing elements as they execute a single program; SIMD machines are best suited to regular applications with large vectors or arrays. In fact, vector processors (Simmons et al., 1992) are a special case of the SIMD model with pipelined, rather than truly parallel, processing of the vector data. In contrast, MIMD machines have a control unit associated with each processing element and are better equipped for supporting more general parallelism. A small number of MISD machines have been built (Kent et al., 1985). However, these machines are more properly described as pipelined operation serial machines, rather than parallel machines.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

247

An example of MIMD machines is the Cray T3D (Cray Research Inc., 1993). While these machines have been traditionally restricted to the realm of super-computing, advances in technology have made it feasible to introduce elements of parallel processing to the mass market. Several PC vendors offer machines with more than one processor (MIMD). Moreover, clusters of machines connected using a LAN or a special communication network are being increasingly used as cheap parallel machines (Pfister, 1998). Several multimedia accelerators use SIMD-like architectures to process image or voice data concurrently. As technology continues to get better and cheaper, we expect that parallel processing will be a mass market technology. Since Flynn’s taxonomy uses the von Neumann model as the base class, and obtains others from replication of streams within this model, it fails to identify fundamentally different architectures. For example, data-flow architectures and neural networks do not fall into any of the four categories. In fact, not even all the configurations based on the von Neumann model (with instruction streams and data streams) are clearly classified. In particular, instruction-level parallelism used on superscalar machines (Johnson, 1991), VLIW computers (Ellis, 198.5), and other forms of multiple functional unit machines (Wolfe and Shen, 1990) cannot be clearly categorized. Nevertheless, SIMD and MIMD organizations are important points in the continuum of parallel computer architectures. MIMD organizations represent a one-to-one relation between control streams and data streams, while SIMD machines represent a one-to-many relation, with all the data paths on the PEs sharing a single control unit. In the remainder of this section we overview the MIMD and SIMD organizations in detail.

2.3 MIMD Organization MIMD machines are “general” parallel machines where each data path has an associated instruction stream. Since every node has the components necessary for independent processing of a thread (the instruction stream associated with a task), MIMD machines are capable of supporting any degree of asynchrony in the control flow of the algorithm. In fact, MIMD machines operate best when the application is completely asynchronous, and the communication and the coordination among PEs are kept to a minimum. Because control resides locally, the PE cycle time is small. As long as the PEs do not interact with the other PEs, they can process their computation locally and efficiently. Thus, MIMD machines are best suited for large-grained applications. One of the defining features of MIMD machines is the memory organization. There are two primary models for the memory organization: shared

248

NAEL 6.ABU-GHAZALEH AND PHILIP A. WILSEY

memory (Fig. 3 ) and distributed memory (Fig. 4). In the shared memory organization the PEs have a common address space and can access any portion of the data. In order to preserve the causality of operation, memory access is serialized whenever a conflict occurs. In order to minimize conflicts, PE caches with a cache coherency protocol are employed (Goodman, 1983). As the number of processors increase, the complexity of the broadcast bus increases, as well as the contention for using it. In contrast, the PEs on a distributed memory machine have independent memory spaces. Data sharing is accomplished via explicit messages requesting or supplying the data. Message passing protocols are inefficient because the messages must suffer an expensive message packing/unpacking procedure (as well as authentication by the kernel, in a multiprogrammed environment) (Gropp et al., 1994; Eicken et ul., 1992). With massively-parallel machines requiring fine-grained access to data, the frequency and high cost of messages severely restrict the performance of the message passing model. The poor scalability characteristics of the shared memory model make it inappropriate for massively-parallel configurations. Massively parallel MIMD machines have almost exclusively had a distributed memory organization. However, because of the desirable algorithmic properties of the shared memory model a new memory organization has been suggested recently. The distributed shared memory organization implements a shared memory interface into what is a physically distributed memory organization (Hill et al., 1993). A scalable cache coherency protocol (using page directories where the list of processors with a copy of each shared memory page is maintained (Agarwal et al., 1988)) is used to implement cache coherency. In order for the shared memory model to be efficient, fine-grained, lowoverhead access to non-local processors must be supported: an inefficient operation on distributed memory machines. Varying levels of hardware support are used to optimize this operation. Moreover, since the messages are initiated by the trusted shared-memory interface, most of the overhead

FIG.3. A Shared memory MIMD machine.

MANAGING CONTROL ASYNCHRONY ON SlMD MACHINES-A

SURVEY

249

FIG. 4. A Distributed memory MIMD machine.

associated with the distributed memory model is eliminated. However, it is essential for the programmer to realize that the cost of memory access is not uniform, and to access non-local memory judiciously (Hill et al., 1993; Larus, 1993). Since the memory organization is physically a distributed memory, it is possible to provide support for explicit message passing as well (Agarwal et al., 1995; Kuskin et al., 1994). The advantages of MIMD machines can be summarized as follows: (1) MIMD machines can support general control flow in algorithms. Since most applications have at least some control parallelism, this is an important property. (2) The control resides on-chip, making the instruction cycle time small. (3) The PEs can be built using off-the-shelf serial processors. The high cost of custom chip design and implementation is avoided. Moreover, because of the economy of scale, the design of these off-the-shelf serial processors usually attracts enormous efforts that cannot be justified in the context of a parallel machine! Unfortunately, serial processors are not optimized to manage communication and synchronization, and therefore have a disadvantage over custom-built nodes. Conversely, some of the disadvantages of the MIMD organization are:

(1) The coordination required among the PEs to preserve the precedence relations in the application task graphs and to maintain the consistency of shared data. This process requires communication among the PEs to implement synchronization primitives such as barriers and locks (Axelrod, 1986; Mellor-Crummey and Scott, 1991). The computation is suspended whenever such coordination is required Whereas microprocessors commonly sell millions of units, massively-parallel machines have a much smaller market.

250

NAEL 6. ABU-GHAZALEH AND PHILIP A. WILSEY

(both to carry out the synchronization primitives and to wait for the coordination conditions to be met). For fine-grained applications, synchronization occurs frequently and MIMD machines are inefficient. Often, additional hardware, such as communication co-processors or dedicated coordination buses (snoopy buses), is required to optimize these operations (Goodman, 1983; Kuskin et al., 1994). (2) The high cost and low utilization of silicon area. MIMD machines have a control unit for every PE, as well as arbitration and conflictresolution hardware. The area required for these components can account for over half of the total PE area (Bridges et al., 1992). Considering the useful part of the PE to be the data path, MIMD machines obtain poor utilization of the available chip area. (3) MIMD machines are large-a consequence the two previous disadvantages: massively parallel MIMD configurations are hard to build and very expensive (Thinking Machine Corporation, 1991). Because of the large size, the communication network has to span long distances, resulting in considerable electrical delays. The power and cooling requirements are also extensive. (4) Difficult programming, debugging, and optimization. The difficulty arises from the asynchronous nature of operation. As any user of MIMD machines will attest, when not carefully synchronized, executions of the same program can produce different outputs. Intermittent incorrect behavior is possible, reducing the confidence in the correctness of the program and making debugging difficult. Some of the problems with debugging MIMD programs include visualization of concurrent threads, the ability to perform standard debugging operations, such as single-stepping and setting breakpoints, in a meaningful and safe fashion, and preserving real-time behavior (such as asynchronous conflicts and congestion) (GarciaMolina et al., 1984; Joyce et al., 1987).

Control Broadcast Bus

0 Control

m PE Memories FIG. 5 . A

SIMD organization.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

2.4

SURVEY

251

SIMD Organization

The SIMD model consists of a single “master” processor, called the control unit, and an array of “slave” processing elements. Figure 5 shows the organization of a SIMD machine. The control unit fetches and decodes a single instruction stream from its local memory. It executes scalar instructions locally and broadcasts parallel instructions to the PEs for concurrent execution.’ Figure 6 shows a block diagram of a SIMD PE. For the PE to be able to carry on a von Neumann computation, all the components necessary to fetch, decode, and execute an instruction must be present. The first two steps are carried out by the control unit and the decoded signals are broadcast to the PEs for execution. This figure is similar to the data path portion of a serial processor. The corresponding control portion resides on the control unit and is shared by all the PEs. The PEs are usually connected with a simple, regular communication network (mesh networks are a popular choice), and communicate synchronously in a single direction (MasPar, 1991b). The SIMD control organization, with a single control unit controlling all the PEs, is restrictive. All PEs must execute the same instruction at the same time; processing their data identically. Surprisingly, this form of parallelism occurs in many scientific computations, where a single algorithm has to be

FIG.6. A typical SIMD processing element. As a historical aside, SIMD machines were first suggested by Unger (Unger, 1958). The first machines to be designed were the SOLOMON (Slotnick ef al., 1962) at Westinghouse and the Illiac at the University of Illinois, which also was the first SIMD machine to be built (Barnes ef al., 1968).

252

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

applied to numerous data points in a uniform pattern. This programming model is called the data parallel model (Hillis and Steele, JR, 1986). SIMD machines are the ideal platform for this form of parallelism, both in terms of cost and performance. The restricted control organization makes SIMD machines ineffective for supporting any form of functional parallelism. When subsets of the PEs require different processing, the control unit must broadcast the required instructions sequentially. Thus, the different control branches contend for the use of the control unit, time sharing access to it. As the degree of branching in the application increases, the performance drops proportionately. This problem is known as the SIMD overhead. The main advantages of the SIMD organization are: Simple, small, and cheap PEs. With the control unit responsible for fetching and decoding the instructions, the PEs can be nearly as simple as the data path portion of a serial processor. Thus, many PEs can be integrated on the same chip; for example, each PE chip in the MasPar MP-2 holds 32 32-bit PEs (Kim and Tuck, 1993). Inherent synchronous operation. The control unit broadcasts the control signals to the PEs in lock-step. Since only one control thread exists, there is no need for synchronization. Ease of programming and debugging. A major drawback of parallel machines is that they are hard to program (Fox and Angus, 1990; Hatcher and Quinn, 1991; Jamieson et al., 1987). SIMD machines are an exception because the flow of control is sequential. There is only one program to write and debug, and the data distribution is often intuitive. In fact, due to the simplicity of the data parallel model used to program SIMD machines, it has also become a popular programming model for MIMD machines (Brandes, 1993; Hatcher and Quinn, 1991; Nichols et al., 1993). Memory efficiency. On MIMD organizations, the PE memory must hold both the program and data. Only data are kept in the SIMD PE memory. The saving in memory cost and size is significant when considered in massively-parallel configurations (Manning and Meyer, 1993). The major disadvantages of the SIMD model are: (1) The SIMD overhead. With a single control unit, only one control thread may be supported at a time. Any variety in the processing required by the PEs causes a substantial drop in performance. In the context of a SIMD program, such behavior occurs primarily on parallel branching regions and variable-index loops.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

253

(2) Off-chip control. The instruction stream is broadcast from the control unit to all the PEs. On massively-parallel machines, the broadcast bus has to cross not only chip, but also board, boundaries. These delays force the machine to operate at relatively low clock speeds (Allen and Schimmel, 1995a). ( 3 ) The worst-case execution time problem. At the same time that the implicit synchronization is one of the virtues of SIMD machines, it poses the following problem: an instruction is not executed until all the PEs finish the previous instruction. If an instruction execution time is variable, the worst-case cost is assessed to all PEs. This behavior has limited the use of caches for SIMD machines-even if only one PE has a cache-miss, all PEs suffer the cache miss-time. The set of problems with massively-parallel computation requirements is growing. There are many scientific problems with computational models that require massively-parallel computers, including weather prediction, molecular dynamics, and quantum flow dynamics (Almasi and Gottlieb, 1989). For these fields, problems with particle models (as opposed to fluid models) are highly irregular and best suited to MIMD solutions (Rodrique et al., 1980). There are many engineering problems with intensive computational requirements. For example, simulation, verification, and synthesis of VLSI circuits with millions of transistors (Fujimoto, 1990), and simulation of the massively-parallel machines themselves, are computationally intensive problems. The artificial intelligence field is ripe with opportunity for massive parallelism (Kitano and Hendler, 1994). In complex database query processing on massive databases, high degrees of parallelism are available within each query (Almasi and Gottlieb, 1989). Irregular behavior exists in many of the algorithms used in these domains, and users are forced to purchase MIMD machines to accommodate all applications. This section overviewed parallel algorithms and their implications on parallel architectures. It also discussed MIMD and SIMD organizations and their advantages and limitations with respect to massively-parallel algorithms. Now that we have covered the primary concepts in parallel processing, we are ready to begin discussion of the primary topic of this paper-improving the support of control parallelism on SIMD machines.

3. The Evolution of the SIMD Paradigm This section discusses the changes and innovations that have been incorporated into the SIMD paradigm for improved support of control parallelism. These features do not change the machine from being a SIMD; they are

254

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

better described as optimizations to the “pure” SIMD model in the course of its natural evolution. These features are organized into hardware and software features. 3.1

Hardware Features

Invariably, computer architecture paradigms start with an idea that holds the promise of better performance or cost for a specific application domain. As the idea develops into an initial implementation and is tested, more information becomes available and the inefficiencies of the initial design are exposed. Future designs compensate for the shortcomings by providing a better match between algorithm and architecture, and better design of the architecture to bypass bottlenecks. In the process, the new design takes advantage of the always-improving VLSI technology. As the knowledge of the paradigm matures, other optimizations continue to be incorporated, governed by the law of diminishing returns. The development of the SIMD paradigm from Unger’s idea of spatially mapped processors (Unger, 1958), to todays SIMD massively-parallel supercomputers has also followed this pattern. The SIMD model embodies enough power to express a class of parallel computation that recurs in many important scientific applications, yet is simple enough to make programming easy and construction inexpensive. Perhaps more than any other architectural paradigm, the users of SIMD machines have taken an active role in deciding the direction of its evolution. In particular, the computer vision (Cantoni and Levialdi, 1983; Cantoni and Ferretti, 1994; Duff, 1983; Maresca et al., 1988), mathematical modeling (Parkinson and Litt, 1990) and artificial intelligence (Hillis, 1985) communities recognized the utility of the SIMD model for a large number of their applications. They are credited for the design of many innovations, within the SIMD domain, that better support their applications. The most significant additions to the “pure” SIMD architecture are features that add local autonomy to capabilities of the system. Local autonomy relaxes some of the rigidity imposed by the control organization. The discussion of the various hardware optimizations is presented below. 3.1.1 Autonomous Operation The principle of local autonomy allows each PE to modify the operation of the broadcast instruction, usually to specify source or target operands (Fountain, 1988; Maresca ef al., 1988). Thus, while the control unit still broadcasts a single instruction, the operation carried out is partially specified by the PE. Autonomy is different from the asynchronous MIMD operation in

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

255

that the PEs operate synchronously on the same instruction. In order to implement autonomy, part of the decoding control is distributed to the PEs; the (larger) part, including the sequencing control, remains centralized. Autonomous operation has been incorporated into the SIMD paradigm at the following levels.

3.1.1.1 Execution Autonomy Execution autonomy is the ability of the PE to specify whether to participate in the execution of an instruction or not. This ability is essential for the success of the SIMD model. All known SIMD machines have some form of execution autonomy. Execution autonomy allows the PEs to simulate functional parallelism. By activating only a subset of the PEs for a code segment, that subset only takes part in that segment-enabling control parallelism. The mechanism by which a program specifies the activity status is called the masking scheme. The PEs that are masked into the execution of an instruction are called the active set. The activity status may be updated with every instruction, or using special instructions in the program that manipulate the active set (Siegel, 1977a). Masking schemes may allow an arbitrary subset of PEs to be active, or restricted patterns only. For example, the address masking scheme allows active subset to be specified by partially defining bit positions in a mask (Siegel, 1977a, 1977b). The PEs whose address shares the partial mask are active. Thus, variable size active subsets can be defined but not arbitrary subsets. The data masking scheme is a more general scheme where the active status of a PE is determined by a local activity bit. This bit is set as a result of a conditional operation (e.g., using a conditional programming language construct carried out in parallel on local data values).

3.1.1.2 Addressing Autonomy Addressing autonomy, also known as memory indirection, is the ability of the processing element to locally specify the address of memory operations. On SIMD machines without this feature, the control unit broadcasts a fixed address for memory operations. The address for the indirection is commonly specified as the content of a local PE register (Barnes et al., 1968; Fountain, 1985; Hillis, 1985; Nickolls, 1990). Memory indirection extends the range of abilities of SIMD machines in a fundamental way. It allows efficient support of operations such as tablelookup, variable indexing into arrays, and other local data-dependent operations. It also provides support for pointers into local data, enabling the creation of rich data structures and support for high-level programming language constructs. The alternative on machines without this feature is to utilize execution autonomy to activate the appropriate PEs at every possible

256

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

address for the operation. Besides the difficulty in statically tracking the possible addresses, this implementation leads to gross inefficiencies in program size and execution time. Addressing autonomy enables a form of restricted functional parallelism to be implemented on SIMD machines (Maresca et al., 1988). For example, the table-lookup technique can be used to concurrently evaluate different functions on the PEs (the operand values as well as the operator form the index into the “truth-table”) (Chung and Chung, 1989). The cost for implementing memory indirection is small, although indirect memory accesses are slightly slower than uniform accesses because of the extra level of indirection (Allen and Schimmel, 1995a; MasPar, 1991a). Addressing autonomy was first implemented in the Illiac IV (Barnes et ul., 1968) and is considered an essential feature of most modern SIMD machines (Fountain, 1985; Hillis, 1985; MasPar, 1991b). 3.7.7.3 Communication Autonomy The disparity between the speed of communication instructions and other (on-chip) instructions makes communication a bottleneck that dominates the execution time of many parallel systems. This is especially true for SIMD machines because the worstcase communication time for many network architectures is significantly higher than the average case. For reasons of scalability and cost, SIMD machines generally have fixed (low) dimensionality connectivity communication networks. Following the SIMD model, all the PEs communicate in the same pattern (e.g. to their east neighbor) at the same time. This regularity in communication allows communication instructions to be very fast for the supported patterns, but inefficient for other patterns. For example, applications that require hierarchical processing cannot be mapped efficiently to a mesh connected topology (Albanesi et al., 1991). Communication autonomy is the ability of the PEs to communicate to dynamic sets of other PEs efficiently. There are several approaches to realize communication autonomy. Highconnectivity networks eliminate the need for communication autonomy by allowing the PEs to communicate to a large choice of other PEs (possibly all) directly. Low-level networks can be embedded with no overhead (for example, both tree and mesh networks can be embedded inside a hypercube (Ho, 1991)). High-connectivity networks do not scale well because the degree of connectivity increases with the number of PEs. Another approach investigates reconfiguring a fixed-degree network to vary the connectivity pattern (Li and Stout, 1991). For example, the same physical network may be reconfigured to support a pyramid topology and a square mesh-each useful for a distinct class of algorithms (Maresca and Li, 1989). The reconfigurability tradeoff is one that has been chosen in many recent SIMD

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

257

machines (Fountain, 1985; Li and Maresca, 1989; Shu and Nash, 1988; Miller et al., 1988). The hardware overhead for reconfigurability is relatively small, but the time needed to calculate the reconfiguration mapping is often expensive. In addition, some configurations allow arbitrarily long paths of shorted connections, with excessive propagation delay times. Another approach utilizes multi-stage interconnection networks (MINs) (Hwang and Briggs, 1984; Siegel, 1984).General permutation (any PE communicating to any other PE) connectivity requires a crossbar connection. Crossbars are impractical to build and hard to control beyond a small number of nodes (Nowatzyk and Prucnal, 1995). MINs represent a tradeoff between complexity and connectivity of the general crossbar. They are composed of stages of switching elements. Using log&) stages, each made up of log,(n)/2 switching elements, an n-cube MIN can be constructed with the following property: there exists a path between any two given processors. However, only the communication permutations that do not place conflicting requirements on the switching elements, or require the use of the same wires, can be accommodated in a single step. The MasPar MP-1 and MP-2 machines use this approach (in addition to a traditional SIMD 8-way mesh network) (Blank, 1990; MasPar, 1991b; Nickolls, 1990). The performance of the network varies with the permutation required by the PEs, as conflicts are sequentialized. A different approach for realizing general connectivity uses packet switching, instead of the (physical or logical) circuit switching approaches discussed thus far (Hillis, 1985). Messages are submitted by the processors to the network and are forwarded to their destination autonomously. Each message, also called a packet, contains the address of its destination for forwarding purposes. Packet-switched networks provide general connectivity, but require distributed control of the network and buffers to store and forward messages6 Other drawbacks of packet switching include the fixedsize packet, the overhead for the address and sequencing information and the variability of the response time with the network load and the message patterns-aggravating the worst-case time problem.

3.7.7.4 Other forms of autonomy Other forms of autonomy have also been investigated in various SIMD designs. For example, the MasPar MP-1 and MP-2 machines incorporate 1/0 autonomy; which allows the PEs to concurrently write to different file pointer^.^ The MGAP- 1/MGAP-2 Buffer space can be eliminated by using hor-potuto forwarding algorithms (Newman and Schuster, 1995). Hot-pot algorithms generally increase the worst-case forwarding time. 'The MasPar 1/0 network uses the router communication network in this mode, further iustifying the cost of incorporating the multi-stage router communication network (MasPar, 1991b).

258

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

(Zhou et al., 1995) implement operation autonomy on the single-bit PEs to build flexible operations. For example, 100 PEs may be configured such that they collectively perform addition on 100-bit wide numbers.

3.1.2

Concurrent Execution of Non-Conflicting Capabilities

Capabilities that exercise mutually exclusive subsets of the PE hardware can be made to operate concurrently, executing different instructions at the same time (Blank, 1990). The precondition for this operation is that there is no structural or data conflict between the two operations. An interlock mechanism is used to eliminate data conflicts, while a buffer (shared register space) has to be set aside to exchange data between the concurrently operating subsystems. The MasPar MP- l/MP-2 machines implement concurrent execution of memory-bound and PE-bound instructions. A hardware interlock mechanism is used to detect potential conflicts and stall the dependent instruction until the hazard is eliminated. The Memory Data Register (MDR) serves as the exchange buffer. Note that a conflict hazard occurs uniformly across the PEs, and is therefore implemented using shared hardware on the control unit (Blank, 1990; MasPar, 1991b), making the cost small (since it does not scale with the number of PEs.) This operation is similar to superscalar issue techniques used on microprocessors (Johnson, 1991; Hennesy and Patterson, 1996). Potentially, many concurrent controllers may exist in order to take advantage of intra-thread parallelism. In fact, the MasPar architecture additionally incorporates a concurrently operating 1/0 subsystem, with a buffer memory area used for the data exchange.

3.7.3 Other Hardware Features While autonomy and pipelined operation are the most relevant features to the control organization of SIMD machines, we will briefly discuss other architectural features that have had significant impact on modern SIMD architectures. We revisit the problem of the slow clock speed on SIMD machines, first discussed in section 2.4. This slow clock is forced by the large fan-out, physical distance, and cross-talk problems associated with the control broadcast to a large number of PEs. SIMD machines have failed to capitalize on improved technology because of this broadcast bottleneck. The MasPar MP-2 (1992) cycle time is worse than the cycle time for the Illiac IV (1968) (Allen and Schimmel, 1995a). Rockoff investigated instruction caches as a method for reducing this problem and found that speedups of up to an order of magnitude can be achieved on some applications (Rockoff, 1994). Instruction caches are local

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

259

control units that receive the broadcast instructions from the main control unit. The instructions are cached, and broadcast locally to the PE cluster that is connected to that instruction cache, allowing the local clock speed to be significantly higher. Thus, the control unit is effectively mirrored closer to each PE cluster. The same problem is addressed in a similar manner by the Single Block Multiple Data (SBMD) architecture designers (Baglietto et al., 1994). A different approach to this problem investigates pipelining the broadcast bus to minimize the broadcast delay in a scalable fashion (Allen and Schimmel, 1995a; Blevins et al., 1990). Allen suggests a tree broadcast structure, with the PEs at the leaves of the tree. The instructions propagate from the control unit, through intermediate buffers to the PEs. Thus, the effective clock cycle is bound by the time required to propagate the control signals through a single stage of the pipeline. Implementing a memory hierarchy on SIMD PEs has generally been considered inefficient because of the worst-case execution time problem. In particular, a cache miss on any of the PEs translates into a global cache miss because all the PEs must wait for the slowest one. On a massively-parallel machine, the probability of a global cache hit is effectively zero. Moreover, there is a time overhead necessary to detect a global cache hit. Herbordt and Weems (1995) investigate a partial solution for this problem for applications with direct accesses only (i.e. memory indirection is disabled). Under direct accesses, the states of all the PE caches are identical; a cache hit on any cache is a global cache hit. Allen suggests a similar implementation, where only direct accesses are cached (Allen and Schimmel, 1995b). In addition, Allen implements mechanisms to allow indirect accesses to occur (from memory), without invalidating the direct access cache. This section has overviewed hardware optimizations that have been incorporated into the SIMD model as it has evolved. Special attention was given to optimizations that relax some of the rigidity of the control organization. The discussion of the evolution of the SIMD model is concluded in the remainder of this section as the optimizations to the data-parallel programming model are overviewed.

3.2 Optimizations to the Data-parallel Programming Model The SIMD paradigm consists of a closely matched programming model and architectural platform. The efforts to achieve optimizations at the hardware level have been accompanied by similar efforts to address the shortcomings of the data-parallel model at the language and compiler levels. Some of these techniques were made possible by the accompanying improvements in the underlying architecture. In this section, some of the important work in this area is summarized. Fundamental changes in the

260

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

programming model at the system level are discussed separately in section 5 . Let us first briefly overview a typical programming environment for SIMD machines. The MasPar Parallel Application Language (MPL) (MasPar, 1991c) is a data-parallel programming language that extends C (Kernighan and Ritchie, 1978). In MPL, a data-parallel program is similar to a sequential C program, with the following additions: There are parallel variables, defined using the plural keyword, that reside on the PEs. Thus, the data space on the PEs is allocated identically. A programming language statement that uses a parallel variable is executed by the PEs, while the statements that manipulate scalar variables are executed on the control unit. When a conditional statement (for example, an i f -then-else statement) uses a parallel variable as a condition, each of the possible execution branches are followed sequentially, with the PEs that pass the condition for each respective branch enabled for its duration (the SIMD overhead). Additionally, instructions/library routines are provided for communication among the PEs (communication), between the PEs and the control unit (reduction), between the control unit and the PEs (broadcast), and for carrying out 1/0 operations to the PEs. Additional explanations for MPL will follow shortly in the discussion of Fig. 7. There are numerous studies presenting innovative implementations of specific problems, that are not obviously data-parallel on SIMD, machines (for example, the work of Greenberg et al. (1996) in Parallel Discrete Event Simulation. Many irregular problems are difficult to predict on SIMD machines (Willebeek-LeMair and Reeves, 1990). Hillis argues that data parallelism is available in all applications that operate on large data-sets (Hillis and Steele, Jr, 1986). To that end, he demonstrates that data parallelism exists in a number of algorithms that are usually thought to be inherently not data parallel, including combinator reduction, LR parsing, and linked list manipulation. plural int local-bound; plural int inner-index; plural int outer-index; / / plural variables local-bound

=

p-random

(1, 5000); / / initialize with random value

for outer-index = 1 t o N do for inner-index = 1 to local-bound do body of loop end for; local-bound = p-random (1, 5000); / / assign new random value end for;

...

...

FIG.7. Variable length nested loops.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

261

Several studies investigate solutions using addressing autonomy to enhance the performance of existing algorithms. Chung uses addressing autonomy to concurrently evaluate different logic operations using table lookup (Chung and Chung, 1989). Prins and Smith (1990) use addressing autonomy to speed up parallel sorting on large data-sets (much greater than the number of processors). Tomboulian also uses addressing autonomy to enhance the performance of Mandelbrot set solution algorithms (Tomboulian and Pappas, 1990). More precisely, in traditional implementations of the Mandelbrot set algorithms, all the PEs must wait for the last PE to converge in the inner loop before they can proceed to the next iteration of the outer loop. The indirect memory implementation uses an indirectly addressed index variable that is incremented once the PE concludes each iteration, allowing the PE to index the next iteration and begin executing it. Because a PE that does not converge fast in a given iteration is likely to behave similarly in future iterations, Tomboulian also investigates load balancing; an implementation in which the iterations for the same data point are skewed across several processors. In addition to the studies at the application level, several efforts have targeted relaxing the control flow constraints in high-level data-parallel language constructs that require non-uniform processing. Von Hanxleden and Kennedy (1992) recognized the SIMD overhead problem in variableindex loops in SIMD programs. A variable-index-loop is shown in the MPL code segment in Fig. 7. The control unit must allow for the worst-case path through the inner loop (likely to be 5000, for a massively-parallel system). As PEs with lower values for the local-bound variable finish the inner loop, they must wait until the last PE finishes execution of the inner loop before the outer loop counter may proceed. Von Hanxleden and Kennedy use an optimization, called loq>Jlattening,that allows the ourer-loop index to be incremented as soon as its inner loop is satisfied.x Loop flattening builds on the observation that the inner loop execution is identical for all the outer loop iterations (only the data, including the outer loop index, are different). Thus, the synchronization requirement for the inner loop can be relaxed in the following way: when a PE reaches the end of its inner loop, it proceeds to the next iteration of the outer loop by incrementing outer-index. Unfortunately, the outer loop must suffer the longest path problem synchronization overhead before the control unit can proceed to the portion of the code after it (only the inner loops are helped). Dietz (1992) investigates a compiler optimization, called cointnoiz subexpression induction, where branching region code sequences, scheduled for execution on the PEs, are scheduled to expose common code sequences.

'

Loop flattening represents a generalization of the method used in the Mandelbrot study (Tomboulian and Pappas, 1990).

262

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

The code sequences (threads) are examined and classified according to how they could take advantage of instructions executed across all threads (a SIMD instruction). A pruned search is then performed on the schedules to find the schedule with the minimum time. Thus, the branching regions are minimized in length and utilization of the PE array is maximized. Common subexpression induction is a complex compiler optimization that is expensive to implement. However, it is a useful optimization that potentially results in significant improvement in the performance. It may also be applied piecewise to small, but critical, portions of the code, to alleviate some of their SIMD overhead. Dietz and Krishnamurthy (1993) also present an algorithm for conversion of a MIMD algorithm to a SIMD one. By using static timing analysis, the progress of the state of each PE, if it is allowed to progress independently (MIMD execution), is charted. Dietz develops an algorithm for converting the collection of task graphs representing the PE threads into a single finite state automaton. The algorithm considers the collection of states at every time step of the decoupled PE execution as one meta state. The algorithm begins by constructing a Non-Deterministic Finite State Automaton (NDFSA) consisting of the union of the Deterministic Finite State Automata (DFSA) making up the individual execution threads. The NDFSA is then converted into a DFSA in the usual way (Kohavi, 1978). Naturally, only one program is needed to execute that automata, and it can be readily converted into a SIMD program. The resulting SIMD program is not optimal (or even efficient). Some optimizations on the state machine are carried out to gain a measure of efficiency. Unfortunately, the resulting meta-state machine explodes in size as the threads diverge. Moreover, the meta-state program represents a schedule for sharing the control unit and does not directly address managing asynchronous operation. Despite the success that the hardware and software optimizations discussed in this section have had on specific applications, the fundamental problems with SIMD machines persist. Inherently asynchronous applications will suffer the SIMD overhead as long as only a single thread of control can be supported at any given moment. Therefore, such applications perform poorly on SIMD machines (Demillo et al., 1978). The next section discusses architectures that extend the SIMD model, relaxing the fundamental restriction causing the SIMD overhead.

4.

Beyond the SIMD Control Organization

This section discusses architectures that enrich the control organization of the SIMD paradigm beyond the single control-unit model. As such, these

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

263

architectures are no longer classified as SIMD machines. Two basic approaches are identified. The Multiple-SIMD model injects control parallelism explicitly into SIMD operations by allowing more than one control unit to guide the PEs. In the second approach, the problem of matching the hardware needs of parallel algorithms is considered from a synchronization perspective. Synchronization models that decouple the advantages of the data-parallel model from the restrictive SIMD hardware can be developed. These synchronization models, and the architectural features needed to support them, are discussed. 4.1

The Multiple-SIMD (MSIMD) Model

Multiple-SIMD (MSIMD) machines represent one of the obvious marriages between SIMD and MIMD. MSIMD machines consist of a small number of control processors (CPs) and a (much larger) number of simple processing elements (PEs). Considering that control parallelism is not available in massively-parallel proportions (Fox, 1989), a small number of CPs (for control parallelism) and a large number of simple PEs (for data parallelism) provide a good match for the needs of most massively parallel algorithms. The advantages of the SIMD organization are retained among the PEs associated with each controller; yet, some control parallelism can be tolerated by allowing the PEs to switch among the CPS.~ The CPs represent a MIMD configuration, and consequently, the difficulty in programming and debugging associated with the MIMD model is reintroduced. However, since the number of CPs is small, this difficulty is restricted to a manageable scale. Figure 8 illustrates an abstract overview of a MSIMD organization. The control broadcast network can be viewed as a set of buses that distribute control signals from the CPs to the PEs. Note that MIMD and SIMD organizations can be mapped onto this model. For example, a MIMD organization results when the number of CPs equals the number of PEs, and the control broadcast network is a set of direct connections between CP-PE pairs. Conversely, SIMD organization results when the number of CPs is one, and the control broadcast network is a single bus fanning out to all the PEs. The manner in which the control is delivered to the PEs is the primary distinction for architectures in this class. The structure of the control broadcast network, and how the partitionability of the PEs among the controllers is

’

The idea of multiple SIMD machines has received attention early in development of the SJMD model. For example, initial designs of the Illiac IV intended it to be a MSIMD (Barnes et al., 1968).

264

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

FIG.8. A high-level view of the multiple-SIMD organization.

achieved, make for a rich class of architectures. The simplest organization is a stutic assigr?nreizt, where each subset of PEs is connected to a specific controller. Static assignment makes the control broadcast network simple. This is a considerable advantage since the control broadcast network is often the bottleneck in the instruction execution path (Allen and Schimmel, 199Sa). An example of a MSIMD machine with static assignment is the TMC CM-2 (Hord, 1990). The CM-2 has four CPs, each assigned one fourth of the PEs statically. Thus, four different threads may run concurrently, but they are each restricted to a fixed partition of PEs. In a static assignment MSIMD, the control parallelism is only supported in the form of a collection of threads operating on completely disjoint data sets. Expensive data relocation is required if the data needed by the subtasks overlap, are dynamic, or are not known at compile time. The static partitions help in a multi-programmed environment or for applications with largegrained parallelism and disjoint data sets. For better support of the needs of the algorithms, a more flexible partitioning scheme must be employed. Partitionability is the problem of designing the control broadcast network that will allow a PE to receive its required control thread. The problem is complicated because the control needs may be data-dependent and dynamic. In the remainder of this section, a number of MSIMD architectures that use more sophisticated partitioning schemes will be discussed. The intent of this discussion is to highlight approaches to the partitionability problem, rather than to exhaustively cover individual MSIMD architectures. One of the unique problems posed by a dynamically partitionable system is the needs of the data communication network. The network has to be partitionable in a way that allows the PEs in a single partition to have the functionality of a SIMD network; operating synchronously and allowing a consistent topology across the partition. Moreover, the partitions must not be restricted to communicate simultaneously.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

4.1.7

SURVEY

265

Limited Dynamic Partitioning: the PASM Solution

The Partitionable SIMD/MIMD (PASM) (Siegel et al., 1987) architecture, in one of its modes, is a dynamically partitionable MSIMD machine. The primary motivation for the PASM project is to provide a general research tool to study the needs of parallel algorithms in image processing and pattern recognition. PASM can operate as a set of variable size pai-titions, each of which can operate as a MIMD or SIMD partition. PASM is a scalable architecture consisting of N PEs and Q CPs. Every CP directly controls N/Q PEs in the MSIMD mode. From that perspective, the partitioning scheme is a static assignment of controllers to PEs. However, the partitions may be merged into larger partitions by having the CPs sequence the same program and synchronizing their operation (via a dedicated control and data bus). The partitions are restricted to being power-of-two sizes, sharing the same k lower order address bits, for a 2 k size PE partition. With this scheme, PASM achieves the efficiency of the static assignment control broadcast network, while allowing restricted dynamic partitionability. The size of the partitions varies according to the needs of the subtasks, but must be set globally. The problems persist with tasks crossing partition lines and PEs needing to proceed to different tasks that do not fit the initial mapping. For example, encountering a parallel if-then-else construct poses the following problems: (1) the partition size cannot be determined at compile time, so the compiler has to assume the worst case (all PEs belonging to each partition), and (2) repartitioning will be difficult because PEs in the same physical partition may belong to either branch of the if statement. In such a case, the data for one of the branching targets must be migrated to a new partition. In fairness to PASM, a SIMD partition that exhibits frequent parallel branches can be executed in the MIMD mode of the machine (incurring the synchronization overhead). The PASM communication network, for an n-PE configuration, is implemented as a log,(n) + 1 stage multi-stage network with distributed routing (Siegel, 1984).'" A characteristic of the network is that, for any valid assignment of the PEs to the CPs, the multi-stage network naturally separates into sub-networks that each support a multi-stage permutation connection among the PEs of each partition (Siegel, 1984).This feature allows each partition to operate with the illusion of a dedicated multi-stage network connecting its PEs. The multi-stage option was chosen because it allows the network to operate concurrently with the PEs (such that PEs operating in the MIMD mode do not have to be interrupted to forward messages). "'Only log,(n) stages are required to create a path from every source destination pairs. The extra stage allows the machine to be fault tolerant, by creating alternative paths if switches in a stage fail for any reason.

266

NAEL 6. ABU-GHAZALEH AND PHILIP A. WILSEY

4.1.2 Pyramidal and other Hierarchical Architectures

Hierarchical architectures in general, and pyramidal architectures in particular, are a popular model for machine vision applications (Cantoni et d., 1991; Cantoni and Ferretti, 1994; Fritsche, 1986; Merigot et al., 1986; Tanimoto et al., 1987). Hierarchical architectures consist of stacked layers of processors, with vertical communication paths among the layers in addition to the paths within the same layer (Cantoni and Ferretti, 1994). Pyramidal machines have progressively more processors at every lower level, in the likeness of a pyramid or a cone. Figure 9 shows a typical pyramidal configuration. Typically, each layer contains a power-of-two factor more processors than the layer directly above it. Moreover, the processors are also of increasingly lower resolution and cost at lower levels. Thus, there are many inexpensive, low-resolution (usually a single bit wide), processors at the base of the pyramid and a successively smaller number of more expensive, wider data path, processors at each higher level. The distribution of processors available on a pyramidal organization matches the needs of vision applications well. Low-level processors are used to process the large amounts of sensory data (image pixels, for example). Intermediate levels manage symbolic operations, while higher more powerful processors carry out more intensive knowledge-based tasks (Cantoni and Ferretti, 1994; Maresca et al., 1988; Weems et al., 1992). Communication paths allow communications in the vertical plate (among layers), as well as the horizontal path (across the same layer). There are many control organizations under which this menagerie of processors can operate. For example, the GAM pyramid is pure SIMD (Schaefer et al., 1987), the SPHINX is primarily MSIMD (Merigot et al., 1986) and the EPGA is pure MIMD (Fritsche, 1986). Cantoni and Ferretti ( 1 994) present a

number of PEs

I

PE resolution

up

FIG.9. A pyramidal configuration.

MANAGING CONTROL ASYNCHRONY ON SlMD MACHINES-A

SURVEY

267

taxonomy of pyramidal organizations based on the granularity, homogeneity of the processors, and the coupling among the layers. We will only consider organizations that allow MSIMD operation. MSIMD operation can be introduced into a pyramidal organization using two different models. The first is a static partitioning scheme where a control unit is given control of each layer. An example of a machine using this model is the SPHINX project (Merigot et al., 1986). This organization matches vision algorithms well, as each of the processor planes has the granularity suited to different tasks. The machine operates as a pipelined real-time system, with raw image data being fed to the base processors (from sensors, for example) and processed data forwarded up the pyramid to be processed by each successive layer. Heavy data exchanges occur across the layer boundaries." Because of its static nature, this organization is not capable of general control parallelism, or even control parallelism within the same layer. The second organization allows the processors in every layer to act as the controllers of a partition in the layer directly beneath them (Nudd et al., 1992). This architecture requires all but the processors at the base layer of the pyramid to have the ability to sequence a local computation. With this organization the ability to support an application with a rich mixed-mode control-structure using processors of different resolution exists. Processors at different planes form the apex of independent sub-pyramids, each supporting its own task (ultimately controlling the base processors). As a task branches into sub-tasks, control may be passed down to PEs in the lower layer. In this configuration, the synchronization and communication needs of the system are complex. The network connecting each plane of PEs must be partitionable. It is questionable whether such a system can be utilized well, especially without the development of a programming language and the compiler technology necessary to map applications to this rich control organization efficiently (Cantoni and Ferretti, 1994). For their intended applications (i.e. computer vision), hierarchical architectures have been successful in cost-effectively matching the needs of the application. It is necessary to study the utility of pyramidal architectures in the context of general massively-parallel applications before the success of such an architecture can be assessed.

4.1.3

General Global Partitionability: The GPA Machine

The partitionability schemes used by the PASM and the pyramidal architectures are significantly more flexible than static assignment. However, the l 1 Some designs facilitate this exchange using a shared, multi-ported, memory connecting each two pyramid layers (Cantoni and Ferretti, 1994).

268

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

relationship between the PEs and the CPs is static at the lowest level. This relationship restricts the sets of PEs that can be included in the same partition. The control parallelism allowed by these machines is one-shot and repartitioning to accommodate the dynamic needs of an application requires data migration (alternatively suffering the SIMD overhead). A generally partitionable scheme avoids these drawbacks by allowing a PE to belong to any CP; the single restriction is that it belongs to only one CP at any given time. The Generally Partitionable Architecture (GPA) (Bridges, 1990) implements such a general partitioning scheme. General connectivity between P CPs and N PEs requires a P x N cross-bar to allow the CPs to connect to the PEs in any permutation. Typically, P is much smaller than N (at least by two orders of magnitude). Bridges (1990) demonstrates that such a cross-bar can be implemented using NIP P x P cross-bar elements. According to this scheme, a physical connection between each of the P CPs and each of the NIP cross-bar elements is established. Each of the cross-bar elements routes control to P PEs. An example with two CPs and four PEs is shown in Fig. 10. Note that the partitioning (the setting of the cross-bar elements) must be under the control of the PEs to allow data-dependent partitioning. General partitionability allows the support of control parallelism of a degree less than or equal to the number of CPs. Applications where the partitions overlap or change size dynamically are supported in place by reconfiguration of the control broadcast network. Unfortunately, general partitionability adds overheads to the system. There is a cost for reconfiguration; in applications that are highly dynamic, with frequent changes in CPto-PE mapping, the overhead becomes significant. Moreover, not only will the cross-bar elements add to the cost of the system, they also exist on the control broadcast network-one of the primary bottlenecks of centralized control organizations. The cross-bar elements extend this critical path and likely force a longer instruction broadcast clock cycle.

P control units

FIG.10. The GPA control broadcast network.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

4.1.4

SURVEY

269

The Superscalar SIMD Machine

The superscalar SIMD (SSIMD) machine is a generally partitionable MSIMD machine that hides the partitioning of the PEs and the details of the control broadcast network from the user (Allen et al., 1993; Garg and Schimmel, 1995; Schimmel, 1992). The motivation for the SSIMD architecture is to improve the performance of SIMD machines on parallel branches. Parallel branch constructs represent a potential target for parallelization because they separate the PEs into disjoint sets that can be processed concurrently-by assigning a control unit to each set. Thus, the time taken for a branching region to execute is reduced from the sum of the times needed for all of the branches, to the time needed by the longest branch (ignoring partitioning overhead and possible data conflicts). Under the SSIMD model, the compiler detects parallel branching regions (if-then-else or similar constructs), inserts fork instructions into the instruction stream at the beginning of the branching regions, and ajoin instructions at the end. The CPs are each initialized with a copy of the program. When a fork instruction is encountered, a CP, if one is available, is initialized with the context of the parent CP and the program counter of its branch (e.g. else clause). The PEs evaluate their local condition value, and decide which of the two CPs to receive control from. At the end of the branching region the two streams are merged again by synchronizing on a barrier. Since the fork and join instructions are heavily used, a multi-ported shared register set is supported to allow a single cycle context initialization for forks (Schimmel, 1992). SSIMD is different from other MSIMD machines in that it preserves the SIMD semantics and operation at the user level. In order to preserve SIMDlike operation, mechanisms for resolving conflicts on data accessed by different branching targets are implemented. On SIMD machines there is an implicit ordering on the access to the shared variable (first branching target gets executed first, and so on). This ordering is enforced for scalar variables using built-in logic (a multi-ported copy-and-merge register sets) and for parallel variables using the communication network (Garg and Schimmel, 1995). With the discussion of the SSIMD architecture, we conclude the overview of the MSIMD model. Several MSIMD machines were overviewed and the tradeoffs involved in the architecture design were outlined. Primarily, the effect of the control broadcast network on the partitionability and the flexibility of support of control parallelism was discussed. The remainder of this section overviews strongly synchronized architectures. These architectures decouple the advantages of a strongly synchronous environment from the limitations of SIMD hardware.

270

NAEL B.ABU-GHAZALEH AND PHILIP A. WILSEY

4.2

Other Synchronization Models

Earlier in this paper we discussed how the difference between the SIMD and MIMD models may be viewed as a difference in synchronization philosophies. Whereas MIMD machines are essentially unsynchronized (synchronization has to be introduced by the user, often at a great cost), SIMD machines are implicitly synchronized at the instruction boundary (effectively eliminating the ability for supporting control parallelism). Thus, for most applications, MIMD machines are under-synchronized while SIMD machines are over-synchronized. The argument can be made that neither the MIMD nor the SIMD organizations is efficient because neither matches the synchronization needs of general parallel applications. In this section, we discuss alternative synchronization models developed to better match the needs of parallel algorithms. In general, a synchronization model that bridges the gap between SIMD and MIMD follows one of two approaches. The first approach incorporates efficient synchronization and fine-grained data access into MIMD operation (Agarwal et al., 1995; Kuskin et al., 1994; Kranz et at., 1994). This approach results in expensive machines, because asynchronous MIMD operation remains at the core of the model (efficient synchronization is implemented explicitly). The other approach studies methods of relaxing the rigidity of the SIMD synchronization model; architectures classified under this approach implement a synchronization model that is less rigid than the SIMD model, but still incorporates implicit synchronization guarantees. Relaxing the enforced synchronization at the instruction boundary requires that the PEs be able to sequence their own computation (like MIMD PEs). However, the implicitly synchronous operation allows assumptions about the behavior of the architecture to be made, simplifying the PE and system designs. The remainder of this section overviews several architectures with support for highly efficient synchronization.

4.2.1 The SPMD Model An emerging model for programming massively parallel machines is the Single Program Multiple Data (SPMD) model (Nichols et al., 1993). The SPMD model is a subset of MIMD algorithms where all the PEs execute the same program. Each PE follows its own path through the same program, based on its local data. Thus, SPMD can be described as unsynchronized SIMD. SPMD provides an easy mapping between the data parallel model and MIMD machines (Hatcher and Quinn, 1991). Accordingly, it provides an effective model for exploiting both data and control parallelism. The SPMD model is similar to data-parallel algorithms in that each PE operates

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY 271

on a subset of the data domain, allowing data parallelism to be exploited. Yet, relaxing the synchronization at the instruction boundary allows control parallelism to be supported among the PEs (and makes the model more suitable for MIMD machine execution). Data parallel languages can be readily and efficiently compiled for MIMD machines using this model (Brandes, 1993; Carrier0 and Gelernter, 1994; Hatcher and Quinn, 1991). In itself, SPMD is a subset of MIMD algorithms where all the PEs execute the same program. It represents a programming model for MIMD platforms, with no inherent synchronization advantages.12However, an important characteristic of the SPMD model is that it provides a mechanism for integrating the desirable properties of the SIMD and MIMD models on the same platform. More precisely, by controlling the synchronization model residing on top of the otherwise SPMD operation, a more flexible implementation of data parallel execution is achieved. Moreover, it is possible to change the synchronization model to adapt to the nature of the application being executed. In the limiting cases, enforcing implicit synchronization at the instruction boundary results in SIMD operation, while removing implicit synchronization results in MIMD operation. The OPSILA architecture is an architecture that supports integrated SIMD/SPMD execution within the same application, by utilizing the relationship between the SPMD and SIMD models (Anguin, 1986). The advantages of this integration is that phases of the application that are fine-grained can utilize the SIMD model, switching to SPMD for the portions requiring conh-ol parallelism. The transition from SIMD to SPMD may occur at any time. The reverse transition (from SPMD to SIMD) requires resynchronization at some point in the program; all the PEs much reach a synchronization point before SIMD operation is resumed. OPSILA restricts synchronization in the SPMD mode to be a switch back to the SIMD mode. Moreover, to simplify the hardware, the SPMD mode is restricted from communication. If the workload is not balanced this leads to inefficient operation (but always at least as efficient as SIMD, recalling that there is no synchronization in the SPMD portions). Figure 11 illustrates how OPSILA manages code segments requiring control parallelism. The programmer marks the beginning of the control parallel code segment (in this case a parallel branch) with the spmd statement. The end-spmd statement signals the machine to synchronize in preparation to resuming SIMD execution. Synchronization is a total (barrier) synchronization, and can be efficiently and economically supported. In the SIMD mode, instructions are fetched by the system control unit, which executes

'* Because the object code for all the programs is shared, certain optimizations can be carried on in an architecture designed exclusively SPMD. For example, security and boundary checks on communication can be simplified, allowing communication with no operating system interference (Eicken e t a [ . , 1992).

272

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

plural condition; / / SIMD statements spmd ; / / instruct machine to go into SPMD mode if ( condition is true ) then do-this(); else do-thato; endif;

...

end-spmd;

...

/ / resynchronize and go back to SIMD / / more SIMD FIG. 11. Integrating SIMD and SPMD.

scalar operations, and enters vector operations into an instruction queue for broadcast to the PEs through a dedicated control broadcast network. Each PE has an associated memory bank where vector data, as well as identical copies of the SPMD segments of the application, are kept. In the SPMD mode, each PE operates asynchronously and completely within its memory. Although the programming model for the OPSILA is easy to use, it is very restrictive. PEs must all be synchronized together, leading to over-synchronization when only a few PEs require synchronization. Moreover, since it is impossible to communicate in the SPMD mode, the operation must switch to SIMD mode for communication, requiring additional artificial synchronization. Under these constraints, the SPMD regions become smaller, as frequent synchronization is necessary. The integration of SIMD and SPMD on the same platform is a promising approach for mixed-mode applications. It merits further investigation with a less restrictive synchronization model and programming environment (Nichols et al., 1993).l 3 4.2.2 The Virtual-Time Data-Parallel Machine The Virtual-Time Data-Parallel machine (VTDPM) uses an optimistically synchronized model to realize SIMD behavior efficiently and implicitly on a SPMD configuration (Shen, 1991; Shen and Kleinrock, 1992). The synchronization model is based upon virtual time, a model for distributed optimistic synchronization first developed by Jefferson for use in Parallel Discrete-Event-Simulation (PDES) (Jefferson, 1985). Instead of forcing the PEs to wait at a synchronization point, optimistic synchronization allows them to continuously advance their computation (even across synchronization points) in the hope that the computation will prove to be useful. A recovery mechanism is implemented to allow a PE to return to a “correct” “For example, on SIMD/MIMD machines like PASM (Siege1 et al., 1987), TRAC (Sejnowski et al., 1980) and the TMC CM-5 (Thinking Machines Corporation, 1991).

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

273

state in the event that the optimistic computation proves to be erroneous. The following paragraphs will briefly review the main concepts of virtual time, then describe how these techniques are used by the VTDPM. Readers interested in more details about virtual time and PDES are referred to a survey article on the subject (Fujimoto, 1990). Virtual time models the passing of time in a simulation (discretely). Events occur at certain virtual times, and they in turn may trigger other events that happen in future (relative to the triggering event) virtual times. Thus, the virtual time specifies the ordering of events relative to each other in the simulation (Lamport, 1978). For parallel discrete event simulation, each simulation object must process the events directed to it in virtual-time order to insure correct simulation. Conservative protocols (Misra, 1986) process each event only if the event is guaranteed that all the events in its past that can affect it have been processed. Alternatively, in order to maximize parallelism, optimistic approaches (Jefferson, 1985) allow a PE to optimistically process current events in virtual-time order, without waiting for possible conflicts (messages with an earlier time-stamp) to occur. Parallel discrete-event simulation is explained in more detail below. A parallel discrete-event simulation consists of a collection of logical processes (LPs), each modeling a component of the simulation (an LP represents the computation assigned to each PE). Every LP advances its local virtual time (LVT) by processing its local pending events in order (least time-stamp first). LVT is the time of the latest event to be processed. This model is optimistic because each LP advances its own computation without regard to the virtual time of other LPs. An LP may receive events scheduled to it in the past (from LPs that are at earlier LVTs) rendering part of the computation incorrect. Because of that possibility, the state is saved periodically, and the LP is rolled-back to a previous consistent state if an out-of-order event is received (sending anti-messages to cancel events it had triggered with the erroneous optimistic advancement). Global progress is denoted by the global virtual time (GVT) and is defined as the smallest time-stamp of all the unprocessed events in the system. The state of the simulation at GVT is known to be correct. VTDPM employs a virtual-time model to achieve asynchronous execution of SIMD programs using an optimistic synchronization strategy similar to Time Warp. The objective is to speed up SIMD execution transparently to the user by relaxing the instruction boundary synchronization forced by SIMD hardware,I4while preserving the algorithmic advantages of the dataparallel programming model. l4 Asynchronous execution can be shown to be up to 6rN times faster than synchronous execution for an N processor machine (Felderman and Kleinrock, 1990).

274

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

The data-parallel execution model can be described in terms of virtual time as a series of events (representing the instructions being executed) that occur at successive virtual-time steps. The virtual-time ordering on these events is the ordering that occurs if this were a synchronous SIMD machine (i.e. all the instructions that are executed together on a synchronous SIMD, share the same virtual-time value). Each event (instructions) triggers only the next instruction execution on its PE model. This is a local event; the interaction of the LPs is restricted to data requests. Synchronous SIMD operation corresponds to conservative synchronization. It assumes that all the instructions with time-stamps t at all the PEs have to be finished before any instruction with a higher time-stamp can be executed, globally ordering the events. In contrast, the synchronization protocol on the VTDPM assumes that every instruction occurring at virtual time t depends only on the previous instruction on the same LP, and at most one other instruction at time t - 1 on another LP. When it is time to execute an instruction that has a remote operand, one of three scenarios exists: (1) the LP where the remote operand resides has not reached the same virtual time; the operand is not ready and the LP has to wait, (2) the remote LP is at the same LVT; the operand is ready and correct, and ( 3 ) the remote LP is at an LVT ahead of the local LVT; the required operand may have been overwritten by subsequent instructions at the remote LP. In order to solve the problem posed by the third scenario, the PEs maintain a history of the variable values as they change. If case ( 3 ) occurs, the history of the variable at the requested virtual time is looked up in the history list and forwarded to the requesting processor. Because this is a heavily used ability, it is supported in hardware using an associative FIFO history cache. If the cache is full on any PE, a GVT calculation is started and histories at virtual times less than GVT are discarded. Each PE is free to execute at its own pace, as long as its operands are ready. This ability alleviates the worst-case execution time problem characteristic of the SIMD model. For example, SIMD communication often has a worse-case time a few orders of magnitude worse than the average time. Using the Virtual Time Data-Parallel machine, only the PEs where the worst case occurs suffer its cost; all PEs proceed as soon as their data are ready. However, is this synchronization model sufficient for supporting general control parallelism? When a conditional region is reached, the SIMD semantics dedicate that the alternative regions be issued sequentially, with the PEs not meeting the condition for a region staying idle. If the length of the region is known statically, the PEs that do not take part in it can safely advance their LVT to the end of the idle time and continue with its computation asynchronously. Unfortunately, often the idle time is not known statically, or even varies

MANAGING C O N T R O L A S Y N C H R O N Y ON S I M D MACHINES-A

SURVEY

275

depending on local variables. Without knowing the length of the idle time, it is impossible to advance the computation safely. It is not critical that the precise virtual time be used, as long as the order of the events is preserved. A secondary virtual time with a higher granularity can be used for such cases (for example, each branching target represents a single increment of the higher granularity virtual-time indicator). Managing dynamic, or diverging, control parallelism using the VTDPM is an open question. Analysis of the Virtual-Time Data-Parallel machine model forecasts an asymptotic speedup of 40%, considering only the speedups gained from alleviating the worst-case instruction time problem. Considering the advantages obtained from the ability to support control parallelism, this approach has the potential of drastically improving the performance of asynchronous applications. Unfortunately, the model also requires complex hardware, using MIMD PEs augmented with the fast FIFO history caches and an asynchronous general connectivity network. It is unclear how a real machine based on this model will perform when considering the overhead of maintaining the history queues and updating GVT.

4.2.3 Hard ware Barrier Machines MIMD machines can emulate SIMD operation by inserting a full barrier synchronization after every instruction (Cohen et al., 1994a) and the addiUsing tion of a mechanism to enable the PEs to stay idle for an in~truction.'~ this model to simulate SIMD operation is inefficient, because synchronization time dominates execution time. Indeed, frequent synchronization is the reason why MIMD machines are inefficient for fine-grained applications. A number of architectures implement synchronization mechanisms directly in hardware, achieving synchronization times much faster than software-based synchronization (Cohen et al., 1994b; Cray Research Inc. 1993; Kranz et al., 1994; Lundstrom and Barnes, 1980; Thinking Machine Corporation, 1991). The synchronization hardware can be used explicitly, by offering the programmer a MIMD environment with efficient synchronization, or implicitly by providing a run-time model that is strongly synchronous (Cohen et al., 1994a). In this section, we consider synchronization architectures based on barrier synchronization protocols (Hensgen et al., 1988). Barriers are a synchronization model that operate in the following manner. A barrier is inserted where a synchronization point is desired in the program. All the PEs participating in the barrier have to reach that point in the program, before any may l5 Enable masking can be supported without hardware modification (Keryell and Paris, 1993).

276

NAEL 6.ABU-GHAZALEH AND PHILIP A. WILSEY

proceed beyond it. When all the participating PEs arrive at the barrier, the barrier is said to befired. The PEs are notified, and proceed with their computation. There are number of different types of barriers, defined by the set of functions they are able to provide. Moreover, the synchronization functions that the barriers make available to the PEs define the models of parallelism that the machine can support. The main barrier classes are as follows.

4.2.3.7 Full barriers These are barrier architectures where all the PEs must participate in each barrier. Supporting full barriers only is sufficient to emulate the SIMD synchronization model. Thus, full-barrier synchronization can also be used to emulate a SIMD/SPMD environment, such as the one used on the OPSILA (Auguin, 1986).16The Triton/l (Philippsen et al., 1993) machine is a MIMD machine with full-barrier synchronization supported through an efficient global-or barrier tree. 4.2.3.2 Fixed-partition barriers These differ from the full barriers in that subsets of the PEs can be specified for meeting at a barrier. PEs not participating in the barrier are unaffected and continue with their computation. Fixed-partition barriers can be used to emulate MSIMD, MultipleSPMD, or similar models that have explicit control parallelism. It is also important for multi-programmed environments-allowing several applications to share the machine. Burroughs Flow-Model Processor (FMP) implements a fixed-partition barrier architecture (Lundstrom and Barnes, 1980). The barrier architecture is an and-tree with provisions to allow sub-trees to synchronize independently. The drawback of this approach is that the mapping of the processors to the barrier groups is fixed. Only processors in the same sub-trees may have an independent barrier.

4.2.3.3 Maskable (static) barriers These are partitionable barriers that allow general grouping of PEs that need to synchronize. A full barrier tree is augmented by a user-specified mask such that PEs can be excluded from the barrier. The advantages of this approach over the fixed-partition barrier is the support for dynamic sets of synchronizing processors. Unfortunately, because there is one logic tree that implements the barrier, only one barrier may use it at a time. Thus, there is a static ordering of the barriers that has to be followed. If barrier group B owns the barrier tree, other barriers are blocked from using it, even if they are ready to fire. The l6 In fact, the OPSILA can he considered a full-barrier machine. However, we do not include it in this discussion because its SIMD mode is implemented using a centralized control processor and control broadcast network (and not by synchronizing the available distributed controol using the barrier architecture).

MANAGING CONTROL ASYNCHRONY ON SlMD MACHINES-A

SURVEY

277

firing order of the barriers is static across the machine (the barrier masks are queued into the masking registers, forcing this ordering). For that reason, this type of barriers is also called static barriers. This restriction can be relaxed by implementing multiple barrier trees. Thus, two groups of PEs following different control paths can each be scheduled to use separate barrier trees. There is still a total ordering on the barriers scheduled to each barrier tree. The T3D (Cray Research, Inc. 1993) is an example of a machine with several static barrier trees.

4.2.3.4 Dynamic barriers These relax the total ordering restriction enforced by static barriers (Cohen et al., 1994a, 1994b). Instead, a partial order of the barriers can be specified. The partial ordering allows barriers within the same control thread to be ordered, while barriers within different control threads are not ordered with respect to each other as per the static model. The dynamic-barrier model is better than the static model because the barriers are never blocked if they are ready to fire. Unfortunately, it is difficult to build efficient, scalable, dynamic-barrier hardware. The PAPERS project investigates connecting a (relatively small) number of processor boards using efficient dynamic-barrier logic that also serves as a fast (but low bandwidth) communication network (Cohen et al., 1994a, 1994b; Dietz et al., 1994). The barrier logic is built using a maskable barrier tree, duplicated at every PE, and a bit-wide fully-connected network. The barrier instruction is achieved by overloading the LOAD instruction. A LOAD to a special address is decoded as a barrier wait request and causes the PE to inform all the processors in this barrier that it is waiting (by asserting the respective lines on the full connection network). In response, the processor receives a notification from every PE in this barrier group that has reached the barrier. The static barrier tree is used to evaluate locally whether the barrier should be fired. Unfortunately, the barrier architecture used on the PAPERS project is not scalable (wiring complexity of O(n2),as well as an n input nand tree at every PE). However, it achieves dynamic synchronization ability at a rate four orders of magnitude faster than traditional socket-based synchronization for the cluster of 32 PEs that was tested. Work is in progress to build the CARD parallel machine based around this barrier synchronization model (with a tree hierarchy used for scalability). The TMC-CMS (Thinking Machines Corporation, 1991) uses a control network to realize general dynamic barriers. The barrier is implemented using message exchange among the PEs through a dedicated control network. Since this implementation is slower than a hardware logic tree, a fuzzy-barrier implementation is used (Gupta, 1989). Fuzzy barriers allow the PE to send a notification before they reach the barrier. Thus, the PE has

278

NAEL 6.ABU-GHAZALEH AND PHILIP A. WILSEY

some work to do while it waits for the barrier to synchronize. The synchronization is terminated when the PE receives a notification that the barrier has been fired. Although fuzzy barriers are more efficient than hard barriers for large-grain synchronization, the CM-5 implementation is much slower than a logic-tree barrier implementation. It is interesting to note how the barrier architecture duals the operation of the control broadcast network in MSIMD machines. The number of threads MSIMD machines can support is limited by the number of available control units, whereas the barrier machines are limited by the number of barriers that can be supported concurrently. Moreover, dynamic barriers allow a control model that most resembles globally partitionable MSIMD (or Multiple-SPMD) machines, while barriers with static assignment result in operation most similar to MSIMD machines with restricted partitionability. In addition to using fast synchronization to support efficient fine-grain computation models, it can also be used to enable accurate static time analysis and compile time scheduling of operations to avoid congestion and reduce conflicts (Cohen et al., 1994b; Kashara et al., 1991). The next section discusses the concurrent-interpretation model. Contrary to the architectures discussed in this chapter, the concurrent interpretation model supports the MIMD model at the application level, but attempts to do so with a centralized control organization. Thus, the freedom to support control parallelism is introduced, but the hardware cost is kept low, and the synchronous operation is maintained at the implementation level.

5. The Concurrent-interpretation Model The main disadvantage of the data-parallel programming model, and its implementation on SIMD hardware, is that the control unit is shared at the thread level-only one thread uses the control unit at a time. Clearly, the higher the degree of control-parallelism present in the application, the less efficient this sharing scheme becomes. The exclusive assignment of a control unit to a thread is inherited from serial processors, where the instruction stream is sequenced by a dedicated control unit and no sharing is needed. l7 Similarly, MIMD machines have a dedicated control unit for each thread. With a single control unit servicing the needs of more than one data path, SIMD machines have a unique control organization. Concurrent interpretation is a novel model for programming SIMD machines that specifically targets better sharing of the control unit among ” Even when multiple threads exist on a serial processor, the time-sharing is forced because only one data path exists.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

279

asynchronous threads. While the data-parallel model implicitly assumes that the normal application will have no control parallelism, interpretation assumes that every PE may require a distinct execution thread. Accordingly, the specification of the control under the concurrent interpretation model must be local to each PE. This is in contrast to the data-parallel model where the algorithm resides at the control unit. The "trick" by which the PEs sequence their independent control thread without having a physical control unit is concurrent interpretation. By casting the programs into data, residing in a programs [ ] array in the local PE memory, a data-parallel interpreter routine can concurrently simulate the execution of these programs. In the remainder of this section, the interpretation model is presented in detail.

5.1 Early Experiments Early studies used interpretive approaches to map specific asynchronous applications to SIMD machines. One such study uses interpretation to support efficient logic simulation on SIMD machines (Kravitz et al., 1989). Traditionally, logic simulation is not considered suitable for massively-parallel implementation because: (1) there is a small degree of parallelism present in discrete event-driven simulation, and (2) it is a fine-grained application, requiring little computation in between the frequent communication operations. Consider the fact that the simulation of a logic gate typically involves one instruction to compute the output, followed by one or more communication instructions to forward the results to the fan-out targets of the gate. Kravitz presents a logic simulation algorithm for SIMD machines (Kravitz et al., 1989). The circuit is preprocessed into a behaviorallyequivalent Sum-of-Products representation (Kohavi, 1978), for which an equivalent circuit consisting of AND and OR gates is constructed. The circuit is mapped to a rank-processor rectangle, where each rank represents a simulation step on the SIMD machine in the following way: a gate can be placed in any rank after the one where its last fan-in operand is generated. Within the same rank, gates are mapped to processors in a way that makes the forwarding of the data possible using the allowed communication operations. It is assumed that each gate has a maximum fan-out of 2; higher fan-out is realized by installing empty fan-out nodes. Each PE is initialized with the gate and fan-out information at every rank. The simulation is carried out by having the control unit execute the concurrent-interpreter algorithm shown inFig. 12.

''

l8 There is a tradeoff between the complexity of communication operations supported, and the length of the simulation cycle (Kravitz et al., 1989).

280 1. 2. 3. 4. 5. 6. 7.

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

while (rank <= max-rank) if (gate[rank] == OR) then {output = inputl I input2;) if (gate[rank] == AND) then (output = inputl & input2;) forward output to first fan-out destination; forward output to second fan-out destination; rank = rank + 1; end while; FIG.12. Interpreter for logic simulation.

Any number of logic circuits can be simulated concurrently (provided that enough processors are available) at a performance that scales with the number of processors used. In general, the operation of each simulated circuit is different from the other circuits. A traditional SIMD implementation requires that each circuit be simulated at a time. However, by breaking down the circuits into sequences of common operations (AND,OR, followed by the fan-out delivery), it becomes possible to simulate them concurrently. Because the number of possible operations at every step is small, high PE utilization is achieved. In other work, concurrent interpretation is used to implement evaluators for applicative programming languages on SIMD machines (Hudak and Mohr, 1988; Nilsson and Tanaka, 1988a; Kuszmaul, 1986), using combinator reduction (Turner, 1979). Briefly, combinator reduction translates a functional language query into an expression involving nine basic combinators (in Turner's original model). The expression is then reduced (using the reduction rules for the nine combinators) in order to produce an answer. The reduction process can be viewed as a series of transformations on a graph representing the query. The graph is constructed automatically from the query, with each node representing an application of the left child to the right child (using currying l9 to express multiple operator combinators). The graph representation allows the reduction of the query expressions to be carried out in parallel. Standard parallel implementations of the reduction process reduce the sub-graphs concurrently. Since the sub-graphs are generally dissimilar, this concurrent reduction is an asynchronous application that is not suited for implementation on SIMD machines. Moreover, implementations on MIMD machines have proven inefficient because the granularity of the combinators is too fine. Although the sub-graphs assigned to the PEs are different, they each consist of a sequence of combinators from the common set of combinators in the reduction implementation. A concurrent-interpretation implementation can be built such that combinator reductions of the same type are evaluated concurrently. The interpreter algorithm interprets all the combinator "Using currying, a functionf(x, y) is expressed as (f(x))(y).

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

281

operators in every iteration and the PEs conditionally execute the combinator operation that is needed for their local graph reduction (Hudak and Mohr, 1988).

5.2

Large-grained Interpretation: The P-kernel

The basic characteristic of an application amenable for concurrent interpretation is the ability to express the computation required at each PE as a stream of operations from a finite (and small) set of operations. The P-kernel is a run-time support system that provides an environment for using concurrent interpretation to implement asynchronous applications on SIMD machines (Shu and Wu, 1995, 1993). An application consists of a number of threads with each PE assigned at least one thread. Furthermore, the application explicitly specifies a set of processes that constitute the process set for the application. More precisely, threads may only use these processes to express their required computation. Each process consists of a set of atomic computations that share one common data area. The atomic computations include general application code segments as well as a number of P-kernel primitives. Each computation also specifies a triggering message that signals it to start execution. Pkernel primitives for sending a communication message, scheduling a new process, or signaling the termination of the current process are supported. There is no implied order to the execution of the atomic computations within a process; they are executed in the order that their triggering messages are received. A thread consists of a schedule of process invocations, which may in turn create new processes. Addressing autonomy is used to pass the parameters of the process indirectly, making it is possible to concurrently execute invocations of the same process occurring in the threads of different PEs. The Pkernel executes between process executions, forwards data messages, and decides which process to schedule for interpretation next. The scheduling is carried out by polling the PEs and deciding which process is requested by the highest number of PEs. The P-kernel also manages load-balancing decisions (if a PE is running out of memory, for example, some of the processes scheduled to it may be moved to another PE). Consider a fully asynchronous application, where each PE follows a unique execution path (thread). A traditional SIMD implementation results in sequential execution of the threads, with only a single PE active at a time. The P-kernel approach allows a better utilization of the PEs by allowing all the PEs interested in the process that is scheduled next to concurrently execute it. Assuming that the number of different processes is k and assuming an auction algorithm is used to schedule the next process, no less than

282

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

N / k out of N processors (and potentially significantly more) are able to advance their computation at every step. This reasoning is true of all concurrent-interpretation environments. Figure 13 shows a snapshot of PEs on a SIMD machine working under P-kernel. Examining this snapshot, several observations can be made: The scheduling and process management time is an overhead incurred between process executions. In order for the model to be useful, the overhead time must be small in comparison to the process execution time. Thus, the granularity of the processes should be large in comparison to the overhead time. The overhead can be decreased by using a predetermined process schedule (without having to poll the PEs to determine which process to schedule next). This approach leads to a lower utilization of the process execution portion, but a shorter scheduling portion. The process execution times of the same process on different PEs can vary. More precisely, based on the parameters of the process and the state of the thread, the execution of the same process may require different control paths to be followed through its program. Thus, while the control-parallelism is being managed at the process level, the controlparallelism inside the processes themselves is not-causing the SIMD overhead problem to appear. A subset of the PEs is active for an execution region. Only a PE that has an invocation of the chosen process next in its execution stream takes advantage of that process execution. If the number of different processes is high, the fraction of active PEs per cycle drops. We note that interpretation is somewhat of a misnomer when performed at the process level-the processes are executed in the native SIMD mode. PEO PE1 PE2 PE3

P-Kernel Active Process Executlon Idle

FIG. 13. A snap shot of PEs on a SIMD machine operating under P-kernel

MANAGING CONTROL ASYNCHRONY ON SlMD MACHINES-A

SURVEY

283

The P-kernel is more accurately described as a scheduling system that aligns the execution of processes for enhanced performance.

5.3 General Concurrent Interpretation In all the concurrent interpretation models discussed above, the set of interpreted operations is derived from, and is specific to, the application. In contrast, general concurrent interpretation is based upon the premise that a general set of operations, which is capable of expressing any application, can be constructed. For example, a traditional computer instruction set represents such an operation set. However, there are a number of additional requirements that concurrent interpretation places on the instruction set design. Before we discuss these requirements, we present a quick overview of a general interpretation environment and review some of the important work in this area. Under a general concurrent interpretation environment, the programs representing the threads to be executed are compiled into an interpreted instruction set and the object module for each program is placed into a distinct PE memory. In addition, memory for the state of the interpreted machine (e.g. program counter, registers) is allocated on each PE. The control unit then executes a Central Control Algorithm (CCA) that repeatedly broadcasts the control signals necessary for interpreting the instruction set to the PE array. A PE is active for the portion of the CCA required for interpreting the current instruction in its local instruction stream-remaining idle during the other parts. A typical CCA is shown in Fig. 14. In each cycle, the instruction streams of all the PEs are advanced. Thus, concurrent execution of multiple instruction streams is realized with a cycle time that is independent of the number of PEs or the control structure of the application. Decoupling the interpretation environment from the details of the application is desirable for the following reasons: (1) it justifies efforts spent towards highly optimizing the CCA, (2) it provides a constant instruction set interface with static timing properties; allowing sophisticated compiler loop forever 1. fetch instruction 2. decode operands 3. if (opcode = ADD) then {interpret ADD instr.) if (opcode = AND) then {interpret AND instr.}

...

4. store results 5. update local program counter end loop FIG.14. Example central control algorithm.

284

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

optimizations to be utilized, and (3) it allows the optimization of the architecture to support the chosen instruction set. Constructing interpreters specifically for each application offers the potential of better performance over using a general instruction set. However, it is unlikely that this advantage will justify the effort required to construct and optimize specialized interpreters, given that the general CCA is highly optimized. Several researches have studied general concurrent interpretation. Nilsson and Tanaka (1988b) discuss interpretation using a theoretical instruction set. Similarly, Collins (1988) discusses using interpretation to optimize the performance on SIMD machines on parallel branching regions. Several researchers (Abu-Ghazaleh et al., 1993; Dietz and Cohen, 1992a; Hollinden et al., 1992; Littman and Metcalf, 1988; Sanders, 1994; Wilsey et al., 1992) discuss the implementation of specific instruction sets and provide results characterizing their performance. These investigations uncovered some interesting results and suggested several optimizations to the interpretation model. These experiences are overviewed in the following sections.

5.4

Characteristics of Efficient Interpreters

The CCA is similar to traditional interpreter programs.20However, there is a fundamental difference in the execution of the CCA from that of traditional interpreter programs. Whereas only one instruction is interpreted every iteration through an interpreter program, all the instructions must be issued by the CCA (Wilsey et al., 1992). Thus, while the design of an instruction set for serial execution emphasizes the efficiency of the execution of the individual instruction, the design of the instruction set for the concurrent interpretation paradigm has the more difficult task of optimizing the sum of all the instructions. The CCA is a data-parallel program whose performance drops with the number of branches it has to follow (since it is implemented on a single physical control unit). If the number of instructions is kept small, with simple instructions, the length of the CCA is reduced. However, the instruction set must be rich enough to express tasks efficiently. There is a tradeoff between the number of instructions in an instruction set and its expressive power. A good instruction set for interpretation eliminates the redundancy among the instructions and addressing modes. As long as there is an efficient way to express the common operations, the compiler can be given the task of finding it. A complex instruction that is rare should not be directly supported if there is a combination of supported instructions that realizes it 2o A

more appropriate analogy, to microprogrammed control units, will be made later.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

285

(Wilsey et al., 1992). Because the granularity of the instruction execution is small, the overhead for managing the interpretation must be kept small in order to achieve acceptable performance (Abu-Ghazaleh et al., 1993; Littman and Metcalf, 1988). This requirement translates into using simple uniform encoding across all the instructions, minimizing the scheduling overhead for instructions, and simplifying the interpreted machine state. In particular, the state of the machine should be kept in the registers of the SIMD PE, since these state variables are likely to be accessed several times in every iteration (Dietz and Cohen, 1992a; Wilsey et al., 1992).

5.5

Optimizing the Interpreter Loop (CCA)

Any reduction in the CCA length represents a reduction in the execution time across all the PEs for every instruction. The most important optimizations are discussed in this section. While there is agreement on the general characteristics of efficient interpreters, there are a number of different, and sometimes conflicting, optimization strategies to the structure of the CCA.

5.5.1 Interpreter Structure In one of the early studies in this area, Nilsson and Tanaka (1988b) analyze the interpretation of a theoretical instruction set. In their analysis, they study a slightly different structure for the interpreter (Fig. 15). This interpreter fetches new instructions after every distinct opcode execution. In contrast, more recent work moves steps 1, 2 , 4 and 5 of Fig. 15 outside the inner loop to achieve a more efficient interpreter (Fig. 14). The overhead for the interpretation is magnified by having to fetch, decode, and update the state after every individual instruction. However, decoupling these functionalities makes it possible for a PE to advance more than one instruction for each iteration. fetch instruction loop forever foreach instruction A in the instruction set. forall PE’s waiting on instruction A 1. decode operands. 2. interpret A . 3. store results. 4. update pc. 5. fetch next instruction. end forall end foreach end loop FIG. 15. Central control algorithm used by Nilsson and Tanaka.

286

NAEL 6.ABU-GHAZALEH AND PHILIP A. WILSEY

Nilsson and Tanaka also study the effect of the ordering of instruction issue within the CCA. An algorithm for finding the optimal permutation of instruction issue is developed. This permutation maximizes the expected number of instructions that each PE advances in each CCA. Note that each instruction is issued at least once, so there is no danger of starvation. The interpreter structure in Fig. 15 is useful only if the overhead is small with respect to the instruction execution time (Abu-Ghazaleh and Wilsey, 1997a).21

5.5.2 Maximizing the Overlap in the Execution of Instructions One of the methods for decreasing the length of the conditional regions in the interpreter loop is to overlap the common execution portions among instructions. The control unit under interpretation represents a micro-programmed control unit that is shared among the data paths of the PEs. In this analogy, the instructions of the CCA correspond to the micro-instructions of the micro-program (Hayes, 1988). In a non-shared micro-program, only a single path through the micro-program is exercised, specified by the instruction being executed. However, all of the paths through the micro-program must be broadcast for the shared control unit (since a PE may require each path). At each PE, only the micro-instructions necessary for the local instruction are used. Thus, while the broadcast of all the paths is necessary for the PEs collectively to proceed, it is not necessary for the individual PE. Accordingly, it is possible to share micro-instructions among different branches in the micro-program. Littman and Metcalf (1988) describe the construction of the MILAN, a RISC-based software architecture targeted for concurrent interpretation. The MILAN interpreter is constructed using assembly language on the TMC CM-2 SIMD machine. Furthermore, the interpreter is hand-optimized to maximize the overlap among the micro-instructions. Similarly, in implementing an interpreter for the MIPS RS-3000 RISC instruction set, Wilsey et al. (1992) describe how the overlap of execution of the micro-instructions is successful in reducing the number of interpreted regions (Abu-Ghazaleh et al., 1993). Wilsey et al. (1992) also suggest a “generic” memory cycle, where the load/store memory cycle is overlapped with the fetch memory cycle (this example overlaps micro-instructions across two CCA cycles). Hand-optimizing the overlap among the micro-instructions is a difficult and time-consuming task for non-trivial instruction sets. Dietz (1992) suggests using the Common Subexpression Induction (CSI) optimization

*’

This is the reason why this organization is used by the P-kernel system (the P-kernel is invoked after every process execution), where the granularity of the execution time exceeds the scheduling overhead.

MANAGING CONTROL ASYNCHRONY ON SlMD MACHINES-A

SURVEY

287

(described in section 3.2) to optimize the overlap between the micro-instructions (Dietz and Cohen, 1992a). CSI is an optimization that produces minimal-superset sequences for multiple-control branches. A minimalsuperset sequence implies maximal overlap between the control branches, and good sharing of the micro-instructions. Wang (1994) used CSI for automatically generated, optimized sub-interpreters (section 5.5.3). Hudak and Mohr, (1988) and Bagley et al. (1994) use a dual approach to maximize micro-instruction overlap. They suggest the use of an instruction set that composes its instructions by successive application of lower-level functions. The basic interpreter consists of a set of basic functions chosen such that they compose to build several higher-level instructions in a single cycle. An instruction can take part in any of the functional blocks to compose its instruction, resulting in unforced sharing of the micro-instructions (functional blocks). Figure 16 demonstrates composition of operations, by synthesizing three useful operations from two functional blocks. Bagley et al. (1994) present the Compose software architecture and show how a set of nine simple functional blocks can be combined to realize more than 50 useful instructions. Similarly, Hudak and Mohr (1988) use a set of five basic graph-manipulation operations to synthesize nine graph-reduction operations in a single cycle for combinator reduction.

5.5.3 Variable Instruction Issue Interpreters Another optimization to the CCA structure considers issuing a variable set of the instructions, instead of all the instructions, in each cycle. By issuing only the most frequent, least costly operations, the effective length of the CCA is reduced. More precisely, delaying the issue of a particular expensive or rare instruction results in two positive effects: (1) the cycle time for the iterations where this instruction is not issued is shortened, resulting in a smaller average cycle (while delaying only a few PEs), and (2) the number of PEs requiring the infrequent instruction increases when the instruction is unissued, as new PEs encounter that instruction in their instruction streams. This “alignment” of the PEs is profitable, because by the time the instruction is finally issued a larger number of PEs takes if (Opcode == Subtract 1 ) Opcode Operandl = -0perandl;

==

Negate)

if (Opcode == Subtract 1 1 Opcode == Add) Operandl = Operandl + Operand2; FIG. 16.

Synthesis of three instructions out of two functional blocks by Composition.

288

NAEL 6. ABU-GHAZALEH AND PHILIP A. WILSEY

advantage of it. The problem of optimizing the issue of the instructions using variable schedules is called the variable instruction-issue problem. Collins (1988) considers a restricted form of the variable instruction issue problem: the case of one expensive, infrequent instruction in an otherwise equal (short) length, equal (high) probability instruction set. Collins derives an expression for the number of cycles that the expensive instruction should be delayed for optimal system throughput. Dietz uses frequency biasing of “groups” of instructions (sub-emulators) according to their probability of occurrence. This biasing does not take into account the costs of the groups of instructions, but only the frequency of occurrence relative to other instructions (Dietz and Cohen, 1992a). Moreover, Dietz also investigates the use of global-or instructions to probe whether each instruction is needed by at least one PE. When such an instruction is found, the execution region for it is skipped. When the programs on the PEs diverge quickly, the overhead for executing the global-ors and accessing the jump-table increases the cycle time while getting rewarded with little or no gain (Collins, 1988; Wilsey et al., 1992). The global-or optimization benefits from keeping the threads aligned (by inserting barriers after asynchronous regions in the application, for example (Collins, 1988)). The general variable instruction-issue problem is addressed by AbuGhazaleh et al. (1997). They build a stochastic model for a concurrent-interpretation system and define objective functions in terms of the system parameters. It is shown that for two objective functions, system throughput and PE utilization ratio, the optimization problem is NP-complete (Fan et al., 1995). Therefore, heuristics are constructed to optimize the instruction issue schedule; yielding significant performance gains on a variety of instruction set profiles. Abu-Ghazaleh et al. also study variable instructionscheduling with respect to compositional instruction sets. They discover that, if the utilization of the functional blocks in the compositional instruction set is high, variable instruction issue is not useful (Abu-Ghazaleh and Wilsey, 1997b). In another study, they extend variable instruction-issue analysis to account for the existence of multiple concurrent engines on the SIMD PE and balance the operation of these engines (Abu-Ghazaleh and Wilsey, 1997b).

5.5.4

Matching the Interpretation Environment to the Host Machine

It is imperative that the interpreter design accounts for the capabilities of the underlying host SIMD machine. Typical SIMD machines have multiple PEs residing on each chip, sharing resources such as the memory bus. Instructions that utilize shared resources, including memory access opera-

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

289

tions, are significantly more expensive than register-bound instructions (MasPar, 1991b). However, SIMD machines lack one of the main features necessary for utilizing the register set for efficient interpretation: register indirection. Register indirection is the ability to address a register specified as a value of another register. This is a necessary feature for interpreting instructions with register operands; the instruction register must be able to specify the register operands. Without register indirection, instructions must access memory for their operands. There were a number of approaches taken to address this problem: (1) Using a stack-based architecture with the topmost element cached into a register (Dietz and Cohen, 1992b). The instructions implicitly use the topmost element, and register-bound operation is achieved. Note that the next element in the stack will likely be needed by some processor, as the top of its cache is consumed; forcing a memory access to cache that element in. Caching in more than one element leads to expensive cache-manipulation operations to update the stack. (2) Both Littman and Wilsey study a less restrictive load-store software, with the register set mapped into memory (Littman and Metcalf, 1988; Wilsey et al., 1992). Mapping the register set into memory allows using memory indirection to specify general register operands. Unfortunately, no advantage in the access time is achieved when using register operations because the registers reside in memory. However, the register space is smaller than the memory space; allowing the instruction to specify multiple register operands in a single word. One of the features of the MasPar MP-l/MP-2 machines is the ability to execute non-conflicting memory and ALU-bound operations concurrently. By careful structuring of the interpreter it is possible to hide the cost of the execution of some operations behind the costs of the memory accesses. In order to facilitate this concurrency, Wilsey et al. (1992) use a softwarepipelining technique where the fetch of the next instruction is initiated concurrently with the execution of the current instruction. Thus, by the time the current instruction finishes execution, the next instruction has been fetched and is ready to proceed. Pipeline hazards are avoided by using a delayedbranch software architecture (Hayes, 1988; Kane, 1987). It is also important to ensure that the SIMD compiler produces efficient code when compiling the CCA. Dietz uses post-processing to remove redundant checks and type-conversions inserted by the MasPar MPL (MasPar, 1991c) compiler (Dietz and Cohen, 1992a). Many of the interpretation

290

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

models are implemented directly in assembly language to avoid the inefficiencies of the compilers and take advantage of the machine characteristics (Abu-Ghazaleh et al., 1993; Collins, 1988; Hollinden et al., 1992; Littman and Metcalf, 1988; Wilsey et al., 1992). For example, it is often possible to simplify masking operations by using (efficient) single bit moves, and reusing temporary values kept in registers (Abu-Ghazaleh et al., 1993). 5.6 Shared Control Multiprocessors Despite the optimizations to the CCA, the cycle time remains two orders of magnitude slower than the SIMD integer instructions. This performance has caused the interpretation approach to be viewed as an impractical curiosity. The study of the models of interpretation discussed in the previous section made it possible to isolate the reasons for the inefficiency in execution (Abu-Ghazaleh et al., 1993; Dietz and Cohen, 1992a; Wilsey et al., 1992). These reasons are listed below. 0

0

0

Interpretation v. direct execution: Under SIMD operation, instructions are implemented by broadcasting the control signals directly to the PEs. Interpretation, on the other hand, must go through a progression of SIMD instructions to serially achieve this control. Each of these instructions must be fetched, decoded, and executed. In addition, on micro-programmed machines, horizontal micro-encoding schemes are often used to enhance the performance by concurrently executing independent micro-operations (Fisher, 1981). This is not possible using interpretation. In order to alleviate this problem, the control unit must be given direct control over the PEs. Moving from interpretation to direct execution does not involve any hardware changes; it merely requires that a different set of control patterns be broadcast to the PEs. Contentionfor control unit use: The branches in the branching regions of the interpreter program contend for the use of the control unit. The problem is minimized using: (1) a carefully designed micro-program, based on a compositional instruction set, and (2) additional control units that are assigned to major branches in the micro-program, implementing the interpreter program in parallel (Abu-Ghazaleh and Wilsey, 1996). Overhead for managing the activity status: Within the single cycle of the interpreter, multiple changes in the active sets of PEs occur. Changing the activity status is an expensive operation at this granularity. The activity management cost can be eliminated completely using a simple hardware mechanism (Abu-Ghazaleh, 1997).

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

0

SURVEY 291

Lack of hardware support for interpretation: The concurrent-interpretation paradigm is fundamentally different from the traditional SIMD programming model. The architecture of the PEs on existing SIMD machines provides features that facilitate efficient execution of the data parallel model. A number of instruction set features required by the interpretation paradigm are not supported by the native SIMD instruction set and architecture. One such feature is adding autonomy to some of the similar mutually exclusive operations. For example, instead of broadcasting n conditional branching instructions sequentially, only one generic cycle is broadcast, with the required condition specified locally in the instruction word. This addition can be considered another level of autonomy, execution autonomy. Another feature is the register indirection addressing mode, discussed earlier in this section.

These solutions are incorporated into the design of a shared control multiprocessor (Abu-Ghazaleh and Wilsey, 1998b). With the control unit directly controlling the PEs in the “interpretation” mode, the control unit truly becomes a shared micro-programmed control unit. Moreover, the major paths of control are assigned to different control units for concurrent interpretation. Figure 17 shows a fully decoupled organization; each

unit

Memory

FIG. 17. Overview of a shared control organization.

292

NAEL 6. ABU-GHAZALEH AND PHILIP A. WILSEY

instruction is assigned a control unit. There are several models for synchronizing the control units when the micro-code segments assigned to each have varying lengths (Abu-Ghazaleh and Wilsey, 1998a). Activity control and signal multiplexing can be supported using simple hardware additions (at no cost to the execution cycle) (Abu-Ghazaleh and Wilsey, 1998b). The additional features for supporting interpretation increase the PE area by less than lo%, but result in better than an order of magnitude technologyindependent improvement in the interpreter cycle time. At the PEs, the signals from all the control units are received, with each PE choosing the signals from the control units corresponding to the operation it currently requires (instruction or system function). The PEs under this architecture are capable of sequencing their own control threads locally. Since the control units are aligned to a fundamental cycle boundary, the control parallelism is supported via this model synchronously. The synchronous behavior allows several simplifications to the system hardware, especially the arbitration and conflict resolution. There is a tradeoff between the number of control units and the complexity of the control broadcast network (as well as the pin requirements for the control delivery). It is desirable to minimize the number of control units. Abu-Ghazaleh and Wilsey (1998b) propose that only groups of capabilities corresponding to distinct groups of capabilities be awarded separate control units. The problem of minimizing the conflicts among the functions assigned to the same control unit is the same problem solved by the concurrent-interpretation model: the same optimizations (composing instructions, sharing micro-instructions, execution autonomy and simple RISC-like design and encoding) are applicable. From an architecture perspective, the shared-control model resembles that of globally partitionable MSIMD machines. The machine has a number of control units, with each PE receiving control from only one. It is different from MSIMD machines in that the control units are associated with system functions, and not threads. The PEs locally determine which control unit to receive control from. In addition, the relationship between the control units is fixed, and they can be statically synchronized to insure that no conflicts occur between them. More precisely, if the control units have micro-code sequences of varying length, it becomes necessary to synchronize them to allow the PEs to switch among them safely (Abu-Ghazaleh and Wilsey, 1998a). The similarity of the underlying centralized control organization to SIMD/MSIMD models makes it possible to support those modes of operation at little additional cost. SIMD/MSIMD are superior models for synchronous, massively-parallel applications. This leads to an architecture that operates efficiently on both synchronous and asynchronous applications.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

293

6. Concluding Remarks The SIMD model is well suited to synchronous, massively-parallel computation both from the architecture and algorithm perspectives. Unfortunately, SIMD machines are unable to support control parallelism efficiently; this is a problem known as the SIMD overhead. This problem forces the use of MIMD machines for supporting general applications. However, MIMD machines are inefficient on finely synchronized applications and are significantly more expensive than SIMD machines. Accordingly, there is considerable interest in introducing facilities for managing control parallelism to otherwise SIMD environments. This paper surveys the approaches to the problem of managing control parallelism on SIMD machines. There are a number of unique strategies for solving this problem. The different strategies are outlined, with emphasis on the hardware cost, benefits, and restrictions of each model. Newer SIMD machines incorporate some flexibility in the control organization. Autonomous operation has been added to many important PE functions, allowing the PEs to modify the broadcast operation locally (usually by specifying a local address). Autonomy in memory access is a particularly important feature that extends the range of SIMD machines to some important problems (in fact, autonomous memory access is a critical capability for concurrent interpretation). These modifications are relatively inexpensive. In conjunction with efforts to develop hardware extensions to the restricted control organization, there are efforts at the software level. Some of these optimizations capitalize on the autonomy features to improve existing algorithms. Others explore compiler optimizations that relax some of the control-flow restrictions within high-level SIMD programming-language constructs. One of the promising compiler optimizations maximizes the overlap in the execution of branching regions, allowing this execution to proceed concurrently. The extensions to the SIMD paradigm are only partially successful in solving the SIMD overhead problem. The cause of the SIMD overhead is inherent to the SIMD model: how can different threads proceed concurrently using one control unit? Some architectures alleviate this basic bottleneck by enriching the SIMD control organization beyond the single control-unit model. Two main approaches are identified: the MultipleSIMD model, and architectures with hardware synchronization mechanisms that can be used to realize less rigid, synchronous models. Multiple SIMD machines introduce control parallelism into the SIMD model by having a small number of control units, from which the SIMD PEs can receive control. A defining feature that affects many characteristics of this model is the control broadcast network, and the nature of the assignment of the

294

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

control units to the PEs. We study several control broadcast strategies, including static assignment, limited dynamic assignment, and globally partitionable networks. The other approach, strongly synchronized machines, attempts to divorce the data-parallel model from SIMD hardware restrictions. The proponents of this approach view the problem of mapping parallel algorithms to either the SIMD or MIMD models in terms of matching the synchronization needs of the algorithms. Neither SIMD nor MIMD match the synchronization needs-SIMD being over-synchronized and MIMD under-synchronized. Several architectures employing different synchronization models are presented, including the SPMD model, the Virtual-Time Data-Parallel machine, and hardware-barrier machines. Finally, the concurrent-interpretation model for programming SIMD machines is considered. Concurrent interpretation supports control parallelism by sharing the control unit at a lower level-the atomic function level. By realizing that the threads are made up of sequences chosen from a common set of functions, the control unit can be shared at the function level. If all the functions in the interpreted set are issued in a cycle, the threads on the PEs are all advanced by one function. Sharing the control unit at the function level is more successful than sharing it at the thread level for the following reasons: (1) the sharing is decoupled from the nature of the application, offering scalable performance regardless of the control structure of the application, and (2) since the functions are fixed, the system can be optimized towards them. The parameters of the interpretation model, and everal optimizations to it, are discussed. By sharing control at the functional level, the control unit acts as a shared micro-programmed control unit that concurrently serves all the instructions in the instruction set. The shared-control multiprocessor model emerged to solve the inefficiency of concurrent interpretation. For example, it is possible to obtain much higher performance by giving the control unit direct control over the PEs, instead of forcing it to go through several SIMD instructions to realize each interpreted function. Moreover, because the different functions contend for the use of the control unit (in much the same way that the threads contend for the use of the control unit in the data parallel mode), shared-control assigns a control unit to every major branch in the shared micro-code. Implementing the features necessary for shared-control increased the PE area by less than 10% (Abu-Ghazaleh, 1997). A sharedcontrol architecture is capable of supporting control parallelism synchronously. Moreover, the similarity in the underlying hardware allows supporting thread-based sharing (and SIMD operation) at little additional cost.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

295

ACKNOWLEDGMENTS The authors would like to thank Herb Hirsch, Perry Alexander, Dinesh Bhatia, Tom Dichiaro, and the anonymous reviewers for their comments on earlier versions of this paper. The paper was considerably improved by their comments and suggestions.

REFERENCES Abu-Ghazaleh, N. B., and Wilsey, P. A. (1996). Shared control multiprocessors. Proceedings of the 2nd International Conference on Massively Parallel Computing Systems, Ischia, Italy, May, pp. 347-352. Abu-Ghazaleh, N. B., and Wilsey, P. A. (1997a). On the structure of concurrent interpreters. International Journal of High-speed Computing, (submitted). Abu-Ghazaleh, N. B., and Wilsey, P. A. (1997b). Variable instruction scheduling for MIMD interpretation on pipelined SIMD machines and for compositional instruction sets. Concurrency: Practice and Experience, 9( l), 21 -39, January. Abu-Ghazaleh, N. B., and Wilsey, P. A. (1998a). Models for the synchronization of control units on shared control architectures. Journal of Parallel and Distributed Computing, (in press). Abu-Ghazaleh, N. B., and Wilsey, P. A. (1998b). Shared control architectures: Supporting control-parallelism on SIMD-like architectures. Proceedings of the 4th European Parallel Processing Conference (EuroPar '98), Southampton, UK, September. Abu-Ghazaleh, N. B., Dichiaro, T., Wilsey, P. A,, Hensgen, D. A., and Cahay, M. M. (1993). Parallel Execution of Monte Carlo Simulations on SIMD Processors. Technical Report TR 146-2-93-ECE, Department of ECE, University of Cincinnati, Cincinnati, OH, February. Abu-Ghazaleh, N. B., Wilsey, P. A,, Fan, X., and Hensgen, D. A. (1997). Synthesizing variable instruction issue interpreters for implementing functional parallelism on SIMD computers. IEEE Transactions on Parallel and Distributed Systems, April. Abu-Ghazaleh, N. B. (1997). Shared Control Multiprocessors: A Paradigm for Supporting Control Parallelism on SIMD-like Architectures. PhD thesis, University of Cincinnati. Adaptive Solutions (1996). Adaptive Solutions Home Page. http: //www. asi. corn. Agarwal, A., Simoni, R., Hennessy, J., and Horowitz, M. (1988). An evaluation of directory schemes for cache coherence. Proceedings of the 15th International Symposium on Computer Architecture, May, pp. 280-289. Aganval, A., Bianchini, R., Chaiken, D., Johnson, K. L., Kranz, D., Kubiatowicz, J., Lim, B-H., Mackenzie, K., and Yeung, D. (1995). The MIT Alewife machine: Architecture and performance. Proceedings of the 22nd International Symposium on Computer Architecture, June, pp. 2- 13. Albanesi, M., Cantoni, V., Cei, U., Ferritti, M., and Mosconi, M. (1991). Embedding pyramids into mesh arrays. In Reconfigurable Massively Parallel Computers, (H. Li and Q. Stout eds.), Prentice Hall, Englewood Cliffs, NJ, pp. 123-140. Allen, J., and Schimmel, D. (1995a). The impact of pipelining on SIMD architectures. Proceedings of the 9th International Parallel Processing Symposium, IEEE Computer Society Press, April, pp. 380-387. Allen, J., and Schimmel, D. (1995b). On Synchronous Data Parallel Caches. Technical Report TR-GIT/CSRL-94/06, Electrical Engineering Dept., Georgia Institute of Technology, Atlanta, GA.

296

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

Allen, J., Garg, V., and Schimmel, D. (1993). Analysis of control parallelism in SIMD instruction streams. Proceedings of the 5th IEEE Syniposium on Parallel and Distributed Processing, IEEE Computer Society Press, December, pp. 383-390. Almasi, 0.. and Gottlieb, A. (1989). Highly Parallel Computing. Benjami/Cummings Publishing Company, Inc., Redwood City, CA. Auguin, M. (1986). OPSILA computer. Proceedings of the International Workshop on Algorithms and Architecture, North Holland Press, pp. 143- 153. Axelrod, T. S. ( I 986). Effects of synchronization barriers on multiprocessor performance. Parallel Computing, pp. 129-140. Bagley, R. A., Wilsey, P. A., and Abu-Ghazaleh, N. B. (1994). Composing functional unit blocks for efficient interpretation of MIMD code sequences on SIMD processors. In Parallel Processing: CONPAR 94 - VAPP VI, (B. Buchberger and 3. Volkert eds.), Lecture Notes in Computer Science, 854,616-627. Springer-Verlag, September. Baglietto, P., Maresca, M., and Migliardi, M. (1994). Introducing execution autonomy in the SIMD computing paradigm. International Conference on Massively Parallel Processing Applications und Development. Elsevier. Barnes, G. H., Brown, R. M., Kato, M., Kuck, D. J., Slotnick, D. L., and Stokes, R. A. (1986). The ILLIAC-IV computer. IEEE Traiz.sar.tions on Computers, pp. 746-757. Blank, T. (1990). The MasPar MP-1 architecture. Proceedings of the 35th IEEE Computer Society International Conferewe, pp. 20-24. Blevins, D., Davis, E., Heaton, R., and Reif, J. (1990). BLITZEN: A highly integrated massively parallel machine. Journal of Parallel and Distributed Computing, 8(2), 150-160, February. Brandes, T. (1993). Compiling data parallel programs to message passing programs for massively parallel MJMD systems. Working Conference on Massively Parallel Programming Models: Suitabiliiy, Realization, and Performance, September. Bridges, T., Kitchel, S., and Wehrmeister, R. (1992). A CPU utilization limit for massively parallel MIMD computers. Proceedings of the 4th Synzposiunz on the Frontiers qf Massively Parallel Computation, October, pp. 83-92. Bridges, T. (1990). The GPA machine: A generally partitionable MSIMD architecture. Proceedings of the 3rd Symposium on the Frontiers of Massively Parallel Architectures, pp. 196-203. Cantoni, V., and Ferretti. M. (1994). Pyramidal Architectirres For Computer Vision. Plenum Publishing Corp., New York, NY. Cantoni, V., and Levialdi, S. (1983). Matching the task to an image processing architecture. Computer Vision, Graphics Image Processing, February, pp. 30 1-309. Cantoni, V., De Gesu, V., Ferretti, M., Levialdi, S., Negrini, R., and Stefanelli, R. (1991). The PAPIA system. Jourrial of VLSI Signal Processing, February, pp. 195-2 17. Carriero, N., and Gelernter, D. (1994). Case studies in asynchronous data parallelism. International Journal of Parallel Programming, 22(2), 129-149. Chandy, M., Manohar, R., Massingill, B., and Meiron, D. (1995). Integrating task and data parallelism with the collective communication archetype. 1995 International Parallel Processing Symposium. Chromatic Research Inc. (1996). Chromatic Research Home Page. http: / / wchro. matic. com.

Chung, M. J., and Chung, Y. (1989). Data parallel simulation using time-warp on the Connection Machine. Proc. 26th ACMIIEEE Design Automation Conference, pp. 98- 103. Cohen, W., Dietz, H., and Sponaugle, J. (1994a). Dynamic barrier architecture for multi-mode fine-grain parallelism using conventional processors; Part 11: Mode emulation. Technical Report TR-EE-94-10, Purdue University School of Electrical Engineering, March.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

297

Cohen, W., Dietz, H., and Sponaugle, J. (1994h). Dynamic harrier architecture for multi-mode fine-grain parallelism using conventional processors; Part I: Barrier architecture. Technical Report TR-EE-94-9, Purdue University School of Electrical Engineering, March. Collins, R. J. (1988). Multiple-instruction multiple-data emulation on the Connection Machine. Technical Report CSD-910004, Dept of Computer Science, University of California., Los Angeles, CA, February. Cray Research, Inc. (1993). Cray Research, Inc., Mendosa Heights, Minnesota. Cray T3D System Architecture Overview, September. Cvetanovic, Z. (1987). The effects of problem partitioning, allocation and granularity on the performance of multi-processor systems. IEEE Transactions on Computers, 36(4), 421-432. Cypher, R., and Sanz, J. (1994). The SIMD Model of Parallel Computation. Springer-Verlag, New York, NY. DeMillo, R. A., Lipton, R. J., and Sayward, F. G. (1978). Hints on test data selection: Help for the practicing programmer. Computer, 11(4), 34-41, April. Dhagat, M., Bagrodia, R., and Chandy, M. (1995). Integrating task and data parallelism in UC. Proceedings of the 1995 International Conference on Parallel Processing, (C. Polychronopoulos ed.), Vol. 11, Software, pp. 11-29-11-36, August. Dietz, H. G., and Cohen, W. E. (1992a). A control-parallel programming model implemented on SIMD hardware. Languages and Compilers for Parallel Computing, (U. Banerjee, D. Gelemter, A. Nicolau, and D. Padua eds.), Lecture Notes in Computer Science, 757, 31 1-325. Springer-Verlag, August. Dietz, H. G., and Cohen, W. E. (1992h). A massively parallel MIMD implemented by SIMD hardware. Technical Report TR-EE 92-4-P, School of Electrical Engineering, Purdue Universsity, West Lafayette, IN, January. Dietz, H. G., and Krishnamurthy, G. (1993). Meta-state conversion. 1993 International Conference on Parallel Processing, (A. N. Choudhary and P. B. Berra eds.), Vol. 11, Software, August pp. 47-56. Dietz, H. G., Muhammad, T., Sponaugle, J., and Mattox, T. (1994). PAPERS: Purdue’s adapter for parallel execution and rapid synchronization. Technical Report TR-EE94-11, School of Electrical Engineering, Purdue University, West Lafayette, IN, March. Dietz, H. G. (1992). Common subexpression induction. In 1992 International Conference on Parallel Processing, (K. G. Shin ed.), Vol. 11, Software, August pp. 174-182. Duff, M. (1983). Computing Structures for Image Processing. Academic Press, New York, NY. Von Eicken, T., Culler, D., Goldstien, S., and Schauser, K. (1992). Active messages: a mechanism for integrated communication and computation. Technical Report CSD-92-675, Computer Science Division, University of California, Berkeley, CA 94720, March. Ellis, J. (1985). Bulldog: A Compilerfor VLIWArchitectures. MIT Press, Cambridge, MA. Fan, X., Abu-Ghazaleh, N. B., and Wilsey, P. A. (1995). On the complexity of scheduling MIMD operations for SIMD interpretation. Journal of Parallel and Distributed Computing, 29(1), 91-95, August. Feldennan, R., and Kleinrock, L. (1990). An upper hound on the improvement of asynchronous versus synchronous distributed processing. Proceedings of the SCS Multiconference on Distributed Simulation, 22, 131- 136 January. Fisher, J. A. (1981). Trace scheduling: A technique for global microcode compaction. IEEE Transactions on Computers, 30(7), 478-490. Flynn, M. J. (1966). Very high speed computing systems. Proceedings ofthe IEEE, 54(12), 1901- 1909, December. Fountain, T. (1985). Plans for the CLIP7 chip. Integrated Technology for Parallel Image Processing, (S. Levaldi ed.), London, Academic Press, pp. 199-214.

298

NAEL 6. ABU-GHAZALEH AND PHILIP A. WILSEY

Fountain, T. (1987). Processor Arrays: Architecture and Applications. Academic Press, Orlando, FL. Fountain, T. (1 988). Introducing local autonomy to processor arrays. In Machine Vision: Algorithms, Architectures and Systems, (H. Freeman ed.), New York, NY, Academic Press, pp. 31-56. Fox, G., and Angus, I. (1990). Solving Problems on Concurrent Processors. Prentice Hall, Englewood Cliffs, NJ. Fox, G. (1989). What have we learnt from using real parallel machines to solve real problems? Technical Report C3P-522, Caltech Concurrent Computation Program, California Institute of Technology, Pasadena, CA 91 125, March. Fritsche, G. (1986). General purpose pyramidal systems. Pyramidal Systems for Computer Vision, (V. Cantoni and S. Levialdi eds.), Berlin, Springer-Verlag, pp. 40-57. Fujimoto, R. (1990). Parallel discrete event simulation. Communications of the ACM, 33( lo), 30-53, October. Garcia-Molina, H., Germano, F. Jr., and Kohler, W. H. (1984). Debugging a distributed computing system. IEEE Transactions on Sofiware Engineering, SE-10(2), 210-219, March. Garg, V., and Schimmel, D. (1995). Architectural support for inter-stream communication in a MSIMD system. Proceedings of the First IEEE Symposium on High Performance Computer Architecture. Gokhale, M., Holmes, B., and lobst, K. (1995). Processing in memory: The Terasys massively parallel PIM array. IEEE Computer, April, pp. 23-3 1. Goodman, J. (1983). Using cache memory to reduce processor-memory traffic. Proceedings of the 10th International Symposium on Computer Architecture, May, pp. 124-130. Greenberg, A., Lubachevsky, B., and Mitrani, I. (1996). Superfast parallel discrete event simulations. ACM Transactioris on Modeling and Computer Simulation, 6(2), 107-136, April. Gropp, W., Lusk, E., and Skjellum, A. (1994). Using MPI: A Message-Passing Interface Standard. MIT Press, Cambridge, MA. Gupta, R. (1989). The fuzzy barrier: A mechanism for high speed synchronization of processors. Proceedings of the International Conference for Arcitectural Support for Programming Languages and Operating Systems (ASPLOS-III),April, pp. 54-63. Hatcher, P. J., and Quinn, M. J. (1991). Data-Parallel Programming on MIMD Computers. The MIT Press, Cambridge, MA. Hayes, J. P. (1988). Computer Architecture and Organization. McGraw Hill, New York, NY. Hennesy, J. L., and Patterson, D. A. (1996). Computer Architecture a Quantitative Approach, 2nd edn. Morgan Kaufman Publishers Inc., San Mateo, CA. Hensgen, D., Finkel, R., and Manber, U. (1988). Two algorithms for barrier synchronization. International Jourual of Parallel Programming, February, pp. 1-16. Herbordt, M. C., and Weems, C. C. (1995). Experimental analysis of some SIMD array memory hierarchies. Proceedings of the 1995 International Conference on Parallel Processing, (P. Banerjee ed.), Vol. I, Architecture, August, pp. 1-210-1-214. Hill, M., Lams, J., Reinhardt, S., and Wood, D. (1993). Cooperative shared memory: Software and hardware for scalable multiprocessors. ACM Transactions on Computer Systems, November. Hillis, W. D., and Steele, G. L. Jr. (1986). Data parallel algorithms. Communications of the ACM, 29(12), 1170-1183, December. Hillis, W. D. (1985). The Connection Machine. The MIT Press, Cambridge, MA. Ho, C. (1991). Hypercube: A reconfigurable mesh. Reconfigurable Massively Parallel Coniputers, (H. Li and Q. Stout eds.), Englewood Cliffs, NJ, Prentice Hall, pp. 141-169. Hollinden, D. Y., Hensgen, D. A., and Wilsey, P. A. (1992). Experiences implementing the MINTABS system on a MasPar MP-I. Proceedings of the 3rd Symposium on Experiences with Distributed arid Multiprocessor systems (SEDMS Ill), March, pp. 43-58.

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

299

Hord, R. M. (1990). Parallel Supercomputing in SIMD Architectures. CRC Press, Boca Raton,

FL. Hord, R. M. (1993). Parallel Supercomputing in MIMD Architectures. CRC Press, Boca Raton, FL. Hudak, P., and Mohr, E. (1988). Graphinators and the duality of SIMD and MIMD. Proceedings of the I988 ACM Symposium on Lisp & Functional Programming. Hwang, K., and Briggs, F. A. (1984). Computer Architecture and Parallel Processing. McGraw-Hill, New York. ISATEC (1996). ZSATEC Home Page. http: //www.netzservice.de/Home/isatec. Jamieson, L., Cannon, D., and Douglass, R. (1987) The Characteristics of Parallel Algorithms. MIT Press, Cambridge, MA. Jefferson, D. (1985). Virtual time. ACM Transactions on Programming Languages and Systems, 7(3), 405-425, July. Johnson, M. (1991). Superscalar Microprocessor Design. Prentice Hall, Englewood Cliffs, NJ. Joyce, J., Lomow, G., Slind, K., and Unger, B. (1987). Monitoring distributed systems. ACM Transactions on Computer Systems, 5(2), 121-150, May. Kane, G. (1987). MIPS R2000 RISC Architecture. Prentice Hall, Englewood Cliffs, NJ. Kashara, H., Honda, H., Mogi, A., Ogura, A,, Fujiwara, K., and Narita, S. (1991). A multi-grain parallelizing compilation scheme for OSCAR (optimally scheduled advanced multiprocessor). Languages and Compilers for Parallel Computing, (U. Banerjee, D. Gelertner, A. Nicolau, and D. Padua eds.), New York, NY, Springer-Verlag, pp. 283-297. Kent, E., Shneier, M., and Lumia, R. (1985). PIPE: Pipeline image processing engine. Journal of Parallel and Distributed Computing, February, pp. 50-78. Kemighan, B. W., and Ritchie, D. M. (1978). The C Programming Language. Prentice Hall, Englewood Cliffs, NJ. Keryell, R., and Paris, N. (1993). Activity counter: New optimization for the dynamic scheduling of SIMD control flow. 1993 International Conference on Parallel Processing, 2, 184-187 August. Kim, W., and Tuck, R. (1993). MasPar MP-2 PE chip: A totally cool hot chip. IEEE 93 Hot Chips Symposium, May. Kitano, H., and Hendler, A. (1994). Massively Parallel ArtiJi:cial Intelligence. AAAI Press/MIT Press, Menlo Park, CA. Kohavi, Z . (1978). Switching and Finite Automata Theory. McGraw-Hill, New York, NY. Kranz, D., Lim, B-H., Agarwal, A,, and Yeung, D. (1994). Low-cost support for fine-grain synchronization in multiprocessors. Multithreaded Computer Architecture: A Summary of the State ofthe Art. Kluwer Academic Publishers. Kravitz, S. A., Bryant, R. E., and Rutenbar, R. A. (1989). Logic simulation on massively parallel architectures. Proceedings of the 16th Annual International Symposium on Computer Architecture, pp. 336-343. Kuskin, J., Ofelt, D., Heinrich, M., Heinlein, J., Simoni, R., Gharachorloo, K., Chapin, J., Nakahira, D., Baxter, J., Horowitz, M., Gupta, A,, Rosenblum, M., and Hennessy, J. (1994). The Stanford FLASH multiprocessor. Proceedings of the 21st International Symposium on Computer Architecture, pp. 302-3 13. Kuszmaul, B. C. (1986). Simulating Applicative Architectures on the Connection Machine. Master’s thesis, MIT, May. Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system. Communications of ACM, July, pp. 558-565. Lams, J. (1993). Compiling for shared-memory and message-passing computers. ACM Letters on Programming Languages and Systems, 2( 1-4), March-December.

300

NAEL B. ABU-GHAZALEH AND PHILIP A. WILSEY

Li, H., and Maresca, M. (1989). Polymorphic torus network. IEEE Transactions on Computers, 38(9), 1345-1351. Li, H., and Stout, Q. (190 1). Reconfigurable Massively Parallel Computers. Prentice Hall, Englewood Cliffs, NJ. Littman, M. S., and Metcalf, C. D. (1988). An exploration of asynchronous data-parallelism. Technical Report No. 684, Dept of Computer Science, Yale University. Lundstrom, S., and Barnes, G. (1980). A controllable MIMD architecture. Proceedings of the I980 International Corlference on Parallel Processing, pp. 19-27. Manning, S., and Meyer, D. (1993). Analysis of asyncronous execution streams with I-caching in massively parallel systems. Journal of Parallel and Distributed Computing, pp. 279-291. Maresca, M., and Li, H. (1989). Connection autonomy in SIMD computers: A VLSI implementation. Journal of Parallel and Distributed Computing, 7, 302-320. Maresca, M., Lavin, M., and Li, H. (1988). Parallel architectures for vision. Proceedings of the IEEE, 76,970-981, August. MasPar (19914. MasPar Assembly Language (MPAS) Reference Manual, July, MasPar Computer Corporation, Sunnyvale, CA. MasPar (I99 1b). MusPar MP-1 Architecture Specification, March, MasPar Computer Corporation, Sunnyvale, CA. MasPar (1991~).MasPar Parallel Application Language (MPL), March, MasPar Computer Corporation, Sunnyvale, CA. Software Version 2.0, Document Part Number: 9302-0100. Mellor-Crummey, J. W., and Scott, M. L. (1991). Algorithms for scalable synchronization on shared multiprocessors. ACM Transactions oti Computer Systems, February. Merigot, A., Clermont, P., Mahat, J., Devos, F., and Zavidovique, B. (1986). A pyramidal system for image processing. In Pyramidal Systenis for Computer Vision, (V. Cantoni and S . Levialdi eds.), Berlin, Springer-Verlag, pp. 109-124. Miller, R., Kumar, V., Reisis, D., and Stout, Q. (1988). Image computations on reconfigurable VLSI arrays. Proceedings of Conference on Computer Vision and Inzage Recognition. Misra, J. (1986). Distributed discrete-event simulation. Computing Surveys, 18(1), 39-65, March. Nation, W. G., Maciejewski, A. A,, and Siegel, H. J. (1993). A methodology for exploiting concurrency among independent tasks in partitionable parallel processing systems. Journal of Parallel and Distributed Computing, pp. 27 1-278. Newman, I., and Schuster, A. (1995). Hot-potato algorithms for permutation routing. IEEE Transactions on Parallel and Distributed Systems, 6, 1168-1 176, November. Nichols, M. A., Siegel, H. J., and Dietz, H. G. (1993). Data management and control-flow aspects of an SIMD/SPMD parallel language/compiler. IEEE Transactions on Parallel and Distributed Systems, February, pp. 222-234. Nickolls, J. (1990). The design of the MasPar MP-1. Proceedings of the 35th IEEE Coniputer Society Znternational Conference, pp. 25-28. Nilsson, M., and Tanaka, H. (1988a). Massively parallel implementation of flat GHC on the connection machine. Proceedings of the Iizternatiorial Conference on Fifth Generation Computer Systems, pp. 1031- 1039. Nilsson, M., and Tanaka, H. (1988b). MIMD execution by SIMD computers. Journal of Information Processing, 13(I ) , 58-61. Nowatzyk, A. G., and Prucnal, P. R. (1995). Are crossbars really dead? The case for optical multiprocessor interconnect systems. Proceedings of the 22114’ Annual lnternational Syinposium on Computer Architecture, June pp. 106-1 15. Nudd, G., Kerbyson, D., Atherton, T., Francis, N., Packwood, R., and Vaudin, G. (1992). A massively parallel heterogeneous VLSI architecture for MSIMD processing. Algorithms

MANAGING CONTROL ASYNCHRONY ON SIMD MACHINES-A

SURVEY

301

and Parallel VLSI Architectures, (F. Deprettere and A. Van der Ven eds.), Amsterdam, Elsevier, pp. 463-472. Oxford Micro Devices Inc. (1996). Oxford Micro Devices Home Page. http://www.oxfordcomputer.com. Parhami, B. (1995). SIMD machines: Do they have a significant future'? Computer Architecture News, September, pp. 19-22. Parkinson, D., and Litt, J. (eds.) (1990). Massively Parallel Computing with the DAP. The MIT Press, Cambridge, MA. Pfister, G. (1998). In Search of Clusters: The Ongoing Battle in Lowly Parallel Computing. Prentice Hall, Upper Saddle River, NJ, 2nd edn. Philippsen, M., Warschko, T., Tichy, W., and Herter, C. (1993). Projet Triton: Towards improved programmability of parallel machines. Proceedings of 26th Hawaii International Conference on System Sciences, 1, 192-201 January. Prins, J., and Smith, J. (1990). Parallel sorting of large arrays on the MasPar MP-1. Proceedings of the 3rd Symposium on the Frontiers of Massively Parallel Architectures, pp. 59-64. Rockoff, T. (1994). SIMD instruction caches. Proceedings of rhe Symposium on Parallel Architectures and Algorithms '94, May, pp. 67-75. Rodrique, G., Giroux, E. D., and Pratt, M. (1980). Perspectives on large-scale scientific computation. IEEE Computer, 13(lo), 65-80, October. Sanders, P. (1994). Emulating MIMD behavior on SIMD machines. International Conference on Massively Parallel Processing Applications and Development. Elsevier. Schaefer, D., Ho, P., Boyd, J., and Vallejos, C. (1987). The GAM pyramid. Parallel Computer Vision, (L. Uhr ed.), Orlando, FL, Academic Press, pp. 15-24. Schimmel, D. E. (1992). Superscalar SIMD architecture. Proceedings of the 4th Symposium on the Frontiers of Massively Parallel Computation, October pp. 573-576. Sejnowski, M., Upchurch, E., Kapur, R., Charlu, D., and Lipovski, G . (1980). An overview of the texas reconfigurable array computer. Proceedings of the AFIPS National Computing Conference, June, pp. 63 1-641. Shen, S., and Kleinrock, L. (1992). The virtual-time data-parallel machine. Proceedings of the 4th Symposium on the Frontiers of Massively Parallel Computation, October, pp. 46-53. Shen, S. (1991). The Virtual-Time Data-Parallel Machine. PhD thesis, Dept of Computer Science, UCLA, Los Angeles, CA. Shu, D., and Nash, J. (1988). The gated interconnection network for dynamic programming. In Concurrent Computation, (S. Tewsburg ed.), Plenum, New York, NY. Shu, W., and Wu, M-Y. (1993). Solving dynamic and irregular problems on SIMD architectures with runtime support. 1993 International Conference on Parallel Processing. Shu, W., and Wu, M-Y. (1995). Asynchronous problems on SIMD parallel computers. IEEE Transactions on Parallel and Distributed Systems, 6(7), 704-713, July. Siegel, H. J., Schwederski, T., Kuehn, T. J., and Davis, N. J. (1987). An overview of the PASM parallel processing system. In Computer Architecture, (H. J. Siegel D. D. Gajski, V. M. Milutinovic and B. P. Furht eds.), Washington, DC, IEEE Press. Siegel, H. J. (1977a). Analysis techniques for SIMD machine interconnection network and the effects of processor address masks. IEEE Trans. on Computers, C-26, 153-161, February. Siegel, H. J. (1977b). Controlling the active/inactive status of SIMD machine processors. Proceedings of the 1977 International Conference on Parallel Processing, August, p. 183. Siegel, H. J. (1984). Interconnection Networks for Large-Scale Parallel Processing: Theory and Case Study. Lexington Books, Lexington, MA. Simmons, M., Wassseman, H., Lubeck, O., Eoyang, C., Mendez, R., Harada, H., and Ishiguro, M. (1992). A performance comparison of four supercomputers. Communications of the ACM, 35(8), 116-125, August.

302

NAEL 6.ABU-GHAZALEH AND PHILIP A. WILSEY

Slotnick, D., Brock, W., and MacReynolds, R. (1962). The SOLOMON computer. Proceedings of AFIPS Fall Computer Conference, pp. 87-107. Snyder, L., Jamieson, L. H., Gannon, D. B., and Siegel, H. J. (1985). Algorirhmically Specialized Parallel Computers. Academic Press, New York, NY. Tanimoto, S., Ligocki, T., and Ling, R. (1987). A prototype pyramid machine for hierarchical cellular logic. In Parallel Computer Vision, (L. Uhr ed.), Orlando, FL,Academic Press, pp. 43-83. Thinking Machines Corporation (199 1). The Connection Machine CM-5 Technical Summary, October, Thinking Machines Corporation, Cambridge, MA. Tomboulian, S . , and Pappas, M. (1990). Indirect addressing and load balancing for faster solution to the Mandelbrot set on SIMD architectures. Proceedings of the 3rd Symposium on the Frontiers of Massively Parallel Architecutres, pp. 443-450. Turner, D. A. (1979). A new implementation technique for applicative languages. SoftwarePractice and Experience, 9, 31-49. Uhr, L. (1982). Computer Arrays and Networks: Algorithm Structured Parallel Architectures. Academic Press, New York, NY. Unger, S. (1958). A computer oriented towards spatial problems. Proceedings of IRE, pp. 1744-1750. von Hanxleden, R., and Kennedy, K. (1992). Relaxing SIMD control flow constraints using loop transformations. Proceedings of the SIGPLAN '92 Conference on Programming Language Design and Implementation, SIGPLAN Notices, 27(7), July. Wang, J. (1994). Executing MIMD Programs on SIMD Machines. PhD thesis, Purdue University, May. Weems, C., Riseman, E., and Hanson, A (1992). Image understanding architecture: Exploiting potential parallelism in machine vision. Computer, February, pp. 65-68. Willebeek-LeMair, M., and Reeves, A. (1990). Solving nonuniform problems on SIMD computers: Case study on region growing. Journal of Parallel and Distributed Computing, 8, 135-149. Wilsey, P. A,, Hensgen, D. A., Abu-Ghazaleh, N. B., Slusher, C. E., and Hollinden, D. Y. ( 1992). The concurrent execution of non-communicating programs on SIMD processors. Proceedings of the 4th Symposium on the Frontiers of Massively Parallel Computation, October, pp. 29-36. Wolfe, A., and Shen, J. (1990). A variable instruction stream extension to the VLIW architecture. ASPLOS-IV Proceedings, pp. 2-14. Zhou, F., Kelliher, T., Owens, R., and Irwin, M. (1995). Introducing MGAP-2. Proceedings of the Frontiers of Massively Parallel Computation '95, pp. 281-288.

A Taxonomy of Distributed Real-time Control Systems J. R. AGRE, L. P. CLARE AND S. SASTRY Rockwell Science Center 7049 Camino Dos Rios PO Box 7085 Thousand Oaks, CA 97358 USA jragre@rsc. rockwell.com

Abstract The demands placed on industrial automation systems have grown in many dimensions over the last two decades. Examples of such demands are increased size, functionality, speed, flexibility, simpler programming, quality, and decreased installation and commissioning costs. An emerging approach to meeting such demands is the use of Distributed Real-time Control System (DRCS) architectures and technologies. This chapter discusses key issues that are driving this trend in modern industrial automation systems and provides a framework for discussion and technological research.

.....................

1 . Introduction . . .

............................... ...................

6. Conclusions . . . . . . . . . .

....... .....................................

References . . . . . . . . . . . . . . . . AppendixA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVANCES IN COMPUTERS, VOL. 49 ISBN 0-12-012149-2

318

.............

4.3 Communications

4.5 Man Machine Interface 5. Benefits and Limitations of a

304

303

341 343

348

Copyright 01999 by Academic Press All rights of reproduction in a n y form reserved.

304

J. R. AGRE ETAL.

1. Introduction A Distributed Real-time Control System (DRCS 132) is a control system in which one or more of its primary operations (such as sensor/actuator 10)are accomplished using communication facilities. This is a broader definition of “distributed control system” as it includes any dispersed system whether or not multiple processors are used for the control, but reflects common terminology in the industrial automation domain (primarily continuous manufacturing). Nevertheless, we will focus on technologies employing multi-processor architectures that have evolved in products over the last twenty years and are the subject of ongoing research. The “real-time” consideration emphasizes the requirement that the control system responds to sensor inputs with control actions within bounded time delays. Synchronous techniques, such as periodic I 0 scanning, have been used in traditional control systems in order to provide predictable response times. More sophisticated techniques from real-time systems theory are beginning to be adopted in industrial control. In practice, real-time control of distributed systems remains a challenging design problem. The remainder of this chapter is organized as follows. General and emerging technology trends that impact the evolution of DRCS are presented in section 2. Section 3 presents a simple classification scheme, called the IOC Taxonomy, which is useful for quick studies and high-level trade-off analyses. This taxonomy is used to briefly discuss the history of control system architectures. Section 4 presents a more detailed classification scheme, called the DRCS Taxonomy, which highlights the architectural options that system designers must consider while designing a DRCS. Section 5 discusses the benefits and limitations of DRCS and section 6 presents the conclusions. The Appendix demonstrates how the DRCS Taxonomy can be used to characterize different kinds of existing and proposed systems.

2. Trends Affecting Control System Architectures There are a number of ongoing trends in technology, business, and eco-

’

In the control system industry, the acronym DCS (Distributed Control System) is almost always used only in the context of process control applications (e.g. see [8]). We use the acronym DRCS to emphasize that these techniques are relevant for process, batch, and discrete industrial automation applications. ’Throughout this chapter, we use the acronym DRCS to refer to both a single system (e.g. “a DRCS,” “the DRCS”) and a family of systems (e.g. “for DRCS”). The exact sense must be gathered from the context.

A TAXONOMY OF DRCS

305

nomics that impact the nature of future control systems. For example, control systems architectures benefit from the general technology trends in the computing industry such as greater siliconization and increased digitization. In addition, the cost, complexity, and robustness requirements of control systems impact the way in which these systems are designed, commissioned, and operated. Control systems architectures also derive benefits from ongoing research in areas such as distributed real-time operating systems, architectures that enable autoconfiguration, autonomous systems, fault tolerance, diagnostics, automatic programming and open systems architectures. Technology trends (in computing) that motivate decentralization are discussed; some of these are widely supported in the community and others are the opinions of the authors. Probable consequences of these trends in the DRCS context are also discussed.

2.1

General Technology Trends Impacting DRCS

In our view of the future, a DRCS will be built using a large number of intelligent devices that are capable of performing the various control system functions locally. We believe that the availability of inexpensive, intelligent devices is necessary to proliferate the technology into common industrial applications. Given this scenario, advances will be necessary to coordinate these components.

2.1. I

Moore’s Law

Computational hardware performance doubles, for about the same cost, every two years. Moore’s Law applies only to hardware computational power and not necessarily to software; it is well known that software advances have been far short of the corresponding advances in hardware. The availability of low-cost, high performance hardware devices facilitates effective distribution of computation and control. The availability of increased computational power is largely due to the advances being made in the mass production of microprocessors, primarily for personal computers. Thus, while at one time it may have been cost-effective to optimize hardware resources, the current trend is to favor sacrificing hardware utilization if the software development effort can be streamlined. Similarly, one may be able to “over-engineer’’the hardware and use a nondeterministic solution with low utilization more cost-effectively than a highly utilized system employing a sophisticated resource scheduler. For

306

J. R. AGRE ETAL.

example, Ethernet may be a viable control network solution provided only a small fraction of its bandwidth is used.

2.1.2 Greater ”Siliconization” It is desirable to implement more ~ u n c t ~ o n ain ~ ~silicon. ty Moore’s Law originally addressed developments in computing hardware devices. These advances were realized largely because of technologies for mass production of increasingly more sophisticated VLSI chips. Such technologies can also be used to produce other devices. In particular, communications devices are being manufactured with an increasingly larger proportion of IC technology (not necessarily limited to silicon, e.g. gallium arsenide). This implies that Moore’s Law is applicable to communications to some extent, although other factors (e.g. Shannon’s theorem) may limit the rate of the curve compared to microprocessor development. Greater siliconization results in two effects: first, cost efficiencies result from the mass production in chip foundries, and second, achieving greater transistor densities means that 10, communications, and control algorithm processing capabilities can be integrated in a single chip, thereby further decreasing the costs of interconnection components. Such smart devices are expected to become predominant in industrial environments. “Silicon sensors,” i.e. miniature analog and digital sensor devices that can be manufactured using chip-processing techniques, are also becoming increasingly successful. To a lesser extent, silicon actuators are also becoming a reality.

2.1.3 Increasing Digitization

Digital realizations of systems are favored over analog realizations. The power of digital processors has increased to the point where traditional analog functions are migrating to digital implementations resulting in increased reliability and functionality (e.g. compact disc players). For example, digital storage media can provide tolerance to errors as well as store greater densities of data. In communications, digitization can increase the reliability of data transmission and at the same time decrease cost (e.g. wiring and installation). A smart sensor, which employs a co-located microprocessor or a digital signal processor, has the flexibility to be programmed to perform a wide variety of signal processing functions tailored to the specific needs. In conventional sensor processing, analog circuits would be required for each signal processing function or require raw data to be transmitted to remote processors.

A TAXONOMY OF DRCS

307

2.1.4 Grosch’s Law Overruled

The cost per machine instruction executed is inversely proportional to the square of the size of the machine. That is, there is an economy of scale in computing machinery. Around 1970, Grosch’s Law became untrue. Today the trend is reversed, i.e. the most cost-effective (MIP/$) processor is the microprocessor and not the single-processor mainframe computer. This trend is important since it provides the most direct rationale for the trend towards distributed control and processing.

2.1.5 Increasing Use of General Purpose Components Economy of scale encourages the use of generic products that may be over-qualified in some respects, but are still more cost-effective. Start-up costs are taking an increasingly greater proportion of the overall cost (including production). The chip manufacturing case is a good example of this general trend, since the majority of the cost is in manufacturing the first chip. Economy of scale then results by virtue of the fact that if more chips are produced, then the cost per chip is reduced. Another example of this is in software development where virtually all of the costs are incurred during development and test while production costs are negligible. This results in products such as word processors that contain thousands of functions, most of which are rarely used by the average user. The impact on DRCS is that a small number of products will address a large spectrum of applications. There are benefits in terms of deployment, maintenance, and training that can represent significant long-term operational cost reductions. It should be noted, however, that the start-up costs are dropping in some areas, such as computer-aided design of application specific integrated circuits, allowing a greater degree of customization.

2.1.6 Open Systems

In the current marketplace, there is a strong trend towards open systems. The power of this concept can be illustrated by the rapid growth of Internet applications such as the World Wide Web. The success of the IBM-compatible PC is also widely attributed to its open architecture. There are both economic and philosophical advantages to producing open systems but there is also greater competition in any particular arena. Currently there is a growing interest in open architectures for the control systems industry. There are several interpretations as to what an “open” system means: 0

interoperability among components or subsystems offered by different vendors,

308 0 0

J. R. AGRE ETAL.

interchangeable components offered by different vendors, and a broader interpretation to mean udaptable to unforeseen changes.

There appears to be a growing demand from customers for products that adhere to open standards that allow them to construct a variety of systems out of standard building blocks. Different products are able to interoperate due to the fact that they adhere to well-known public or openly licensed standards. Customers want interchangeable items to stimulate competition. This makes the job of vendors more difficult in distinguishing their product in terms of functionality (versus simply being cheaper through manufacturing processes alone). Adaptable systems permit accommodation of evolving technology over the relative long lifetime of industrial systems having large capital investments. Rapid adaptation supports the goals of agile manufacturing described below. There are several critical issues in implementing open systems: 0

0 0

system configuration, system fault management, and standards adoption.

Configuring system parameters with components from different vendors is a non-trivial task, akin to plug-and-play, but in a more general setting. Determining the cause of system faults in a multi-vendor environment is hampered by current system testing techniques that are not integrated across vendors. Premature selection of a standard can hinder technological advances while competing standards present risks and confusion among potential adopters. In the context of a DRCS, open systems appear to be immanent as the generic intelligent I 0 devices and low cost communications begin to reach the market. It would appear impossible for any one supplier to maintain expertise in sensors/actuators, 10, control software, and communications to the level necessary to dominate the market. As no vendor currently can lay claim to the controls market, new devices must adhere to open protocols in order to gain wide acceptance. Strategies for positioning products in such an environment are important and strong product discriminators are necessary which allow one vendor's products to offer superior functionality that captures customers.

2. I. 7 Agile Manufacturing Agile systems are those that can quickly adapt to change. In spite of the fact that Henry Ford proved that mass production of identical copies results in much lower production (and component replacement) costs, people want

A TAXONOMY OF DRCS

309

diversity in much of what they purchase and own. Geopolitics, environmental and ecological events, fashion fads, technological innovations, dynamic business partnerships (enterprise integration and virtual enterprise), and many other factors affect the marketplace (demand) and supply of raw materials to the factory. Equipment failures and labor problems also impact production. The ability to change the manufacturing process for a given product, to produce a new product, to change the volume of production, and to alter the proportional mix of products, and do so rapidly and cheaply, is becoming a necessity in many industries. Although the degree of agility required is highly dependent on the product, it appears that the overall need for agility is increasing in the majority of manufacturing applications. DRCS offers a potential solution by means of its modular decomposition of the overall system into less complex subsystems tied together through well-defined interfaces.

2.1.8 Large Complex Systems Current control systems can be viewed as examples of complex systems, consisting of a large collection of relatively simple entities following simple rules of behavior. The numerous shop floor-level components are relatively simple individually, and yet the overall manufacturing cell or factory is becoming increasingly complex in its design, function, and operation. An analogy may be made with biological systems. For example, ants have evolved a complex social structure and are a successful species according to certain metrics (e.g. aggregate biomass, and survivability). New theories of complex systems point out, among many other things, that allowing a degree of autonomy among the elements can result in emergent behavior and structure that is beyond the capabilities of any individual element (e.g. hive behavior). Ongoing research efforts aimed at applying these concepts to a control context may achieve breakthroughs in adaptive architectures. A particular application (such as a factory) will require a large aggregate amount of processing. Tying together a large number of small processors into a cohesive system is non-trivial. While great strides have been made in computing hardware, progress in implementation of complex systems is still at a young stage. Nevertheless, network operating systems and tools for designing, configuring, and maintaining distributed systems are coming into existence and promise to unleash the power of the aggregate.

2.2

Emerging Technology Trends in Computing

The evolution of an area like DRCS involves advances in many related areas such as distributed computing, communications and programming

310

J. R. AGRE ETAL.

environments. In this section, we briefly discuss some important topics that are closely related to this evolution.

2.2.1 Distributed Real-time Operating System Research There has been considerable research on distributed real-time operating systems in the computer science domain over the last decade. Distributed operating systems manage the overall resources, such as communication links and processing elements, across multiple distinct computers efficiently and transparently. Progress has leveraged research in centralized real-time systems spanning the last two decades. Although encouraging results have been described in the literature, very little has actually permeated factory systems. Some of the R&D projects that are described in the open literature are briefly summarized below. The Spring distributed real-time operating system [30]was developed at the University of Massachusetts for large systems and provides support for application-level predictability and fault tolerance. Spring is a multitasking system that has a separate notion of task importance and task deadlines and uses both for scheduling. The HARTS (Hexagonal Architecture for Real Time Systems) system [28] is built on a wrapped hexagonal interconnect scheme. It is a high-speed, predictable and reliable parallel system using shared memory. The emphasis is on efficient and fault-tolerant communication functions that are incorporated in deadline guarantees. The MARS system, developed at the Technishe Universitat Wien [19], is designed to be a completely deterministic, distributed time-driven control system, even under peak load conditions. A global clock that controls both bus and CPU timing synchronizes all activities. It is possible to have multiple cycles with different periods concurrently active in the system and to dynamically change this mix. The Maruti system [20] is an object-based distributed real-time operating system developed at the University of Maryland. This system has a scheduler that can constrain the task start times and still meet deadlines. It uses a calendar-like data structure to drive scheduling and fault tolerance functions. The CHAOS (Concurrent Hierarchical Adaptable Object System) [26] is intended for large, dynamic real-time applications. It is a transactionoriented system and supports atomicity as a basic concept for implementing reliable operations. TRON (The Real-time Operating system Nucleus) [25] is a Japanese developed standard that establishes methods for data interchange. It is an open architecture and includes VLSI designs and software. It has versions

A TAXONOMY OF DRCS

31 1

that are tailored for industrial, business, network servers and workstation communications applications. A real-time version of the MACH multiprocessor operating system has been developed at Carnegie-Mellon University. Real-time MACH [34] extends the multitasking, multithreading concepts of MACH to the real-time domain. Real-time Mach is currently being applied to industrial control applications in a research environment [ 151. The Chorus System [16] was developed by INRIA in France starting in 1979 with the objective of replacing the conventional monolithic operating system with a set of independent servers running on a microkernel. Chorus provides certain real-time functions and configuration capabilities missing in Unix. In 1991, Chorus became compatible with Unix System V and will continue to coordinate with System V developments. The Amoeba system [32] is a distributed operating system aimed at providing transparency services for making a collection of workstations appear as a single machine. It was started in 1980 at the Free University in Amsterdam, Holland. Amoeba is currently not a hard real-time system although there is considerable effort in building fast file servers and efficient parallel processing methods.

2.2.2 Autoconfiguration One of the major attractions of a DRCS is the potential ability to replace system components (hardware, software, and network) without disrupting the system or requiring human intervention for configuration (e.g. plugand-play). This requires intelligent devices with software algorithms that can adapt to unexpected change and perturbations. Many possible perturbations occur during the lifecycle of a control system as summarized in Fig. 1. Users may need to add new functionality to the application, increase the size, or improve the performance. Sometimes, existing functionality may be discarded. In a factory, a lack of raw material or failure of manufacturing equipment may also temporarily interrupt the process flow. Similarly, in the control system itself, control components may fail or be changed. In the event of one or more failures, users would like the system to continue operating normally or in a gracefully degraded mode until repaired. Similarly, addition of new components should be performed in a hot mode (i.e. without shutdown). Research efforts in the area of autoconfiguration attempt to develop new architectures for building such systems. Techniques for autoconfiguration employ information about a unit’s capabilities that allow it to be easily incorporated into the system. With increasingly intelligent devices, it becomes possible to store detailed models and other

312

J. R. AGRE ETAL.

FIG. I . Lifecycle of a control system.

self-knowledge within the device itself and to incorporate this into more sophisticated distributed plug-and-play algorithms [ 11.

2.2.3 Fault Tolerance and Diagnostics New fault management schemes are required in a DRCS comprising multiple controllers and I 0 devices. At first glance, a DRCS would seem less reliable, as it is made up of many components, each of which could fail. To counteract this, it is necessary to design procedures that will detect, diagnose, and recover from failures, and continue operations. It is necessary to build in a certain amount of excess capacity in each of the component devices to recover from faults. Many forms of redundant configurations are possible and they can be tailored to provide levels of fault tolerance as dictated by the requirements. However, unlike general-purpose computing, the computations in a DRCS processor may not be readily moved to other locations if there are I 0 connections that are hard-wired. Fault tolerance can be implemented in both hardware and software. Hardware fault tolerance is a well-studied area in general-purpose distributed computing systems. In a DRCS context, process and equipment failures usually dominate control system failures and there is a need for system-level services to assist in fault management of the process itself. In addition, writing control systems software that can recognize and deal with process and equipment failures remains a challenging problem.

A TAXONOMY OF DRCS

2.2.4

31 3

Object Orientation

It has become clear that the hardware is advancing at a much more rapid pace than the corresponding software technologies. Typical software costs are now more than 50% of the total cost of a system. There is an urgent need to reduce software cost and development times. Object-oriented design and programming is one technique that can increase the ability of software to handle complex control applications. The benefits of modularization have been well known for some time, and object orientation offers (among other things) a degree of modularization in the software arena. Object-oriented design has a close correlation to the physical objects in the system and supports the notion that the software can be developed for smaller system modules independently. Software reuse is also facilitated in object-oriented systems. Object-oriented frameworks are being defined for interfacing control systems to Manufacturing Execution Systems (MES) for resource management and Supervisory Control and Data Acquisition (SCADA) functions.

2.2.5 Autonomous Cooperative Systems A new design paradigm for manufacturing systems that builds on a holonic concept is under active research. In holonic systems, each subsystem is viewed as a having a “whole” or autonomous aspect and a “part of” or cooperative aspect, much like a cell in an organ [2, 5 , 14, 371. These systems potentially provide more adaptability, robustness, improved performance and availability than conventional control systems. Holonic subsystems communicate by exchanging goals and intentions, as opposed to conventional systems in which objects communicate by sending messages which invoke specific functions. This allows a holonic entity to formulate problem solving strategies and goals based on these messages it receives. A taxonomy from the cooperative, distributed, problem-solving area [ 131 describes many aspects of such systems.

2.2.6 Control-Application-Centric Programming Alternative programming paradigms, such as constraint-based programming, are beginning to receive attention in the control systems industry. In a constraint-based, control-application-centric view, the user specifies highlevel constraints between domain objects; thus defining the needs of the control application. Figure 2 presents an example factory application to illustrate this technique. The conveyor on the left brings blocks into the workcell and the

314

J. R. AGRE ET AL.

’

I

Clean

block-Turn

Drill

Start-Em

Start-Home

FIG.2. Example factory application.

transfer ram moves the block to a turntable. The turntable cames the block (by spinning) to three workstations, namely, a drilling station, a milling station, and a cleaning station. When the operations are completed, the transfer ram brings the block back to the conveyor, which moves the block out of the workcell. Constraints are imposed on the possible actions that define correct operation. For example, a Block-Start constraint between turntable position 2 and the drill specifies (to the drill) that the drilling action must begin when a block is in position 2. Similarly, the Start-Home constraint between the Conveyor-in and the Transfer Ram specifies that the conveyor must not start unless the Transfer Ram is in the Home position. Models of each of the components (conveyors, transfer rams, turntables, etc.) are used to describe the actions and can be state-based models (e.g. Petri nets, finite state machines) or logic-based models (e.g. predicate calculus, Prolog). A formal model theory (e.g. constraint satisfaction) can be developed to synthesize an integrated control program based on these specifications. Constraint-based programming has been a topic of interest in the area of general-purpose computing. Due to a significant level of structure and commonality among programs for control systems, the control systems programming domain appears to be well suited for the development of this approach.

A TAXONOMY OF

DRCS

315

2.2.7 Automatic Programming Despite the lack of success of fourth-generation programming languages that promised to generate code from high-level specifications, evidence is mounting that automatic code generation systems are feasible in limited, domain-specific applications. Segments of industrial control systems, particularly robotics applications, have implemented such systems using simple specification languages or simple teaching methods in which motion is simulated or graphically defined. Code is then automatically generated to implement the motion. Coupled with autoconfigurable components, automatic programming may facilitate the commissioning of or modifications to large distributed control applications. Research is continuing in this area and will likely prove to be practical in the near future for DRCS.

2.2.8 Highly Distributed Control System A fully distributed architecture has been proposed that maximally pushes the distribution of intelligence out to every 1/0 point (sensor/actuator) that provides information to/from the environment [ 11. In this system, the general-purpose controllers are no longer necessary. As shown in Fig. 3, each system element incorporates a sensor/actuator, signal conditioning, control processor and a communications capability. The principle of local control is used where nodes behave and interact according to well-defined rules based on the state of their immediate neighborhood. Overall process control emerges from the aggregate behavior. A real-time distributed 0s that provides guaranteed, predictable control algorithm computations is

FIG.3. System view of a highly distributed architecture.

31 6

J. R. AGRE ETAL.

implemented on each node and an efficient, predictable peer-to-peer communications network such as a Fieldbus [6] or DeviceNet [12] could be used. As shown in the figure, a man-machine interface (MMI) is provided by a separate tool that can be plugged into the system at any location and have complete access to the desired data. Such a system will provide reductions in the number of physical connections, the cost of the package, and the power requirements. Further advantages accrue due to the ability to provide customizable features, embedded sensor/actuator self-knowledge, self-diagnostics and better performance for many applications. The primary disadvantages of this scheme include increased complexity of the software, concern for stability/predictability, and fault diagnosis. We postulate that with a highly distributed architecture, the overall system costs will be decreased, but this will depend on many of the factors/trends affecting the market described earlier. Ultimately, these control systems will evolve to a complex adaptive system that is selforganizing, despite the fact that the detailed interactions are beyond the ability of an engineer to explicitly design.

3. Taxonomies for DRCS In this section we present two taxonomies for DRCS. These taxonomies are useful tools to distinguish between different kinds of DRCS, based on the specific architectural options. Figure 4 highlights the primary dimensions of a traditional control system architecture. In a traditional control system, a central programmable logic controller (PLC) retrieves sensor inputs and computes actuator outputs, transfers those values through the I 0 system to/from the application and includes the ability to program and monitor/operate the system. The dimensions of a traditional control system are I 0 (input/output), control algorithm processing, programming, and MMI (man-machine interface). Designing a control system involves making judicious choices for each of the attributes within the categories that are consistent in the context of the target control application. We refer to a dimension as centralized if communications is not used, and distributed if communications are effectively used. The above interpretation is consistent with the community wide interpretation of the terms “centralized” and “distributed” in the context of computing systems. The principal discriminator between a DRCS and a traditional centralized control system is the effective use of communications protocols to realize the system goals. In particular, by centralized I 0 we mean communication Principles of classification.

317

A TAXONOMY OF DRCS

Control Systems

Controllei Programming and monitoring tools

PB Panel

FIG.4. Dimensions of a traditional control system.

of an analog signal transmitted on a dedicated wire between a controller and an 1/0 point, whereas distributed I 0 uses an intermediate protocol. The dimensions of a DRCS are shown in Fig. 5. Digital communications media and protocols have strongly influenced the design choices in the 10, control algorithm processing, and MMI categories over the last two decades.

3.1 The IOC Taxonomy

A simple taxonomy is defined by considering two dimensions of I 0 and control algorithm processing as shown in Fig. 6. The IOC Taxonomy is a DRCS

\

/

10

MMI

FIG.5 . DRCS dimensions.

31 8

J. R. AGRE EJAL.

I0

T D-

D I N - - -DIDC

-

CICC- - - - -CIDC I

I

C = Centralized D = Distributed

Control algorithm

projection of two important features of the full taxonomy presented in the next subsection. This partitions the set of known control system architectures into four basic categories: CICC, DICC, DIDC, and CIDC. The CICC system is a traditional centralized control system. DICC is a DRCS in which I 0 is distributed and control algorithm processing is centralized. This architecture has been popular in the discrete control systems industry (e.g. remote I 0 systems). In the process control industry, the term distributed control system (DCS) is typically used in the context of DICC systems. The category DIDC has both I 0 and control algorithm processing distributed. These systems are prevalent in the forms of systems of multiple programmable logic controllers (PLCs) [7, 181 with dispersed 10.CIDC is a system in which I 0 is centralized and control algorithm processing is distributed. Such systems are used when there is a need to have redundant control computations (e.g. critical control functions in a high risk system). A second, less obvious form of CIDC is a highly distributed system in which control algorithms are realized at the level of the sensors/actuators; these combined IO/controllers are networked in order to accomplish system-wide control goals.

3.2 Control Systems Architecture Evolution A brief history of control systems architecture is helpful to set the context for understanding evolutionary trends. Some important developments in control systems architecture over the last two decades are discussed and shown in Fig. 7. The systems selected are illustrative examples. See [8, 23, 311 for a more detailed and thorough review of control systems architectures. One observes a steady evolution from the early control systems to the current versions of DRCS. For each example, we indicate the IOC classification of the system.

31 9

A TAXONOMY OF DRCS

1970s

PLC or Drive Master

I 1980s Remote 1 0 Racks

I

Small Logic Controllers

Intelligent 1 0

.

PLC Adapter Mode

.

Network PLCS

\

1990s

Highly Distributed Control

FIG. 7. Historical trends in control systems.

Around 1970, the costs of processors, memory, and communications were still relatively high, when control engineers essentially replaced relay networks with a computer-based architecture with processing and memory functions in a single box. This single box was successfully optimized for cost and rapid evaluation of relay-type logic, thus producing a revolutionary product, the programmable logic controller (PLC). The primary benefit was that the control system could be implemented and modified using software instead of hard-wired relay circuits. In the early 1970s, as the cost of communications decreased, they became incorporated into control systems. Remote I 0 (RIO) devices were built that concentrated multiple 1/0 signals over a wire to a single PLC as shown in Fig. 8. The principal business drivers for this innovation were: 0

0

0

reduce wiring and thereby reduce installation and maintenance costs, increase the distances between the control application and the control system, and increase transmission reliability.

Such a system can be classified as a DICC DRCS. Shortly after this, control companies began to be interested in experimenting with smaller controllers, although the communication

320

J. R. AGRE ETAL.

Programming and monitoring tools

PB Panel

0 Remote 1

FIG. 8.

Remote 10.

capabilities were limited. The business drivers for building these systems were: 0

0 0

reduce controller costs by integrating the control functions into an inexpensive, smaller controller, improve reliability and ruggedness of the control system, and they were better suited for incremental expansion.

Each of these smaller controllers still operated in a centralized fashion, and therefore the DRCS remained as a DICC. In the next step of the evolution in the early 1980s, we witnessed the introduction of intelligent (or smart) I 0 devices such as fast motion control. These intelligent I 0 devices were a result of developments in processor and memory technology and integrated the I 0 device, I 0 module and some specific control functions. These devices were generally slaves to an associated PLC and used the I 0 network to communicate. The business drivers for the introduction of such devices were: 0 0

0

0

exploit special purpose controllers embedded in I 0 devices, decrease the I 0 load on the main controller, locally perform signal conditioning, low-level loop closures, and preparation of information for display, and improve diagnostics.

The use of intelligent I 0 devices represents a simple version of a DIDC DRCS. Also in the early 1980s,the master-slave controller architecture was introduced, called PLC Adapter mode. From an architectural perspective, this was a simple attempt to construct a loosely coupled, multi-controller system. A central (master) controller coordinated the activities across the

A TAXONOMY OF DRCS

321

different slave controllers operating on their local 10. The architecture is shown in Fig. 9, where PLC 1 acts as the master for the other two PLCs. In practice, the coordination between controllers is accomplished using communications similar to I 0 transfers. The business drivers for such systems were: 0

0

primarily to improve the response time for local I 0 processing, and increase the size of applications (i.e. number of I 0 points) that could be handled.

As the previous system, the master-slave controller system can be classified as simple DIDC DRCS. In the early 1980s, the utility of general-purpose, high-speed, intercontroller traffic became recognized for large, multi-PLC applications. This caused the introduction of separate control network capabilities such as provided by Data Highway, which allowed peer-to-peer messaging between controllers. This resulted in systems that can also be depicted by Fig. 9. These architectures differ in the protocols, but are also DIDC. In the 1990s, control companies began to be interested in experimenting with distributed control systems with mixes of large and small controllers. The business drivers for building these systems were: 0 0

0

achieve scalability (of the control system) through distribution, reduce controller costs by distributing the control functions over a collection of inexpensive, smaller controllers, and enable fault-tolerant systems.

PLC 1

FIG.9. Networked controllers.

322

J. R. AGRE ETAL.

I

1

1

1

1

I

FIG.10. Highly distributed control.

At the present time, distributed system components with integrated I 0 and control are appearing in the market and in research prototypes. Communications technology has improved significantly with the introduction of integrated circuits such as the CAN chip. This allows vendors to exploit low-cost, high-speed communications options in device-level communication networks that support both I 0 and control traffic. Coupled with the availability of low-cost, miniature processor and memory technologies, it is possible to effectively produce an integrated device as shown earlier in Fig. 3. Systems comprising these elements as shown in Fig. 10 are classified as CIDC DRCS.

4.

DRCS Taxonomy

While the IOC Taxonomy helps to differentiate between DRCS at a gross level, it is not sufficient for designing or research planning. In this section we present the DRCS Taxonomy based on the five dimensions shown in Fig. 5. We have been able to characterize, classify, and reason about many different DRCS architectures using this scheme. Establishing the completeness of a detailed taxonomy is a complex and difficult task. While we believe that this taxonomy is extensive enough to characterize a large number of DRCS, we cannot claim that it is complete. Many of the attributes such as processor, protocols and operating systems are complex enough in their own right to warrant their own taxonomies. Our criteria were mainly based on emphasizing those attributes distinguished among the architectures summarized in the Appendix.

A TAXONOMY OF DRCS

323

In order to establish some terminology, an example of a typical DIDC system is provided in Fig. 11. This system shows two controllers, each with its own I 0 network, a common control network and various communication interfaces. In the I 0 portion of the system, I 0 devices (i.e. sensors and actuators) are distributed around the plant. The I 0 devices are connected via point-to-point wires, called I 0 connects, to an I 0 module for conversion to digital data. The I 0 modules can be remote or local. Local I 0 modules are plugged into the backplane of the controller. Remote I 0 modules are clustered into racks under the control of an adapter. The adapter communicates with the modules over the adapter backplane on one side and then communicates with the controller through the 10 network. The I 0 modules and adapter reside in the I 0 chassis or rack. There may be many racks connected to the 10 network. The controller portion of the system consists of several components that reside in a controller chassis and are connected using the controtter backplane. The I 0 network is connected to the 10 network conzmunication interface ( I 0 Comm IF). The I 0 Comm IF will typically transfer data to/from the remote I 0 subsystems to a scanner device. The scanner controls the timing for the collection of the sensor input and places inputs into the controller’s memory. Similarly, it transfers values back to the actuators. The scanner also collects data from local I 0 modules, typically at much faster rates. The controller uses the I 0 data and local state information in its memory to implement all, or a local portion, of the system control

10

Connect

FIG. 11. Typical DIDC system with two controllers.

324

J. R. AGRE ETAL.

algorithm. Controllers communicate to each other over a controller network through a controller communication interface (Control Comm IF). There are many variations of the hierarchical system shown in Fig. 11 that will be captured in the taxonomy. These fall into the classes of functionality or implementation. Functionality refers to the basic operations or capability that a component must accomplish. Implementation refers to the methods and/or locations that are used to accomplish the functions. The location of the implementation is often defined by the packaging, which refers to the integration of component types into one device, eliminating interfaces or links. The basic property of real-time control processing is to provide the control response outputs within a predictable, bounded response time from the relevant inputs. A hard real-time system is defined as a system in which the inability to respond to input events within their associated deadlines results in a system failure. In a soft real-time system the inability to meet the deadlines does not result in a system failure but a cost penalty is associated with tardiness. For example, production planning is a soft real-time system since failure to meet a delivery date is typically detrimental but not catastrophic. A non-real-time system will provide the outputs as fast as possible, with no guarantees and no innate design that supports predictability. The predictability property of a control system architecture will be emphasized in the taxonomy. Depending on the way in which the system operates, it is said to be deterministic, quasi-deterministic, or non-deterministic. In deterministic systems, it is possible to accurately predict the performance of the system. In quasi-deterministic systems, although the performance cannot be predicted as accurately as in deterministic cases, it is possible to determine worst case upper bounds before which the system can be guaranteed to respond. In non-deterministic systems, it is not always possible to guarantee a response time and it may be difficult to predict the response time without detailed modeling of various system parameters. Under normal operating conditions, the performance of non-deterministic systems can be significantly better than the other systems; however, the behavior under abnormal operating conditions is not always possible to characterize and predict. The predictability of the various subsystems will be discussed; for example, the communication subsystem or the operating system in the controllers can either be deterministic, non-deterministic, or quasi-deterministic. In the following taxonomy diagrams, solid lines under a heading indicate that one or more of the subitems may be included in an implementation while dotted lines indicate that only one subitem is selectable for a system.

325

A TAXONOMY OF DRCS

Input/Output

4.1

We first consider the I 0 dimension of Fig. 5 . In a DRCS, the function of the I 0 subsystem is to capture the input signals from the sensors and convert the values into a form suitable for transfer to the appropriate controller. A similar process (reversed) is followed for outputs to actuators. As shown in Fig. 12, there are four primary functions in the I 0 category. Z 0 Transduction and Signal Conditioning are required while Diagnostics and I 0 Data Processing may be additional features. The I 0 Transduction is either of type analog or discrete. Discrete I 0 is typically one bit of information (i.e. on/ofQ while analog I 0 values range over an interval and will require a substantially larger number of bits. Applications tend to be predominantly one or the other, although mixed systems are becoming more prevalent. The Signal Conditioning function includes activities such as amplifying, digitizing, filtering, forcing, or other signal processing functions. During input, the result of signal conditioning (for either type) is a digital representation of sensory values. During output, a digital signal from the controller is converted to an appropriate output signal for the actuator. Signal conditioning is important both for analog and digital 10,although the complexity of the required processing may be much greater for analog devices. Digital

DRCS

Processing Communicalions

Function

ImDlementation

I/O Transfer

Transduction

\

__

Packaging 5,

~

I

I

, I

I

I

I

\

,

Discrete Analog

ILocal 10 l",""",r Module

~

_ -. ~

-Remote . Adapter

Periodic

-,>.,-* , *,, \ - _. -, + . -',.'., ' ,

Diagnostics

I

~

,

,

,

I

~

Integrated , ,' lo 10Devlce; I'

,,', '>

\-

'\

I

'\

I

\

\ \

-. . Integrated .... M8 I

\

I

t

\

I,,lr

~ ~

Intearated intearatea 10I U lntearated Intearated Module with Controller wiih Controller

FIG. 12. I 0 categories.

Integrated Adapter with Controller

Static

Dynamic

326

J. R. AGRE ETAL.

representations are employed for several reasons. Digital signal processing techniques can be used, digital communication is generally more robust with respect to noise via error detection and correction schemes, and storage of digital values is possible using RAM components. Diagnostics for an I 0 device refers to methods for determining whether the device is functioning properly or has failed. Intelligent I 0 often refers to I 0 devices that contain additional circuitry for performing self-test or that allow other control devices to peiform diagnostic tests. I 0 Data Processing refers to a list of possible other activities that may be included at an I 0 device that has processing capabilities. These include functions that may provide preprocessed information to the control algorithms such as manufacturing process modeling, historical trending, data logging, configuration, statistical functions or alarming functions. The Implementation of these I 0 functions significantly affects the overall architecture and functionality of the DRCS. The basic choices are to: 0

0

locate the I 0 functions (signal conditioning, diagnostics, data processing) in a centralized location (typically the controller, as a service to all I 0 devices), or distribute the I 0 functions throughout the I 0 subsystem (either in one or more I 0 modules and/or in I 0 devices).

I 0 is centralized if the controller is colocated with the I 0 module or the I 0 device. Also, if an I 0 module is on the controller’s local bus, it is considered to be colocated (although communication is taking place; typically, a parallel bus architecture is used to accomplish high-speed I 0 transfers). On the other hand, if the I 0 module is not on the local bus, remote communications services must be provided and is said to be distributed. In Fig. 13, some of the various forms of packaging for implementing distributed I 0 functions are shown. Diagram (a) is the remote adapter scheme (e.g. remote 10) that was shown earlier in Fig. 11. The connection between I 0 modules and the I 0 Comm IF is via a I 0 chassis backplane bus. Diagram (b) shows an integrated I 0 module in which an 10 module is combined with a communications capability yielding an I 0 module capable of direct remote communication. The module could be equipped with an adapter-style communication interface that is a slave to a controller or it could be a more general type of communication interface that could conduct peer-to-peer communication. In (c), an Integrated I 0 device is shown in which the I 0 device, the I 0 module and the communications are packaged as a unit (e.g. a fieldbus-capable photo detector). Diagram (d) shows integrated I 0 with controller where the I 0 device and module functions are integrated with a controller and its control network interface. This package eliminates the need for a distinct I 0 network and colocates the control with the device it is

327

A TAXONOMY OF DRCS

-

(a) Remote adapter

T;oTT"-l cypm1

-

(b) Integrated module

lo

Device

Module

(c) Integrated 10 device

(d) Integrated 10 with controller Adapter Comm IF

(e) Integrated module with controller

Controller

Controller Comm

IF

(f) Integrated adapter with controller

FIG.13. Packaging of integrated system components.

controlling. Diagram (e) is an integrated module with controller that supports multiple 10 connects. Several examples using simple microcontrollers such as an Intel 8051-based system with a built-in CAN port would fall into this package class. Package (f) is the integrated adapter with controller scheme in which the I 0 Comm IF in (a) has now been enhanced to encompass local control and controller communication. These tend to require more powerful microcontrollers (e.g. Intel 80188-based systems). The implementation options (of Fig. 13) are listed in Fig. 12 as Packaging options along with the local I 0 modules that are attached to the controller backplane. The packaging of the I 0 functions affects the I 0 response time (under normal and fault conditions), wiring costs and the processing requirements of the controllers. Performing the conditioning or other processing locally can be optimized for the specific devices and avoid the contention for controller resources, resulting in quicker response times. The use of modules and adapters serves a data concentrator function. Many I 0 points can be routed to an I 0 module and share a common bus to a controller, eliminating the need to run all I 0 connects directly to the controller, thus significantly reducing wiring costs for large-area systems. As an example of the effect on processing requirements, in diagnostics the choices are to: 0

0

locate I 0 diagnostics in the Controller (e.g. as a special function) requiring additional control logic, or distribute 10 diagnostics throughout the I 0 subsystem (either in one or more I 0 modules and/or in I 0 devices), offloading the controller.

Distributed diagnostics may also result in faster diagnostics response times.

328

J. R. AGRE ETAL.

The I 0 Transfer function refers to the synchronization of delivery of I 0 data to and from the controller(s), and is either periodic or event driven. Periodic I 0 synchronization can be either static or dynamic based on whether the periods are fixed or may be modified at runtime. Depending on the packaging, periodic I 0 synchronization can be initiated either by the controller using a scanner in a master-slave mode, or by self timers in the I 0 package itself and peer-to-peer communications. Static transfer is usually performed by a device called a scanner that is colocated with the controller. The scanner polls the I 0 modules deterministically with a fixed time period, called the scan time. Static periodic systems may employ several scanners which are physically separated or colocated and operate at different but fixed scan times. A periodic system that is dynamic employs multiple time cycles and can intentionally switch between them at the direction of a control command (e.g. MARS-see Appendix). Often in practice, there are unintentional variations (jitter) in the scan time due to data-dependent logic scan times or special I 0 transfers initiated by the controller during control algorithm processing, that affect predictability. Event driven I 0 synchronization is based on either detecting: a ChangeOf-State (COS) of predefined variables, or predefined events (as sequences or expressions of COS of predefined variables). The advantages of an eventdriven system over a periodic system are that: (1) on average it is more responsive, in the same sense that an Ethernet has a smaller average delay compared to a fixed channel allocation scheme, and (2) the amount of communication in a COS-based system can be reduced by not sending repetitive information. However, the disadvantages are: (1) additional measures to guarantee the delivery of data are necessary, (2) heartbeats or other methods to detect failures in a particular 10 Device-Module-Interface path are required (since it is difficult to distinguish between a failure and a long period of no COS), and (3) prevention of an avalanche of data from overwhelming the communications system in exceptional situations are needed. Unlike periodic I 0 synchronization, event driven I 0 synchronization is nondeterministic unless techniques for bounding the performance are used (e.g. priority scheduling). There has been a steady improvement in the functionality of Intelligent Integrated I 0 devices that support signal conditioning, I 0 diagnostics, and digital I 0 transfer within the same I 0 device. A recent standard activity, IEEE 1451.2 Smart Transducer Interfaces, has defined aspects of the sensor/actuator to communication system interface [ 171.

4.2

Control Algorithm Processing

We next consider the control algorithm processing dimension of Fig. 5.

329

A TAXONOMY OF DRCS

Traditionally, all the control algorithms were processed in a single, centralized controller. The introduction of effective communications made it feasible for multiple controllers to be used cooperatively to control a process. As shown in Fig. 14, the four primary functions are the control algorithm processing itself, process diagnostics, data management, and system interfaces. Controt aigorithms encompass the rules that govern the operation of the industrial application. Application requirements for speed, quality, etc. are increasing and are causing the control algorithms to become more sophisticated with the inclusion of new types of algorithms such as fuzzy logic or neural nets. Control algorithms are now a general mix of information, numerical calculations and discrete logic processing. This is blurring the distinction between the established continuous and discrete control processing domains. Additional functions that were formerly computed in supervisory systems, such as scheduling in material handling systems, are being migrated to the shop floor control algorithms. Process diagnostics are another form of processing now integrated tightly with control algorithm execution. Status information and alarm data must be provided to the operator monitoring stations. The diagnostic schemes often require time tagging of information and sequence information in addition to

DRCS MMI Communications Function

Implementation

Reallime

Cllenti Server

GeAeral Purpose

$:zf

\'

ContrOllerS Controllers

GPC = General Purpow Computer EC - Einbodded Conliolier ic = inriiihtiidi Coiilroiler

FIG. 14. Control algorithm processing categories.

Non-reape

330

J. R. AGRE ETAL.

the I 0 data. Further, diagnostics in a distributed control system can be a difficult task and special techniques are needed to determine the state of the system when an error occurred. The application of operating system services to assist in diagnostics in a distributed system is an active area of research. Various techniques for automatically embedding diagnostics code in the control are being investigated to ease the programming burden of diagnostics. Data management is increasing in importance as more and more information is demanded from the control system by supervisory and other higherlevel management systems. The data is collected and stored by the control algorithms in real-time for internal use or by other systems. In distributed systems the data can be maintained in the form of a distributed database, with all of the associated problems of data consistency and concurrent accesses. Real-time, distributed database techniques are an active area of research. Lastly, the control processing algorithm function System interfaces addresses the flow of information between the control system and various interacting Manufacturing Execution Systems (MES) such as the product scheduling system or the quality control data collection system. The higher level systems do not generally have the same real-time requirements for the data, causing interface and buffering difficulties. Recently, there is a strong push for providing the data to dispersed operators using a world-wide-web type paradigm. Most of the characterization of control algorithm processing is with respect to the four implementation attributes of Fig. 14. The controller type can either be a general purpose computer (GPC, e.g. IBM PC), an industrial controller (IC, e.g. PLC) [7, 181, or an embedded controller (EC, e.g. 80188). While embedded controllers can offer an attractive cost/performance advantage for I 0 handling, and are easily incorporated into custom integrated I 0 devices, their performance range in terms of storage and processing rate is limited. Industrial controllers are explicitly optimized for reliable, fast (e.g. ladder logic accelerator) and deterministic operation (specialized memory architecture, interface to scanner, etc.) in a variety of industrial environments. General purpose computers offer advantages such as low cost (due to mass market), advanced programming environments and familiar software, sophisticated MMI options, and easy integration into higher level information systems; however, their reliability in industrial environments is yet to be proven. Embedded controllers have been effectively used for control only in small systems or in a larger DRCS where they cooperatively interact through the underlying communications infrastructure. There are also a great number of packaging options for the controller integration and packaging as shown in Fig. 15. Option (a) shows a simple

331

A TAXONOMY OF DRCS

(b) Integrated module

(a) Remote adapter

(d) Integrated 10 with controller

(c) Integrated 10 device

Module 10

Controller

Controller Comm IF

(e) Integrated module with controller

Adapter Comrn IF

Controller

Controller Comrn IF

(f) Integrated adapter with controller

FIG. 15. Controller integration and packaging.

stand-alone controller, with an integrated I 0 module, but no external communication other than hard-wired I 0 connects. System (b) has a controller with interfaces to both an I 0 network and a control network. This type of package can seilre as a controller and gateway function or it can be a small controller with separate interfaces to an I 0 network and a controller network. In (c), the controller is packaged with a single communication interface that services a combined network, such as a controller on a fieldbus [6]. In (d), a more standard PLC architecture is shown where the various modules are all connected to a system backplane bus. Lastly, in (e), the architecture of an industrial controller with a coprocessor is shown where the controller is optimized for Boolean logic execution and the coprocessor is used for more general processing. The coprocessor is given a communication interface to a external system network (e.g. Ethernet). The control processor architecture of the DRCS is significant. A single controller is obviously suited for centralized control algorithm processing. This can be a stand-alone controller or a special purpose controller (e.g. motion controller or a drive) that is optimized for its intended application. A parallel controller is a set of tightly coupled processors that operate as a multi-computer (e.g. a dual Pentium PC). In a multi-computer system it may be possible to reuse the centralized control algorithm processing schemes by using a parallelizing compiler. A logic controller with a coprocessor is another example of a parallel controller that uses a combination of an industrial computer coupled with a general purpose computing engine. In multiple controllers architectures, the controllers are usually physically separated and linked via a communication service. The control

332

J. R. AGRE ETAL.

algorithm processing function in multiple controllers must use some form of distributed processing. The nature of interactions among these different controllers varies from nearly independent controllers that occasionally interact to systems in which the controllers are frequently interlocking and exchanging data. There are four common variations of multiple controller architectures: (1) hierarchical in which there are tiers of authority in which higher tiers are masters of lower tier controllers (slaves); (2) federared in which certain coarse-grain responsibilities are granted to a superior tier, but many local functions are performed autonomously, (3) client-server in which controllers are delineated into roles so that clients request services or data from the servers; and (4) peer-to-peer in which controllers can dynamically be either clients or servers or both. These architectures are not always clearly separable. We expect most systems in the future to be basically federated, with many subsystems organized as peer-to-peer or client/server. There are many distributed services that can facilitate the operation of a DRCS. These include notions of transparency, atomicity and synchronization. Distributed services are provided by a distributed operating system or a network operating system that interacts with the local device operating system on each controller (discussed later). The transparency distributed service refers to the ability to regard the distributed system as a single computer. Tannenbaum [32] defines several forms of transparency for distributed systems: (1) data or program location, (2) data or process replication, (3) process migration, (4) concurrency, and (5)parallelism. A major benefit of transparency in control systems would be provided by an object naming und storage service that allows software to access system objects without regard to their physical location. Also useful are remote prograin services, which provide the ability to create, place, execute or delete a program without regard to the platform. Typically, there are servers that perform the registration and lookup functions to provide these services. Standards are emerging for these services (e.g. CORBA [4,29]) however, they have not yet gained acceptance in the industrial setting, primarily due to non-real-time performance. The atomicity service is used to increase the reliability of the control system by insuring that certain operations (called transactions) occur in their entirety or not at all. Various forms of recovery mechanisms can be implemented to checkpoint and restore the component state should the atomic operation fail. Conceptualizing industrial operations as atomic transactions is a promising technique for decreasing operational errors. The interaction among the multiple controllers depends on the type of Synchronization service employed ranging from event-based to time-based to shared resources. The type determines when an interaction is triggered and its predictability. The Event service type allows a controller to register

A TAXONOMY OF DRCS

333

an interest in particular events and to be notified when they occur. This has similar benefits as the change of state approach described under I 0 Transfer. The time service is used to provide a system-wide notion of time. An important application of system time is in the diagnostic function where it is used to establish event causality. Two forms of time are possible: clock time and logical time. Providing a system-wide clock time that is globally known within a specified accuracy to all the controllers in a distributed system can be difficult. Clock time can represent a standard Universal Coordinated Time (UTC) or it can be a common time local to the system. Two common techniques are: (1) provide a hierarchical mastei-/slave system in which a master clock in one device is then transmitted to the other slave devices or (2) mutually synchronized systems that use a peer-to-peer distributed mechanism in which time is determined through an exchange of local times among the system components. Logical time only provides the relative order of events in the system, not their absolute clock time. For many control applications, exact time may not be as important as ensuring that actions occur in the correct sequence, or within certain relative time intervals between events. Many algorithms can be rewritten to use logical time instead of clock time to perform their function. Providing logical clocks in a distributed system may be more cost effective. Further study of the feasibility of logical time in real applications is needed. The management of shared resources across the network is supported through mechanisms that implement mutual exclusion schemes for concurrent access to resources. For example, a two-phase commit protocol that is used for transaction locking in shared database applications can be also used in control applications. The last implementation category in Fig. 14 is the device operating system. The control algorithm executes in an environment provided by the device operating system in the controller. The operating system provides services such as resource management, interrupt handling, and scheduling. The operating system can be designed to provide real-time services in which the length of time required to perform tasks is bounded and predictable. The operating system is said to be non-real-time if such services are not supported. Typical operating systems used with GPCs are non-real-time (e.g. DOS, Windows, Unix). Real-time support is provided in two ways: (1) a periodic execution model (e.g. the PLC scan cycle: read inputs, execute code, write outputs); or (2) a multi-task, interrupt driven, real-time scheduler (e.g. rate monotonic scheduling). These schedulers are priority based and can be preemptive (intenuptible) or not. Preemptive scheduling can provide the fastest response times for high priority tasks, but there is an additional context swap overhead.

334

J. R. AGRE ETAL.

In general, the control algorithm processing dimension can be deterministic, quasi-deterministic, or non-deterministic depending on the interplay among the scheduler, the control algorithm and the communication interfaces. One of the main challenges in DRCS research is to provide efficient, predictable processing systems.

4.3 Communications While the communication subsystem is provided as a service to the other subsystems of a DRCS, specific design choices made in this category strongly affect the other capabilities of the DRCS. In Fig. 16 the attributes of the communication subsystem are given. The primary functions in this category are: the transport of I 0 data, the transport of intercontroller data, the transport of system data and the services of bridgeslgateways. As indicated in the earlier discussions on subsystems, the service requirements for transport of the various types of data can be quite different. 10 data is typically short and needs guaranteed, deterministic message delivery in order to avoid losing sensor data. Control data tends to be used for synchronization and failure recovery. Thus, inter-controller traffic is more

DRCS ~ - . ~ ~

10

-

ControlAlgorithm Processing

MMI

Communication

I

\

Access Method

E T

* ?

FIG. 16. Communications categories.

.

,

Gateway and Control

,‘ ,’ ’, \

I

.p?t

II

RiAg

\\\

’x

Switched

A TAXONOMY OF DRCS

335

likely to be sporadic, involve larger messages and be more suited to quasideterministic or non-deterministic schemes. System data refers to all the other data delivery needs that may or may not have hard real-time requirements. For example, data required for system monitoring and status alarms may be critical and real-time, while that used by MES systems may not. Non-real-time system data such as program downloads can be typically handled in a background mode using a “best effort” protocol. The functions of bridginglgateways between multiple networks becomes increasingly important in distributed systems. Bridging refers to interface devices that connect two (or more) networks using the same protocol, while a gateway connects two (or more) networks of differing protocols. These devices are tending to be more intelligent, providing services such as data filtering, alternate routing, and broadcasting. The bridginglgateway functions are critical to providing large, scalable DRCS as they can serve to partition the system into logical subsets. Next the implementation categories will be discussed. A communication protocol definition such as in the Open Systems Interface (OSI) is designed as layers of services from low level physical signaling, to media access, through internetworking, up to the application layer. Under the protocol implementation we consider two attributes: the addressing scheme and the access mechanism. The addressing scheme can be source-based in which only the producing device’s address is used in messages versus destinationbased, Source-based schemes can be extended to use content-based addressing in which codes are used to identify the meaning of the data within the message (e.g. Hitachi ADS [22,36]). Source or content-based schemes are typically used on a broadcast bus, a ring, a data server, or when routing schemes can be a priori specified. Destination-based schemes are used when there is usually one destination group or when the routing is dynamically constructed. The protocol’s capability to provide deterministic service is strongly affected by the access method, which gives the rules for sharing the common communication medium. Polled, token-based and time division multiple access (TDMA) schemes that all use a fixed time slot allocation are deterministic. Token schemes which allow nodes to skip their time slot when they have nothing to transmit (e.g. ControlNet [l 11) result in quasideterministic behavior. Random access schemes such as Ethernet result in non-deterministic performance while a priority-bus scheme (e.g. CAN) can be made quasi-deterministic. The I 0 data types supported on the network have traditionally been an important consideration in discrete control systems. Previously, the communication system was optimized for binary data, and other types of data (e.g. analog) were handled differently by the controller. This was called a block

336

J. R. AGRE ETAL.

I 0 transfer capability and it typically degraded the controller performance. More recently, the communication systems have had the ability to handle general data messages by implementing more sophisticated protocols at the device level (e.g. Fieldbus [6]). We now consider the interface packaging options. There may be segregated networks in which the data on each network can be strictly I 0 data, strictly inter-controller messages, or strictly system data (e.g. Ethernet); each through sepurute 10 and controller cornnzunication interfaces implementing possibly different protocols. Alternatively, the traffic may be mixed on a single network (e.g. DeviceNet or ControlNet [ I 11) through a common integrated interface, called I 0 and controller communication interfuce, capable of handling both I 0 and control data messages. There may be communication interfaces that communicate between multiple networks. A bridginglgateway function can be packaged as a separate device or it can be combined with a controller. If the device c m perform control as well as protocol translation or routing functions between multiply attached networks then it is said to be a bridgelgateway and control interface. A variation of the example system shown earlier in Fig. 11 in which the 10 and Control networks are combined is shown in Fig. 17. The communication interfaces are packaged into an I 0 and controller communication IF

FIG. 17. Combined 10 and control network architecture.

A TAXONOMY OF DRCS

337

that serves general data traffic requirements. Note also that it is efficient to bypass the scanner for access to the network by control data and that this architecture could support an event-driven processing scheme. Another influence on the overall architecture is the physical topology of the communication system. It can be either bus-based (single or multiple), a point-to-point system or a combination of the two (e.g. switched buses). The bus-based systems can refer to a local backplane bus or to a serial bus as in a local area network (LAN). Typically, bus-based systems are physically able to support message broadcast schemes. Local backplane buses are usually very high speed, relatively short length and able to perform memory operations at the processor speeds. They can be serial (one data line) or parallel (many data lines). Serial buses that are used in LANs are typically slower but capable of extending from a few meters to a few kilometers, and permit larger numbers of nodes to be connected. The actual range depends on the protocol, e.g. a token-bus is unlimited in length (except that performance degrades) while a CAN bus has a basic limit due to end-to-end propagation time. The point-to-point systems are usually organized as: (1) a ring, in which data is circulated to all devices on the net; or (2) switched, to allow messages to be delivered to their specified destinations. Switched topologies can vary from tree-structures to grids to irregular patterns. Techniques such as ATM (Asynchronous Transfer Method) are used in switched fiber optic (or wire) systems at rates of 155 megabits/second and higher. Networks can consist of both bus-based components and point-to-point components. For example, in a multiple bus system, the buses are interconnected by bridges that serve as point-to-point connectors. Note that tightly coupled parallel processing systems often take advantage of topological regularity, e.g. a Hypercube, to efficiently handle routing. At this time, we have not explicitly considered the communication media as an attribute as it is typically wire-based in industrial control applications. In the near future, other forms such as fiber-optic or wireless media may become cost-effective.

4.4

Programming

Many attributes of the programming category have not kept pace with advances in the state-of-the-art in computing systems. This is evident from the fact that the programming methodologies and paradigms have virtually remained unchanged over the last three decades. In industrial control, the programming subsystem must cover a range of activities including designing, developing, debugging and maintaining control programs. In addition, activities such as abnornzal state recovery, alarming and diagnostics are also supported.

338

J. R. AGRE ETAL.

Figure 18 shows the primary functions of the programming category: support for coding of the control algorithm, system testing, diagnostics, exception handling, data management, documentation and synchronization. These functions are clearly implied by most of the previous discussions. A key component of each function is the differences that are imposed by having to run in a distributed environment and what services are provided by the programming languages and operating system. For example, the control algorithm at a given controller may require data from another controller. An issue is whether the data is easily available (transparent services) or the programmer must provide code for accessing the remote data explicitly. System testing, diagnostics, and exception handling are complicated by the fact that data is distributed and determination of the true system state is difficult. Similarly, programming using distributed data can be difficult and standards such as CORBA [4,29] are beginning to emerge that address these issues. Currently, these standards do not address the real-time requirements of automation systems. Documentation includes the program source code and details of system operation. Questions arise regarding where programs and documents reside in the distributed system, as well as issues in version control and concurrent access. Lastly, the degree of transparency in synchronization that is supported by the languages and environment is a key to simplifying distributed programming.

DRCS

Fu

9

-------

\ Implementation

Control Algorithm

Documentation

/

Testing oia Exception Handling

I

/

Lanauaae Language

___---_ -_ _ _ - - - - ,’ II ;

kwpoint

--;a , I , \

,I’

Ladder logic

Statebased

,

I

,,‘ ,,,

r

I

I

I

,\<

’

,

s

\

’ I I

3

,I

’

Function

%\

Domain specific

‘lock Gelaral ,I’ ,’ ‘<\ I,

Alaoritikic

\ / Control application / centric view #

\\

t

,I I

,

,

\

I I

Deve’opment

Code Analvsis

I, \ \

,.

O6ectoriented

I) I)

I

3

>%

I

\

. \ .

\I

S a h Mdsage - h_.. Memotv Parising ~

FIG.18. Programming categories.

Single Viewpoint

Multiple Viewpoints

A TAXONOMY OF DRCS

339

The Language chosen in a DRCS to implement the control algorithm affects the services and tools that must provide support (e.g. operating system, compilers, partitioning, and performance estimation). The IEC 1131 Programming Standards for digital controllers defines four languages: ladder logic, sequential function charts, function blocks, and structured text. The IEC languages operate primarily on fixed-period scanned architectures. However, there are proposed extensions in the IEC 1499 that define an event-driven execution model for function blocks. The dominant language is ladder logic, which evolved from the early electro-mechanical relay-based control systems. Ladder logic is a graphical language that is relatively simple to learn, easy to use and provides a lowlevel ability to react to process changes. It mimics the parallel operation of the relay-based systems on a sequential controller. On the negative side, ladder logic has no notion of state and large ladder logic programs are very difficult to debug and verify. Ladder logic was originally intended to be a behavioral specification-which “accidentally” evolved into a programming language. Sequential function charts, Petri nets, and finite state machines (FSMs) are examples of state-based languages. FSM models are intuitively simple but the size of these models grows rapidly as the size of the control system increases. Hierarchical representation methods, such as hierarchical FSMs, have been used to cope with the large size of state-based models. While such hierarchical methods were well suited for hardware design, their use in software design is still an ongoing research issue. Function blocks are designed as a replacement for ladder logic programming in an industrial environment. They provide a graphical, software-IC style language that is simple to use and understand. Function blocks are modular software units, can contain internal state and represent the inputs and outputs of the function. Libraries of common blocks are provided for building control programs. Other general purpose languages such as FORTRAN or C are employed when GPCs are used as controllers. More recently, object-oriented languages such as C++ or Java are being used to program controllers. Domain-specific languages that are tailored to the needs of particular control problems such as motion control, transfer lines, or assembly machines are also common. These often have graphical user interfaces that make them easy to use. Under the Tools category, development and debugging environments for a DRCS should support modular, independent programming of different controllers. Key distributed programming constructs can be provided to the programmer by distributed system services (described under the control algorithm processing dimension) or they can be embedded in the language

340

J. R. AGRE ETAL.

and implemented by its compiler/linker. For example, location transparency can be provided by a name server or it can be a remote procedure call generated by the compiler. In addition, the programmer must be able to debug and maintain the system by viewing and manipulating the code in many controllers simultaneously. Formal models and theory may help in simplifying this complex task. The architecture design choices made in the control algorithm processing subsystem closely affect the support that can be provided to the programmer. For example, in a tightly coupled parallel system, a shared memory model can be supported that allows the programmer to easily share data structures and I 0 status across multiple controllers without any explicit actions. The shared memory model simplifies many programming, synchronization and debugging problems and is frequently assumed in many distributed control languages (e.g. distributed Grafcet). On the other hand, the message passing model is better suited for the design of loosely coupled systems. In a message passing programming model, any sharing of data between different controllers must be accomplished via explicit messages. The messages can be blocking (requires that a task wait until it receive$ a response) or non-blocking (truly asynchronous); however, debugging and maintaining a collection of asynchronous programs is a non-trivial task. Code analysis uizd generution refers to the degree of automation that is provided through software tools and software services for constructing the control programs. In an automated code generation system, the code for managing and maintaining all the interactions between the controllers (either by message passing, shared memory, or sharing 10 status) is created automatically. Theoretical work by many researchers [9, 10, 24, 331 in the area of discrete event dynamic systems can be considered as positive steps in this direction. The viewpoint is another important aspect of the programming dimension. Most of the current programming environments support a controller centric view. In this view, the needs of the control application must be expressed in terms of the capabilities of the controller. This frequently results in users being coerced into using a low level of abstraction (e.g. relay open, relay closed). When dealing with large control applications, managing such programs is a cumbersome activity. The distributed system can be represented as a single viewpoint, or as multiple viewpoints corresponding to the physical controllers. Relying on the single viewpoint is useful for an overall perspective on system relationships, but may become too complex. In a control applic.ation centric view,users express control needs by describing relationships among objects in the domain of the control application. Control application centric views can be supported with any level of abstraction (i.e. low, medium, or high). However, control application centric views with a low

341

A TAXONOMY OF DRCS

level of abstraction tend to be more akin to a CAD drawing for a printed circuit board than a traditional software program. A high level of abstraction is preferable in a control application centric view. A controller centric view makes the language more general (i.e. the language and programming environment can be used for different control applications). On the other hand, programming a general-purpose control application centric view can be a complex and difficult task, The development of effective programming techniques for DRCS has ongoing research activities in both views. We expect to see major advances in control application centric views for limited control application domains in the near future.

Man Machine Interface

4.5

The purpose of MMI is to assist humans in monitoring the status of, effect changes to, and to configure the DRCS. The primary functional attributes in this category are: display, process control, and configuration, as shown in Fig. 19. The purpose of the display function of the MMI dimension is to transfer process status variables and alarm conditions to a control station and present

DRCS 1 0 Contro/A/g< Processing

\

\ Man Machine Interface

Programming Communications

Implementation /

Display

Monitoring

Devices

_ -_---_ , -. Devices \

OPmerator ;' IF I) Modifications

/\ A

Offline

-- Operator IF

'

with Controller

Display

Operator /A 'I,\ IFand Online ; ~ ~ a l ; h Display i ~Inl~ l AlphaI, L\ numeric ,, \I 't

,

,

Special Devices

I

\

Fg :l:' Computer

FIG.19. MMI categories.

Communication Interface

.,T.. ..

,' I'

10 Network

I

I !

j

Open Network

.-. control Network

342

J. R. AGRE ETAL.

them to the user. Alarms are accommodated with higher priority than other types of status. Specialized graphics-based programs are used to present the status in visual and other meaningful ways that directly correspond to the equipment. Animation is increasingly being employed to show dynamics of the control system or process. The process control function provides mechanisms for the user to enter commands into the control system. These may be normal actions that are used as part of the process control plan or they may be reactions to exceptional conditions such as alarms. Actions related to exceptional conditions would require higher priority, time-critical messages. The coizfiguration function allows the loading and configuring of the control software into the control system. There is generally an MMI device which must be connected to the system and provided with the means for entering the code that will be downloaded to control devices. There is a need to enter an initial configuration of software and parameter values as well as to modify existing software and parameters. The modifications can be accomplished offline and then downloaded to an idle system or they can be injected online into an operational system. Online modifications must be accomplished without disrupting other operations that may be in progress. The MMI requires real-time distributed operating system services to support online modifications and to ensure ease of transferring data to/from operator stations. Operator commands must be guaranteed to be processed within a prespecified window even under abnormal conditions or emergencies. In the DRCS environment, the ability to maintain the real-time operation of the system while executing modifications, commands and alerts is a difficult task. Next we examine MMI implementation choices. There are many packaging options for the operator devices. The display can be either alphanumeric or graphical. Operator interface devices can be separate units such as a pushbutton panel. Frequently, the display and operator interface capabilities are combined into a single special purpose unit, as in a touch panel CRT or more recently as a generic personal computer running a commercial graphical user interface. In some instances, control capabilities are now being integrated with the display and operator input components. This can be an attractive alternative as it eliminates the needs for two separate processing devices (MMI and Controller) in the control system. The comiiiunication interfaces supported by the MMI are important in determining the real-time behavior of the MMI system. If an 10 network interface is employed, then status data and operator commands are conveyed over the I 0 network as if it were sensor/actuator data. If a control network interface is used then the information is conveyed over the control network, thereby permitting a more general message format. It is also

A TAXONOMY OF DRCS

343

possible to use an open network interface, such as Ethernet, to communicate data to/frorn the MMI subsystem if a non-real-time service is sufficient. The configuration devices range from hand-held terminals to GPCs. These typically are capable of tapping into the communication systems and transferring program information to/from remote storage devices and the control system. Specialized software is generally required to set parameters for the particular devices present in the system such as I 0 devices, I 0 modules, adapters, scanners and display devices. Configuration is generally a time-consuming task for the control engineers and many techniques are being investigated to further automate the configuration process.

5. Benefits and Limitations of a DRCS Some of the reasons for considering a distributed system and some resulting consequences are summarized in this section. The physical and logical structure of a DRCS can have a modular design where modules form natural partitions. Heterogeneous components that are chosen to be appropriate for particular subtasks can be included. These components can often be exercised concurrently. This has many immediate advantages such as :

(1) Quicker response times for local loops are possible since decisions are made locally on appropriate processors. (2) A heterogeneous mix of controllers may be used to match the geographical and temporal distribution of industrial automation applications. Individual controllers can be modified and adapted to changing requirements. (3) Overall processing capability is increased due to concurrency on multiple processing elements. (4) Communication loads can be reduced since most of the information can be handled locally as opposed to requiring data transfer to a central location. ( 5 ) The control system is scalable (new processing and communication elements may be added or deleted incrementally); the control application is also scalable (new functionality may be added or deleted incrementally). (6) Fault-tolerant systems with gracefully degrading behavior are achieved by eliminating single-points-of-failure. (7) In a loosely coupled DRCS, maintenance and commissioning activities are simplified by limiting the work to a portion of the system, with minimal side-effects on the other sections.

344

J. R. AGRE ETAL.

(8) Overall system software development is simplified as components can be implemented individually and coupled through well defined interfaces. Building the system out of independent (or nearly independent) modules can reduce system development costs and increase system functionality. However, the complexity of the system is increased and requires careful design and advanced tools to effectively manage the multiple elements. More specifically, a DRCS presents the following challenges: Configuration of components requires additional information on interactions among subsystems. Predictability of the overall system is difficult due to the interactions among concurrent dynamic entities. Synchronization of multiple controllers and devices in a distributed system requires communication and cooperation. Distributed operating systems that support the efficient resource management in large DRCS are still evolving. The true scalability of the distributed system is closely tied to the architecture and the underlying hardware/software infrastructure. The investigation of large complex systems is a relatively new area of theoretical study and many fundamental questions remain. From the above list of benefits and limitations, it is not possible to conclude that a DRCS is always better than a traditional centralized control system. There is a natural tendency to consolidate decision-making in a central place as this apparently simplifies data processing, synchronization, and understandability. However, a large centralized system solution becomes infeasible as the size and functionality of the application increases beyond a certain limit. Large centralized systems become brittle in that they are difficult to modify and maintain, particularly when the application requirements change. On the other hand, a DRCS has the potential to handle greater overall complexity by exploiting modular hardware and software blocks. Yet the complexities of DRCS commissioning and operation need the support of sophisticated tools and techniques.

6. Conclusions DRCS technologies have been studied by research groups and implemented by product groups over the last twenty years. In spite of its evolutionary nature, the acceptance of DRCS in all segments of industrial

A TAXONOMY OF DRCS

345

automation applications is not uniform. Three possible reasons for this nonuniform acceptance are: (1) inadequacies of the current DRCS base technologies, (2) customer skepticism and unfamiliarity with DRCS technologies, and (3) lack of a complete product suite for DRCS. Despite these issues, we believe that DRCS technologies will displace existing control systems technologies in many application areas. In this paper, we have developed a taxonomy that can be used to better understand the spectrum of distributed control system solutions. The DRCS taxonomy is a structure that groups the attributes of a DRCS into five dimensions: 10, control algorithm processing, communications, programming and MMI. Categories within each attribute of a DRCS represent design choices to be made by a control system designer. While this taxonomy is comprehensive, we expect it to evolve into a mature DRCS architecture guide as new technologies are introduced. Key active research areas in DRCS were discussed. One of the principal advantages of DRCS is envisioned to be the ability to build the control system and the automation application incrementally (i.e. add functionality over time). Research directed towards this objective is focused in the areas of autoconfiguration, run-time removal and addition of control or I 0 units, protocols for capability recognition, algorithms for reconfiguration, and algorithms for resource sharing. Another critical research area of DRCS is in fault tolerance and diagnostics. Advanced techniques in model-based supervisory control and cooperative diagnostics are being emerging. Utilizing the potential redundancies in the DRCS for gracefully degrading operations promises new levels of system availability. As the size and complexity of industrial automation applications increase (e.g. large material handling systems), the need for loosely coupled architectures becomes more apparent. The factory configuration will change frequently and the control system must be rapidly reconfigured. The capability of each processing node must be augmented to allow autonomous/cooperative functionality. Research in the area of holonic manufacturing technologies is addressing some of these key challenges. A loosely coupled DRCS presents special challenges because of the asynchronous nature of the system. As the computational capability of an individual node increases, it is possible to exploit this to achieve better local response times for control. Loosely coupled architectures are well suited for a heterogeneous mixture of controller types in the system. These controllers can be selected to match the demands of a specific section of the control application. At the same time, since loosely coupled systems scale well, it is possible to efficiently exploit the geographical and temporal distribution of control applications. In a loosely coupled architecture, synchronizing the operations of the different controllers is difficult and developing distributed control algorithms

346

J. R. AGRE ETAL.

more complex than developing centralized control algorithms or control algorithms for a tightly coupled DRCS. The architecture of the programming dimension in a DRCS must be compatible with the architecture of the other four dimensions shown in Fig. 5. If the control algorithm processing is distributed and the programming is based on a centralized model, problems are introduced with program partitioning, transparent messaging, and synchronization. New research results are needed in this area to reduce the current complexities of DRCS programming. We expect that developments in this area will significantly influence large scale commercial deployment of DRCS technologies. Another emerging factor in the control industry is the cry for open systems. Developments in this area will greatly affect DRCS components and architectures. Market-driven standards are dominating the consumer PC business and will likely impact the control market. Customer expectations are influenced by this and cause a general avoidance of closed architectures. There will be more crossover products from the commercial software market, such as is now happening with MMI software. We believe that DRCS is a natural path to open systems. ACKNOWLEDGMENTS We thank Assad Ansari, Sujeet Chand, Jim Christensen, Mark Duewiger, Ernst Dummermuth, Ondre Flek, and Ken Hall for useful discussions related to the development of this taxonomy.

REFERENCES [ l ] Agre, J., Clare, L., Lee, J., Brandin, B., and Perrone, M. (1995). Autoconfigurable distributed control systems. Proceedings of the International Symjiosium on Autonomous Distributed Systewis ISADS, Phoenix, USA, pp. 162- 168. [2] Agre, J. R., Elsley, G., McFarlane, D., Cheng, J., and Gunn, B. (1994). Holonic control of a water cooling system for a steel rod mill. Proceedings of the Fourth International Corgerence oiz Computer Integrated Manufacturing and Automation Technology, Troy, NY, October, pp. 134-141. [3] Allen-Bradley ( 1987). PLC-5 Family of Programniahle Controllers: Processor Manual, Allen-Bradley. [4] Ben-Naten, R., (1995). CORBA-A Guide to Common Request Broker Archirecture, McGraw-Hill. [S] Bongaerts, L., Valckenaers, P., Van Brussel, H., and Peeters, P. (1997). Schedule execution in holonic manufacturing systems. Proceedings of the 29th CZRP Internutiorid Seminar on Manufacturing Systems, 11-13 May, Osaka University, Japan, pp. 209-215. [6] Bradshaw, A. T. (1997). Fieldbus foundation or foundation fieldbus. Journal of Industrial Autoination and Control, Honeywell, February. [7] Bryan, L. A., and Bryan, E. A. (1987). Programmable Controllers: Selected Applications. IPC/ASTEC, Atlanta, GA.

A TAXONOMY OF DRCS

347

[8] Buchner, M. R., and Lefkowitz, I. (1982). Distributed computer control for industrial process systems: characteristics, attributes, and an experimental facility. IEEE Control Systems Magazine, March, pp. 8-12. [9] Cassandras, C., Lafortune, S., and Olsder, G. (1995). Introduction to the modeling, control and optimization of discrete event systems. In (A. Isidori ed.) Trends in Control: A European Perspective, Springer-Verlag, pp. 2 17-292. [ 101 Chand, S. (1993). Decentralized monitoring and diagnosis of manufacturing processes. Proceedings of the ISADS, Kawasaki, Japan, pp. 384-389. [I 11 ControlNet Specification, (1998). ControlNet International, (www.cor?trolnef.org),Boca Raton, FL. [ 121 DeviceNet Specification Version 2.0, (1997). Open DeviceNet Vendors Association, Boca Raton, FL. [I31 Durfee, E. H., Lesser, V. R., and Corkill, D. D. (1989). Cooperative distributed problem solving. Chapter XVII in (A. Barr, P. R. Cohen, and E. A. Feigenbaum eds.) The Handbook of Artificial Intelligence, Volume IV, Addison-Wesley. [ 141 Gou, L., Hasegawa, T., Luh, P. B., Tamura, S., and Oblak, J. M. (1994). Holonic planning and scheduling for a robotic assembly testbed. Proceedings of the 4th International Conference on Computer Integruted Manufacturing and Automation Technology, Troy, NY, October, pp. 142-149. [15] Gu, G., Krogh, B., and Kindy, J. (1994). R-TICS: A real-time infrastructure for control systems. Proceedings of the 4th International Conference on Computer Integrated Manufacturing and Automation Technology, Troy, NY, October, pp. 358-363. [16] Guillemont, M., Lipkis, J., Orr, D., and Rozier, M. (1991). A second generation microkernel based unix: Lessons in performance and compatibility. Proceedings of the Winter 1991 USENIX Conference, January. [ 171 IEEE (1997). IEEE 1451.2 Draft Standurd for Smart Transducer Interface for Sensors & Actuators-Transducer to Microprocessor, IEEE, August. [18] Jones, C. T., and Bryan, L. A. (1983). Programmable Controllers: Concepts and Applications, IPC/ASTEC, Atlanta, GA. [19] Kopetz, H., Damm, A,, Koza, C., Mulazzani, M., Scwabl, W., Senft, C., and Zainlinger, R. (1989). Distributed fault-tolerant real time systems: The MARS approach. IEEE Micro, 9( l), 25-40 February. [20] Levi, S.T., and Agrawala, A. K. (1990). Real Time System Design, McGraw-Hill. [21] LONBUILDER User’s Guide, 078-0002-01A2, Echelon Corp., Palo Alto, CA. [22] Mori, K., (1993). Autonomous decentralized system: Concept, data field architecture and future trends. Proceedings of the ISADS, Phoenix, USA, pp. 162-168. [23] Popovic, D., and Bhatkar, V. P. (1990). Distributed Computer Control for Industrial Automation, Marcel Dekker. [24] Rmadge, P. J., and Wonham, W. M. (1989). The control of discrete event systems. Proceedings of the IEEE, 77(1), 81-98 January. [25] Sakamura K. and Sprague, R. (1989). The TRON project. BYTE, April, 1989, pp. 292-301. [26] Schwan, K., Geith, A., and Zhou, H. (1990). From CHAOS-base to CHAOS-arc: A family of real-time kernels. Proceedings of the Real Time Systems Symposium, pp. 82-91. [27] SDS Baseline Documentation Version 1.1, (1997). Micro Switch Division, Honeywell Inc., Freeport, IL. [28] Shin, K. G. (1993). HARTS: A distributed real-time architecture. in Chapter 1 of Hard Real-Time Systems, (Y.Lee and C. M. Krishna eds.) pp. 30-49. [29] Siegal, J. (1996). CORBA Fundamentals and Programming, Object Management Group, J. Wiley and Sons.

348

J. R. AGRE ETAL.

[30] Stankovic, J. A., and Ramamritham, K., (1993). The spring kernel: A new paradigm for real-time systems. IEEE Sofmare, 8(3), 62-72 May. (311 Stout, T. M., and Williams, T. J. (1995). Pioneering work in the field of computer process control. IEEE Annals of the History of Computing, 17(l ) , 6-18. [32] Tanenbaum, A. S. (1992). Modern Operating Systems, Prentice-Hall, Englewood Cliffs, NJ. [33] Thistle, J. G. (1996). Supervisory control of discrete event systems. Mathematiral and Computer Modeling, 23(11/12), 25-53. [34] Tokuda, H.,Nakajima, T., and Rao, P. (1990). Real-Time MACH: Towards a predictable real-time system. USENIX First MACH Symposium, October. [35] Vandoren, V. J. (1996). Versatile new controller simplifies network integration. Control Engineering, 43(4), 42-44 March. [36] Wataya, H., Kawano, K., and Hayashi, K. (1995). The cooperating autonomous decentralized system architecture. Proceedings ofthe ISADS, Kawasaki, Japan, pp. 28-34. [37] Wyns, J., Van Brussel, H., Valckenaers, P., and Bongaerts, L. (1996). Workstation architecture in holonic manufacturing systems. 28th CIRP Internatiorial Seminar on Manufacturing Systems, 15-17 May, Johannesburg, South Africa, pp. 220-23 1.

Appendix A This appendix presents characterizations of various types of systems within the DRCS Taxonomy. There is an additional characterization of the overall predictability of the system included at the end.

(1) Single, centralized PLC system with integrated I 0 module, handheld programming terminal, and industrial user interface [3, 181. (2) PLC with local 10, remote I 0 with hand-held configuration terminal, and industrial user interface. (3) PLC with intelligent I 0 module (e.g. motion control module in backplane), hand-held configuration terminal, and industrial user interface. (4) Dual PLCs with adapter mode, local 1 0 , hand-held configuration terminal, and industrial user interface. (5) Multiple PLCs with local 10, remote 10,PC-based configuration terminal, and industrial user interface on deterministic token-bus network. (6) Multiple PLCs with local 10, remote 10,intelligent I 0 controller (e.g. drive), PC-based configuration terminal, PC-based operator IF on deterministic token-bus network. (7) PLC with coprocessor with Ethernet, local 10,remote 10,PC-based configuration terminal, and PC-based operator IF on deterministic token-bus network. (8) PLC with remote I 0 modules, PC-based configuration terminal, and PC-based operator IF all on DeviceNet [ 121.

349

A TAXONOMY OF DRCS

(9) PLCs with remote 10, local 10, intra-controller communication on ControlNet, PC-based configuration terminal, and PC-based operator IF on ControlNet [ l l ] . ( 10) Highly distributed control (conceptual)-PC-based configuration terminal, and PC-based operator IF on DeviceNet. (1 1) Multiple PCs with I 0 modules on Ethernet, separate PC-based configuration terminal, and PC-based operator IF, event-driven, Unix multitasking non-real-time 0s. (12) Multiple PCs with I 0 modules on DeviceNet, separate PC-based configuration terminal, and PC-based operator IF, event-driven, Windows NT multitasking non-real-time 0s. (13) Multiple PCs with I 0 modules, configuration terminal, and operator IF, on DeviceNet, with event-driven, real-time multitasking non-real-time 0s. (14) Open distributed control system (conceptual)-integrated I 0 modules with control, DeviceNet, event-driven real-time OS, event-driven function blocks, I 0 diagnostics, autoconfiguration, separate PC-based configuration terminal, and PC-based operator IF [l]. (15) Hitachi autonomous distributed systems (ADS) [22,36]. (16) Honeywell SDS-PLCs with I 0 modules, PC-based configuration terminal, and PC-based operator IF, all on SDS Net [27]. (17) Open modular controllers on Ethernet (Foxboro), I 0 networks such as DeviceNet, Fieldbus, RIO-PC-based configuration terminal, and PC-based operator IF on Ethernet [35]. (18) MARS Distributed Real-time Control Research System [19]. (19) Lon chip-based controllers (Echelon)-LONWorks network, PCbased configuration terminal, and PC-based operator IF [2 11. (20) Parallel processing system (conceptual)-tightly coupled special purpose processors, remote I/O, simple MMI, complex scheduling and routing in control programs. TABLEA1 CHARACTERIZATIONS OF SYSTEMS WITHIN THE Category/Attribute

I0 *FUNCTIONS *I0 Transduction Type +Analog +Digital *Signal Conditioning 'I0 Diagnostics * I 0 Data Processing

DRCS TAXONOMY

01 02 03 04 05 06 07 08 09 10 1 1 12 13 14 15

X

x x

x x

x x X

x x

x x

x x x x

x x x x

x x

x x

x x

x x x

x x x

x x x

x x x x X

x x

16 17 18 19 20

x x x

x x

x x x

x x x

x x

X

(continued)

350

J. R. AGRE ETAL.

TABLE A1 (CONTINUED) _____

Cdtegory/Attribute *IMPLEMENTATION *packaging +Local 10 tReniote 10 Advpter +Integrated I 0 Device +Integrated I 0 with Controller +Integrated I 0 Module with Controller +Integrated 10 Module +Integrated 10 Adapter with Controller *I0Transfer + Event-dnven t Periodic +Static +Dynamic Control Algorithm Processing "FUNCTION *Algorithm Processing *Process Diagnostrcs *Data Management *System Interfaces *IMPLEMENTATION 'Type of Processing Elements +Embedded Controller +General Purpose Computer +Industrial Controller *Control Processing Architecture +Single Controller (Centralized) +General Purpose Controller +Special Purpose Controller +Parallel Controller +General Purpose Controllers +Cnprocessor +Multiple Controllers (Decentralized) +Hierarchicdl +Federated +Client-Server +Peer-to-peer *Distributed Services *Transparency *Object Naming 'Remote Programming *Atomicity "Synchronization +Event +Time +Clock Time +Master/ Slave +Mutually Synchronized +Logical Time +Shared Resources "Device Operating System +Real-Time +Scanned +Task-based

01 02 03 04 05 06 07 OX 09 10 1 1 12 13 14 15 16 17 18 19 20

x

x X

x x

x x

x x

x x

x

x x

x

x

X

X

X X

X

x X

X

X

X

X

X

x

X

X

x x

x x

x x

x x

x x

x x

x x

x x x

x

x

x

x

x

x x

x

X

x x

x x

x x

x

x x

x

X

x

x

x

x

x

X

x x

x

X

x x x x

x

x x

x

x

x

x

x

x

x

x

x

x

x

x x

x x

x x

x

x

x

X

X

x

x x

x

x

x

x

x x

x x

x

X

X

X

x

x

x

x

x

x

x X X

X

X

X

X

X

Y

x

X

x

x

x

X

x

x

x

X

X

X

X

X

X

x

x

x

x

x

x

x

x

x

x

x

X

x

x

x

x

x

x

x

x

x

x

x

x

x x

x x

X

x

x

x

x

x

x

x

x

X

X

X

X

x x

X X

?

X

X X

x x

x x

x x

x x x

x x x

x x x

x x x

x x x

x x x

x x x

x x x

?

x

x X

X X

x x x

x x

x x

x x

x x

x x

x x

x

x x

x x x

x

x

x

x

x

x

x

x x

x x

?

x x

x

x

x X

351

A TAXONOMY OF DRCS

TABLE A1 (CONTINUED) Category/Attribute ~

~

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

16 17 18 19 20

~

+Preemptive +Non-preemptive +Non Real-Time +Task-based +Preemptive +Non-preemptive Communications *FUNCTIONS *Inter-controller " I 0 data *System data (downloads, etc.) *Bridge/Gateway "IMPLEMENTATION *Protocol *Addressing +Source-based +Destination-based +Content-based *Access method +Polled +Token based +TDMA +Random Access * I 0 Data Types +General Data +Block 1 0 *Interface Packaging +Separate I 0 and Controller Comm IF + I 0 and Controller Comm IF +Bridge/Gateway and Control *Physical topology +Bus +Backplane +Serial +Parallel +Serial Broadcast +Point-to-Point +Ring +Switched +Mixed Programming *FUNCTION *Control Algorithm *Testing *Diagnostics *Exception Handling *Data Management *Documentation *Synchronization *Language +Ladder Logic +State-based (SFC, PetriNet) +Function Blocks +General Purpose

X

x

x

x x x

x x x

x

x

x x x

x x x

X

x

x x

x x x

x x x

x x x

x x x

x x x x

x x x

x x x

x x x

x x x

x x x

x x x

x x x

x x x

x x

x

x x

x

x x x

X

? x

x x x

x x

x

x x

x x

x x

?

?

x

X

X X

X

x

x

x

x x

x x

x x

x

x X X

X

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x x

x ?

x

x

x

x

? x

x

x

x

x x

x

x

x

x

x x

x x

x x

x x

x

x

x

x

x

x

X

x

x

x

x

x

x

x

x

x

x

x x

x x

x ?

X

x x

x x

x x

x x

x x

x x

x x

x x

x x

x

x

x

x

x x x

x x x

x x x

x x

x x

X

x

x

x x x x

x x

x x

x x

x x

x x

x x

x x

x

x x

x x

x x

x

x x

? x

x X

X X

x

x x

x x

x x

x x

X

x

x

x x x

x x x

x x x

x x x

x x

x X

x

x

x

x x

x

x

x

x x

x

x x

x x

x x

x

x x

x x

x x

x x

x x

x

X

X

x

x

x

x x x x x

x x x x x

x x x x x

x x x x

x x x

x x x

x x

x x

x

x

x

x x

x x

x

x x

x X

x

x x

x

x x X

X

X

X

x

x

x

X

x

x

(continued)

J. R.AGRE ETAL.

TABLE A1 (CONTINUED) Category/Attribute +Algorithmic +Object-oriented +Domain specific *Tools +Development and Debug Environments +Shared Mriiiory +Message Passing +Code Analysis and Generation *Programming viewpoint +Controller centric +Single Viewpoint +Multiple Viewpoints +Control Application Centnc

Man Machine Interface "FLINCTION *Display *Process Monitoring *Alarms *Process Control +Normal +Exceptions *Configuration *Initial *Modifications *Online *Offline *IMPLEMENTATION *Operator Devices +Operator Interface +Display +Alphanumeric +Graphical +Operator IF and Display +Special Purpose +General Purpose +Operator IF with Display and Controller "Communication Interface + I 0 Network +Control Network +Open Network Tonfiguration Devices PREDICTABILITY +Deterministic +Quasi-deterministic +Random

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 x

X

x

x

x

x

X

x

x x

x

x x

x

x x

x x

x

x

x

x

x

x

x

x

x

x

x

x

x x

X

x

x

x

x

x

x

x

x x

x

x

x

x

x

x

X

x

x

x

x

x

x

x x

x

x

x

?

x ? x ' x x x x x ? x x x x x

X

x

x

x

x

x x

x

X

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x x x x x x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x x

x x

x x

x x

x x

x x

x x

x x

x x

x x

x

x

x

x x

x

x

x

x

x

x

x

x

x

x

x x

x x

x x

x x

x x

x x

x x

x

x

x

x

x

x

x

x

x

x

x

x

x x

x x

x x

x x

x x

?

!

?

x

x

x

x

x

'! x

x

x

x

? x

? x

? x

x

x

x

x

x

x

x

x x

x x

x x

x x

x x

x x

x x

x x

x

x

x

x

x

x

x

x

x

,)

X

X

? x

x

x

x

x

X

x

x

x

x

x

x

x

x

x

x

x x x

x

x x

x

x x

x x

x x

x x

x x

X

x

x

X

x

x x

x x

x

x x

x x

x

x x

x x

x x

x

x

x x

x

x x

x x

x

X

x

x

x

x

x x

x

x x x

Author Index Numbers in italics indicate the pages on which complete references are given.

A AbeillC, A,, 26,56 Abrial, J.-R., 79,91 Abu-Ghazaleh, N.B., 284,285,286,287, 288,289,290,291,292,295,296, 297,302 Adaptive Solutions, 242,295 Adelson, B., 99, 141 Agarwal, A., 242,248,249,270,275,295, 299 Ageno, A., 12,58 Agerholm, S . , 85,91 Agrawala, A.K., 310,347 Agre, J., 312,315,346 Agre, J.R., 313,346 Aichemig, B.K., 84,91 Albanesi, M., 256,295 Albisser, D., 48,56 Allen, J., 14,56,253,256,258, 259,264, 269,295,296 Allen-Bradley, 346 Almasi, G., 253,296 Al-Onaizan, Y., 40,62 Alonge, A., 66 ALPAC, 3,56 Alshawi, H., 39,56 Amalou, M., 147, 148,188 AMTA Special Interest Group for Interlinguas, 5 1,56 Anderson, C., 153, 188 Anderson, R.J., 86,92 Angus, I., 244, 245, 252,298 Anick, P., 12, 65 Antona, M., 24,56 Appelo, L., 26,28,56 Appelt, D.E., 12,61 Amold, D., 19, 21, 26, 28,41,46,47,48,56, 65 Arnold, R., 107, 112,140 Atherton, T., 267,300 ATLAS 11, 19,56

Auguin, M., 27 1,276,296 Axelrod, T.S., 249,296

B Baecker, R.M., 98, 105, 106,141 Bagley, R.A., 287,296 Baglietto, P., 259,296 Bagrodia, R., 241,297 Baker, J., 36,68 Balcer, M., 149, 150,188,189 Ball, T., 106, 140 Ballard, B., 12,56 Bamberg, P., 36,68 Bar-Hillel, Y., 5, 7,57 Barnes, G., 275,276,300 Barnes, G.H., 251,255,256,263, 296 Barnett, J., 36, 57 Bates, M., 12,30,57 Batory, D., 144, 149, 187,188 Bauer, J., 145,188 Baxter, J., 242, 249,250,270,299 Bazzichi, F., 146,188 Beame, P., 86,92 Beaven, J., 21,26,31, 33,57 Beizer, B., 144,188 Ben-Naten, R., 332, 338,346 Bennett, A., 17,57 Bennett, P., 13,57 Bennett, W.S., 5,7,57 Benoit, J.W., 2,57,62 Bergler, S., 12,57,65 Berlin, L., 237 Bertolazzi, P., 139,140 Berwick, R.C., 57 Bharadwaj, R., 86,92 Bhatkar, V.P., 318,347 Bianchini, R., 249,270,295 Bicarregui, J.C., 88,92 Biggerstaff, T.J., 143,188

354

AUTHOR INDEX

Blank, T., 257,258,296 Blanksteen, S., 12,59 Bliser, B., 26,57 Blaser, B., 12,64 Blevins, D., 259,296 Bloomfield, R., 84,92 Bobrow, R., 12, 30,57 Boguraev, B., 12,57 Bohner, S., 107, 112,140 Boitet, C., 38.57 Bolognesi, T., 72,94 Bongaerts, L., 313,346,348 Booch, G., 156, 158, 161, 188,237 Boyd, J., 266,301 Bradshaw, A.T., 316,331,336,346 Brandes, T., 252,271,296 Brandin, B., 312,315,346 Brent, M., 12,57 Bresnan, J., 62 Brew, C., 31,57 Bridges, T., 240, 2.50, 268,296 Briggs, F.A., 241,257,299 Briscoe, E.J., 12,57 Briscoe, T., 12,58,66 Brock, W., 251,302 Broman, M.O., 12,60 Brookes, T.M., 81,84,89, 92.93 Brooks, F. Jr., 100,141 Brown, C., 119,141 Brown, P.F., 12,34, 3.5,57,58 Brown, R., 40,58 Brown, R.M., 251,2.55, 256,263,296 Bryan, E.A., 318, 330,346 Bryan, L.A., 3 18,330,346,347 Bryant, R.E., 279,299 Buchner, M.R., 304,318,347 Buchsbaum, A.L., 39.56 Bundy, G., 192,237 Bundy, G.N., 237,238 Burger, J., 12.67 Bums, S., 86,92 Burstall, R.M., 72,92 Byrd, R.J., 12,58

C Cahay, M.M., 284,285,286,290,295 Calzolari, N., 12,373 Cant, J., 36.57, 68

Cantoni, V., 241,254,256,266,267,295, 296 Carbonell, J., 2,5, 20, 24, 39,58,64 Carbonell, J.G., 5,7,24,42,58 Carletta, J., 47,58 Carriero, N., 271,296 Casacuberta, F., 64 Cassandras, C., 340,347 Castano, M.A., 64 Castellon, I., 12.58 Cay, S., 194,217,238 Cei, U., 256,295 Celentaoo, A,, 146, 188 Chaiken, D., 249,270,295 Chan, W., 86,92 Chand, S., 340,347 Chander, I., 24,40,62 Chandy, M., 241,296,297 Chang, J.S., 34,58,67 Chapin, J., 242,249,250,270,299 Charlu, D., 272,301 Chamiak, E., 35,58 Cheng, J., 313,346 Chevalier, H., 36, 68 Chodorow, M.S., 12,58 Chomsky, N., 30,58 Chow, T.S., 147, 148,188 Chromatic Research Inc., 242,296 Chung, M.J., 256,261,296 Chung, Y., 256,261,296 Church, W., 12,60 Clare, L., 312, 315,346 Clarke, E.M., 70,85,86, 92 Clermont, P., 266, 267,300 Cocke, J., 34,58 Coglianese, L., 144, 187,188 Cohen, W., 275,277, 278,296,297 Cohen, W.E., 284, 285,287, 288,289,290, 297 Collins, B., 37,58 Collins, R.J., 284,288,290,297 Computing Research Laboratory, 19,58 ControlNet Specification, 335, 336,347 Copestake, A., 12,58,66 Copestake, A.A., 12,57 Corkill, D.D., 313,347 Comell, G., 194,217,238 Craigen, D., 88,92 Crawford-Hines, A,, 146, 175,189 Cray Research Inc., 247,275,277,297

AUTHOR INDEX

Crespi, V., 146,188 Culler, D., 248, 271,297 Cullingford, R.E., 42,58 Cunningham, P., 37,58 Cvetanovic, Z., 244,297 Cypher, R., 244,297

D Dahbura, A.T., 148,189 Damm, A., 310,347 Danlos, L., 28,58 Dasai, T., 28,60 Davies, J., 72,79, 94 Davis, E., 259,296 Davis, N.J., 26.5, 272,301 De Gesu, V., 266,296 Delisle, N., 90, 93 Della, P., 146,188 Della Peitra, S.A., 34,58 Della Peitra, V.J., 34,58 Demedts, A,, 36,57, 68 DeMillo, R.A., 262,297 DeRemer, F.L., 146,188 Devanbu, P., 151,188 DeviceNet Specification Version 2.0, 3 16, 347 Devos, F., 266, 267,300 Dhagat, M., 241,297 Diagne, A.K., 48,64 Di Battista, G.L.G., 139,140 Dichiaro, T., 284, 285,286, 290,295 Dickrnann, L., 48,64 Dietz, H., 275,217, 278,296,297 Dietz, H.G., 252, 261,262,270, 272, 271, 284, 285, 286,287, 288, 289, 290, 297,300 Dietzel, T., 36,57, 68 Doi, S., 34,59 Dolan, W., 31,65 Dornashnev, C., 37,64 Dorninguez, I.Z., 12,64 Dorna, M., 24,33, 39,59,60 Dorr, B.J., 2, 12, 17, 19, 26, 30, 31, 53,54, 57,59,60,62,65,68 Dompdd, J., 28,67 Douglass, R., 244,245,252,299 Duff, M., 244,254,297 Duggan, G., 112,140

355

Duncan, A.G., 146, 147, 149, 175,188 Duran, J.W., 150,189 Durfee, E.H., 313,347

E Eberle, K., 9, 21,60 Eeg-Olofsson, M., 30, 66 Ehrlich, K., 99,141 Eick, S., 106,140 Elder, J., 36, 68 Ellis, J., 247, 297 Elmstrom, R., 84,92 Elsley, G., 313,346 Emele, M.C., 24,33,39,59,60 Emerson, E.A., 85,92 Eoyang, C., 246,301 Eugenio, D.B., 47,59

F Falkedal, K., 46,62 Fan, X., 288,295,297 Farwell, D., 12, 19,24,26,40,60,64 Fass, D., 12,26,68 Felderman, R., 273,297 Fenton, N., 92 Ferretti, M., 254,266,267,296 Ferritti, M., 256,295 Figliulo, T., 187,190 Finger, A,, 145, 188 Finin, T., 41,42,65 Finkel, R., 275,298 Finney, K., 92 Fisher, F., 14, 26,60 Fisher, J.A., 290,297 Fitzgerald, J.S., 72,81, 84,88,89,92,93 Florenza, M., 28, 67 Flynn, M.J., 240,246,297 Ford, L., 104, 105, 106,140 Fountain, T., 244, 254, 255, 256, 257,297, 298 Fox, G., 241,244,245,252,263,298 Francis, N., 267,300 Frank, A., 59 Frederking, R., 24,40,58,60 Frederking, R.E., 24,54,61 Fritsche, G., 266,298

356

AUTHOR INDEX

Froome, P., 84,92 Fuchs, N.E., 85,93 Fujii, Y., 28, 60 Fujimoto, R., 253, 273,298 Fujita, K., 26, 67 Fujiwara, K., 278,299 Fujiwara, S., 147, 148,188 Furuse, O., 37,40,60,67

G Gachot, D.A., 51.60 Gale, W.A., 12, 60 Gamrat, O., 50,65 Gannon, D., 244,245,252,299 Gannon, D.B., 244,302 Garcia-Molina, H., 250,298 Garg, V., 269,296,298 Garlan, D., 90,93 Carman, J., 12,59 Gates, B., 36,57 Gates, D., 12.60 Geith, A,, 310,347 Gelernter, D., 27 1,296 George, C., 72,93 Gerhart, S., 88,92 Gerhart, S.L., 149, 188 Germano, F. Jr., 250,298 Gershman, A.V., 42,58 Gharachorloo, K., 242, 249,250,270,299 Ghedamsi, A., 147, 148,188 Ghezzi, C., 146,188 Ginsparg, J., 12, 60 Giroux, E.D., 253,301 Goguen, J.A., 70, 72, 92, 93 Gokhale, M., 242,298 Goldstien, S., 248, 271,297 Gonenc, G., 148,188 Goodenough, J., 196,237 Goodenough, J.B., 149,188 Goodman, J., 248,250,298 Goodman, K., 2,5,20, 24.64 Goodwin, M., 144, 187,188 Gottlieb, A,, 253,296 Gou, L., 313,347 Gramata, G., 146, 188 Grdnnes, D.J., 37, 64 Green, M.A., 84,92 Greenberg, A,, 260,298

Grishman, R., 12,28,34, 37,40,60,61 Gropp, W., 248,298 Grosz, B.J., 12,61 Grumberg, O., 86,92 Gu, G., 31 1,347 Guha, R.W., 24,63 Gui, Q., 237 Guida, G., 12,61 Guillemont, M., 31 I , 347 Gunn, B., 313,346 Guo, Cheng-Ming, 12,26,68 Gupta, A,, 242,249,250,270,299 Gupta, R., 277,298 Guthrie, L., 12,26,60 Guttag, J.V., 72, 93

H Habash, N., 26,31,53,59 Haines, M., 24, 62 Hall, A,, 89, 93 Hamlet, D., 150,188 Hanson, A,, 266,302 Harada, H., 246,301 Harel, D., 72, 93 Harrold, M.J., 237 Hasegawa, T., 313,347 Hasling, W., 149, 188 Hatcher, P.J., 252, 270, 271,298 Hatton, L., 94 Hatzivassiloglou, V., 24,62 Havelund, K., 72,93 Hayashi, K., 335,348 Hayes, E., 36,57 Hayes, I.J., 85, 93 Hayes, J.P., 244,245,286, 289,298 Heaton, R., 259,296 Heinlein, J., 242, 249, 250, 270,299 Heinrich, M., 242,249, 250,270,299 Heitmeyer, C., 85,86,92,93 Hendler, A., 253,299 Hendler, J., 12,59 Hennessy, J., 242,248,249,250,270,295, 299 Hennesy, J.L., 242,245,246,258,298 Hensgen, D., 275,298 Hens&, D.A., 284,285,286,288,289,290, 295.298.302 Herbordt, M.C., 259,298

AUTHOR INDEX

Herter, C., 276,301 Hewlett Packard, 101,140 Hidano, M., 63 Higinbotham, D., 39, 61 Hill, M., 248,249,298 Hillis, W.D., 246, 252,254, 255,256, 257, 260,298 Ho, C., 256,298 Ho, P., 266,301 Hoare, C.A.R., 72,93 Hogan, C., 14,24,54,61 Holland, V.M., 14,61 Hollinden, D.Y., 284,290,298 Hollinden, N.B., 284, 286,288, 289,290, 302 Holmes, B., 242,298 Honda, H., 278,299 Hopp, K.L., 5 1,61 Hord, R.M., 244,264,299 Homing, J.J., 72,93 Horowitz, M., 242,248, 249,250, 270,295, 299 Horstmann, C.S., 194,217,238 Houston, I., 93 Hovy, E.H., 24,62 Howden, W.E., 144,188 Howe,A.E., 150, 152, 175,189 Howell, C., 192,237 Hudak, P., 280, 281, 287,299 Humphreys, R.L., 41,46,47,56 Hutchins, J.W., 2, 19,40,61 Hutchinson, J., 147,189 Hutchison, J.S.,146, 147, 149, 175, 188 Hwang, K., 241,257,299

I IEEE, 328,347 Iida, H., 37,40, 60, 67 Iida, M., 24,62 Ince, D.C., 146,189 Iobst, K., 242,298 Irwin, M., 242, 258,302 ISATEC, 242,299 Ishiguro, M., 246,301 Ishikawa, M., 39,61 IS0(1995)ISO/IEC 8652,217,229,238 ISO, 72,73,93,94 Ito, Y., 36,57, 68

J Jackendoff, R., 19,30,61 Jackson, D., 70,93, 112,140 Jain, A.N., 39,61 Jamieson, L., 244,245,252,299 Jamieson, L.H., 244,302 Jefferson, D., 272,273,299 Jelinek, F., 34,58 Jeng, B., 150, 190 Jerding, D., 99, 106, 140 Jin, C., 34,62 Johnson, K.L., 249,270,295 Johnson, M., 38,61,247,258,299 Johnson, R., 19,61 Johnson, R.L., 17,57 Jones, C.B., 70,72, 85,86,93 Jones, C.T., 318,330,347 Jones, D., 37,38,61,67 Jones, M.A., 151, 152,189 Jordan, P.W., 2,47,57,59,62 Joshi, A.K., 26,56,62 Joyce, J., 250,299 Justus, C.F., 44, 66

K Kampmann, F., 36, 68 Kane, G., 289,299 Kaplan, R., 21,22,28,62 Kaplan, R.M., 21,22,24,28,62 Kapur, R., 272,301 Karcich, R., 187,190 Kashara, H., 278,299 Kasper, W., 9 , 2 1,60 Kato, M., 251,255,256,263,296 Kawano, K., 335,348 Kelliher, T., 242,258,302 Kelly, V.E., 151, 152,189 Kennedy, K., 261,302 Kent, E., 246, 299 Kerbyson, D., 267,300 Kernighan, B.W., 260,299 Keryell, R., 275,299 Khendek, F., 147, 148,188 Kim, W., 252,299 Kindy, J., 31 1,347 King, G., 34,62 King, M., 2, 19, 44, 46, 61, 62

357

358

AUTHOR INDEX

King, S., 93 Kirby, J., 85,93 Kitano, H., 253,299 Kitchel, S., 240, 250,296 Klavans, J.L., 12,58 Klein, J., 48,64 Kleinrock, L., 272, 273,297,301 Knight, K., 12,24,40,62 Kohavi, Z., 262,279,299 Kohler, W.H., 250,298 Kohyama, H., 37,67 Kolodner, J., 37,62 Komatsu, E., 34,62 Kopetz, H., 310,347 Kosaka, M., 28,34,37,40,60 Koza, C., 310,347 Kranz, D., 242,249,270,275,295,299 Krauwer, S., 26,28,41,56,62 Kravitz, S.A., 279,299 Krishnamurthy, 0..262,297 Krogh, B., 311,347 Kruchten, P., 196,237 Krueger, C., 143,189 Kubiatowicz, J., 249, 270,295 Kuck, D.J., 251,255,256,263,296 Kuehn, T.J., 265,272,301 Kumar, V., 257,300 Kuskin, J., 242,249,250,270,299 Kuszmaul, B.C., 280,299

L LahdW, B., 85, 93. Ladd, D., 112,140 Lafferty, J.D., 34.58 Lafortune, S., 340,347 Lagemaat, J., 72,94 Lai, J.C., 12,SH Lamport, L., 273,299 Landsbergen, J., 28,62 Lange, J.M., 12,64 Lano, K., 79,93 Laraen, P.G., 72, 8 1,84,85,89,91,92, 93 Larus, J., 248, 249,2Y8,299 Lassen, P.B., 84,92 Lavin, M., 254, 266,300 Lee, J., 312, 315,346 Lee, Jye-hoon, 30,59 Lefkowitz, I., 304, 318,347

Lehmann, H., 12,40,62,64 Lenat, D.B., 24,63 Lesser, V.R., 313,347 Levi, S.T., 310,347 Levialdi, S., 241, 254, 266, 296 Levin, R., 237 Li, H., 254, 256,257,266,300 Ligocki, T., 266,302 Lim, B-H., 242,249,270,275,295,299 Lin, D., 30,59 Lindsay, P.A., 88, 92 Ling, R., 266,302 Lipkis, J., 311,347 Lipovski, G., 272,301 Lipton, R.J., 262,297 Liskov, B., 237 Litman, D., 15 I , 188 Litt, J., 254, 301 Littman, M.S., 284,286, 289, 290,300 Loehr, D., 51,65 Lomow, G., 250,299 LONBUILDER User’s Guide, 347 Long, D.E., 8 6 9 2 Lonsdale, D., 12,63 Loyall, J., 110, 1 1 1, 112, 141 Lozano, M.C., 5 1,63 Lubachevsky, B., 260,298 Lubeck, O., 246,301 Luh, P.B., 313,347 Luk, S.K., 24,62 Lumia, R., 246,299 Lundstrom, S., 275,276,300 Luqui, 70.93 Lusk, E., 248,298 Lytinen, S.L., 5.63

M McCord, M.C., 28,63 McDonald, J.E., 12,26,68 McFarlaine, D., 313,346 Machine Translation, 2,63 Maciejewski, A.A., 244,300 Mackenzie, K., 249,270,295 McLean, I.J., 37, 39,63 McNaught, J., 17.57 MacReynolds, R., 251,302 Mahat, J., 266, 267,300 Mahesh, K., 24,63

AUTHOR INDEX

Manber, U., 275,298 Mandel, M., 36,68 Manganaro, L., 36.68 Manning, S., 252,300 Manohar, R., 241,296 Maresca, M., 254,256,257,259,266,296, 300 Margolis, T., 36,68 Maria Otero, 5 1,65 Marti, M.A., 66 Martin, P.A., 12,61 Maruyama, F., 28,60 Maruyama, H., 37,63 MasPar, 251,256,257,258,260,289,300 Massingill, B., 241,296 Mathisen, S., 110, 111, 112,141 Mattox, T., 277,297 Maurer,P.M., 148, 149, 175,189 Maxwell, D., 2,63 Meiron, D., 241,296 Mellor-Crummey, J.W., 249,300 Mendez, R., 246,301 Mercer, R., 12,34,58 Mercer, R.L., 12,63 Merigot, A,, 266,267,300 Metcalf, C.D., 284, 286, 289,290,300 Meyer, B., 194,217,237 Meyer, D., 252,300 Migdaloff, B., 12,59 Migliardi, M., 259,296 Miller, K.J., 12,51,63,68 Miller, R., 257,300 Milner, R., 72,93 Misra, J., 273,300 Mitamura, T., 12, 19,24, 39,58,63,64 Mitrani, I., 260, 298 Mittendorf, E.P., 14,63 Modet, A., 12, 93 Modugno, F., 86,92 Moffat, D., 48,56 Mogi, A., 278,299 Mohr, E., 280,281,287,299 Monahan, B., 84,92 Montemagni, S., 12,63 Moore, J.D., 47,59 Moore, R., 88,92 Mori, K., 335,347 Moriconi, M., 112,141 Mosconi, M., 256,295 Moulding, M., 194, 195,237

359

Mraz, R., 145, 150, 152, 153, 161, 171, 174, 175,188,189 Muhammad, T., 277,297 Mukherjee, P., 84,93 Mularz, D., 192,237 Mularz, D.E., 237 Mulazzani, M., 310,347 Muraki, K., 28,34, 37,59,64 Myers, G.J., 149, 189 N Nagao, M., 24,37, 38,43,63,64,66,67 Naito, S., 189 Nakahira, D., 242,249,250,270,299 Nakajima, T., 311,348 Narita, S., 278,299 Nash, J., 257,301 Nation, W.G., 244,300 Neff, M.S., 12,58,64 Negrini, R., 266,296 Nerbonne, J., 48,64 Netter, K., 21, 22,28,48,62,64 Newman, I., 257,300 Ney, H., 64 Nichols, M.A., 252, 270,272,300 Nickolls, J., 255, 257,300 Nielsen, M., 72,93 Niessen, S., 64 Nilsson, M., 280,284,285,300 Nirenburg, S., 2,5, 12, 20,24, 37,40,60,63, 64,65 Nomiyama, H., 34, 37,64 Notkin, D., 86,92 Nowatzyk, A.G., 257,300 Ntafos, S., 150,189 Nudd, G., 267,300 Nyberg, E., 12, 19,24,39,58,63,64

0 Oard, D.W.. 54,59,64 Oblak, J.M., 313,347 Odijk, J., 28,62 Ofelt, D., 242, 249, 250, 270,299 Ogino, S., 63 Ogura, A., 278,299 Okumura, A., 28,37,64

360

AUTHOR INDEX

Olsder, G., 340, 347 Olsen, M.B., 12, 3 1,65 O’Malley, 0.. 150, IS9 O’Malley, S., 144, 149, 187, 188 Onyshkevich, B., 12,24,65 Orr, D., 311,347 Ostrand, T., 149, 150,188,189 Ott, N., 40, 62 Ousterhout, J., 102,141 Owens, R., 242,258,302 Owre, S., 86.93 Oxford Micro Devices Inc., 242,301

P Packwood, R., 267,300 Paggio, P., 13,57 Palmer, M., 12,24,41,42,65 Pappas, M., 261,302 Parhami, B., 242,301 Paris, C., 43, 65 Paris, N., 275,299 Parkinson, D., 254,301 Patterson, D.A., 242, 245, 246, 258. 298 Peeters, P., 313,346 Pennington, N., 09, 141 Pereira, F.C.N., 12,61 Perlis, A.J., 143, 188 Perrone, M., 312,315,346 Pfister, G . , 247, 301 Pfleeger, S.L., 94, 195, 198,237 Philippsen, M., 276,301 Plate, T., 12,26,68 Popovic, D., 318,347 Pratt, M., 253, 301 Price, B.A., 98, 105, 106,141 Prins, J., 26 I , 301 Prucnal, P.R., 257,300 Puerta, M.C., 50.65 Pugh, J.M., 17,57 Purdom,P., 145, 146, 148, 175,189 Pustejovsky, J., 12,57, 65

Q Queille, J.-P., 07, 112, 141 Quinn, M.J., 252, 270, 271, 298

R RAISE Language Group, 72,79,94 Ralston, T., 88.92 Ramadge, P.J., 340,347 Ramamritham, K., 310,348 Rao, P., 3 1 I , 348 Reeder, F., 51,65 Reese, J.D., 86,92 Reeves, A., 260,302 Reghizzi, S., 146,188 Reif, J., 259,296 Reinhardt, S., 248, 249,298 Reisis, D., 257,300 Retinger, C.-T., 51,65 Ribas, F., 12,58 Richardson, D., 150,189 Richardson, S.D., 37,65 Rigau, G., 12, 58 Risernan, E., 266,302 Ritchie, B., 88, 92 Ritchie, D.M., 260,299 Rizk, O.A., 12,58 Rockoff, T., 258,301 Roderick, L., 38, 61 Rodriguez, H., 12,58 Rodrique, G., 253,301 Rohrer, C., 9,21,60 Rook, P., 237 Roossin, P.S., 34,58 Rosenblum, M., 242,249,250,270,299 Rosetta, M.T., 28, 65 Roudaud, B., SO, 65 Rozier, M., 311,347 Rushby, J., 86,93 Rutenbar, R.A., 279,299

S Sabnani, K.K., 148,189 Sadler, L., 21,23,26,28,41,46,47,48,56, 65 Sager, J.C., 17,57 Saiedian, H., 70, 94 Saito, H., 38,65 Sakamura, K., 310,347 Samiotu, A , , 12,58 Samvelian, P., 28,58 Sanders, P., 284,301

AUTHOR INDEX

Sanfilippo, A., 66 Sanz, J., 244,297 Sato, S . , 37,66 Savoretti, F., 146, 188 Sayward, F.G., 262,297 Schabes, Y., 26,56,66 Schaefer, C., 238 Schaefer, D., 266,301 Schank, R.C., 19,66 Schauble, 14,63 Schauser, K., 248,271,297 Schenk, A,, 28,62 Schimmel, D., 253,256, 258,259,264,269, 295,296,298 Schimmel, D.E., 269,301 Schlesinger, C., 14,61 Schubert, K., 2, 19,63,66 Schuster, A,, 257,300 Schwall, U., 26,57 Schwan, K., 310,347 Schwederski, T., 265,272,301 Science Applications International Corporation (SAIC), 5 1,66 Scott, B.E., 51,66 Scott, D., 43,65 Scott, M.L., 249,300 Scwabl, W., 310,347 SDS Baseline Documentation Version 1.1, 347 Sejnowski, M., 272,301 Senft, C., 310,347 Shafer, S., 144, 187,188 Shankar, N., 86, 93 Sharp, R.M., 30,66 Shell, P., 12, 60 Shen, J., 247,302 Shen, S., 272,301 Sheridan, P., 14,63 Shieber, S.M., 26, 66 Shin, K.G., 310,347 Shiwen, Y., 48,66 Shneiderman, B., 144,189 Shneier, M., 246,299 Shu, D., 257,301 Shu, W., 281,301 Shumway, M., 144, 153,189 Siegal, J., 332, 338,347 Siegel, H.J., 244,252,255,257,265, 270, 272,300,301,302 Sigurd, B., 30, 66

361

Simmons, M., 246,301 Simoni, R., 242,248,249,250,270,295, 2 99 Sinha, S., 237 Skjellum, A., 248,298 Sklar, D.F., 119,141 Slind, K., 250,299 Slocum, J., 2, 44,66,67 Slotnick, D., 251,302 Slotnick, D.L., 251,255,256,263,296 Slusher, C.E., 284,286,288,289,290,302 Small, I.S., 98, 105, 106,141 Smith, J., 261,301 Snyder, A,, 237 Snyder, L., 244,302 Soloway, E., 99,141 Somers, H., 2, 37,38,39,61,67 Sorners, H.L., 17,57 Spadafora, I., 146,188 Sponaugle, J., 275,277,278,296,297 Sprague, R., 310,347 Stankovic, J.A., 310,348 Staples, M., 119,141 Stasko, J., 99, 104, 106,140,141 Steele, E., 36, 68 Steele, G.L. Jr., 252,260,298 Stefanelli, R., 266,296 Steiner, E., 54,67 Stokes, R.A., 251,255,256,263,296 StorageTek, 154,189 Storrer, A,, 26,57 Stout, Q., 256, 257,300 Stout, T.M., 318,348 Stroustrup, B., 194,217,238 Stumberger, D.E., 12,56 Su, K.Y., 34,58,67 Sugimura, R., 39,61 Suh, S., 30,59 Sumita, E., 37,67 Sumita, H., 37,67 Suzuki, K., 28,60

T Tamura, S . , 313,347 Tanaka, H., 280,284,285,300 Tanenbaum, A S., 311,332,348 Tanirnoto, S., 266,302 Tasso, C., 12,61

362

AUTHOR INDEX

Taule, M., 66 Taylor, R., 150,188 Templeton, M., 12.67 Thinking Machines Corporation, 250, 272, 275,271,302 Thistle, J.G., 340.348 Thomas, S.C., 12,31,65 Thomason, R.H., 47,59 Thompson, B., 12,67 Thompson, F., 12.67 Thompson, H.S., 23,65 Thurmair, G., 28,67 Tichy, W., 216,301 Tillmann, C., 64 Tittle, C., 150,189 Tokuda, H., 31 1,348 Tombe, L. des, 19,26,28,56,61,67 Tomboulian, S., 261,302 Tomita, M., 2,5,20,24, 38,64,65 Traum, D., 26,31,53,59 Trujillo, A,, 12, 26,67 Tsoulakas, M.Z., 150,189 Tsujii, J., 24,26,38,56,61,67 Tsunoydnia, M., 189 Tuck, R., 252,299 Turner, D.A., 280,302

U Uhr, L., 244,302 Unger, B., 250,299 Unger, S., 251,254,302 Upchurch, E., 272,301

v Valckenaers, P., 3 13,346,348 Vallejos, C., 266,301 Van Brussel, H., 313,346,348 van der Eijk, P., 28,67 Vandenvende, L., 12, 37,63,65 Vandoren, V.J., 348 van Genabith, J., 59 van Noord, G., 28,67 Vans, A.M., 99,141 van Slype, G., 40.43.67 Vasconcellos, M., 54,68 Vaudin, G., 267,300

Vauquois, B., 68 Vidal, E., 64 Vissers, C.A., 12, 94 Vogel, S., 64 Voidrot, J.-F., 97, 112, 141 von Bochman, G., 147, 148,188 Von Eicken, T., 248,211,297 von Hanxleden, R., 261,302 von Mayrhduser, A., 99,141, 144, 145, 146, 150, 152, 153, 171, 174, 175, 187, 188,189,190 Voss, C., 12,26,60,68 Voss, R., 14,26,60 Vossen, P., 12,58

W Wagner, K., 72,93 Waibel, A,, 40,68 Walls, J., 145, 171, 174, 189 Wang, J., 287,302 Wang, Ye-Yi, 40,68 Warschko, T., 276,301 Wasserman, H., 246,301 Watanabe, H., 37,63 Wataya, H., 335,348 Way, A,, 48,56 Wedekind, J., 21,22,24,28,62 Weems, C., 266,302 Weems, C.C.. 259,298 Wehrli, E., 30, 68 Wehrmeister, R., 240, 250,296 Weinberg, A., 12,59 Weiser, M.,110, 112,141 Weyuker, E.J., 150,190 Whitelock, P., 20,21, 31,33, 38,61,68 Whitney, R.A., 24,62 Wild, C., 153,190 Wilks, Y., 12, 19,24,26,36,40,60,64,68 Willebeek-LeMair, M., 260,302 Williams, T.J., 318,348 Wilsey, P.A., 284,285,286, 287, 288, 289, 290,291,292,295,296,297,298, 302 Wing, J., 70, 72,93,94 Wing, J.M., 70,72, 86,92,93 Winkler, T.C., 112,141 Winner, B., 192.237 Witkam, T., 2.63

AUTHOR INDEX

Wolfe, A,, 247,302 Wong, H., 36,68 Wonham, W.M., 340,347 Wood, D., 248,249,298 Woodcock, J.C.P., 72,79, 94 Wu, D., 12,36,40,68 Wu, L., 120,141 WU,M-Y., 281,301 Wu, Z., 41,42,65 Wyns, J., 313,348

X Xia, F., 39,56 Xia, X., 12,68

363

Y Yamabana, K., 28,37,64 Yamada, K., 24,62 Yamron, J., 36,57,68 Yasuhara, H., 34, 37,62,68 Yeung, D., 242,249,210,275,295,299 Z

Zaenen, A., 21,22,28,62 Zainlinger, R., 310,347 Zajic, D.M., 12,5 1,63, 68 Zavidovique, B., 266,261,300 Zeil, S.J., 153, 190 Zhou, F., 242,258,302 Zhou, H., 310,347

This Page Intentionally Left Blank

Subject Index

A A priori domain analysis, 155-71 Abstraction, 71 Access method, 335 Access patterns, 245 ACCION International, 5 1-2 ACSLS, 181 Action classes, 167 Ad hoc exception handling, 196 Adaptability, 308 Adapter, 323 Adapter backplane, 323 Adaptive CNAPS, 242 Address masking scheme, 255 Addressing scheme content-based, 335 destination-based, 335 source-based, 335 Agile manufacturing systems, 308-9 Air traffic control, 89 Algorithm visualization, 98 Amethyst, 105 Amoeba system, 31 1 ANIM, 105, 106 Anonymous exceptions, 217,228-9 Application domain-based testing, 144 Architectural design level, 198 Artificial intelligence (AI), 1 in test generation, 150-3 ATM (Asynchronous Transfer Method), 337 Atomicity service, 332 Attributed grammar, 146-7 for sort routine, 147 Automated cartridge system (ACS), 154, 162, 182 Automated test generator, 187 Automatic Language Processing Advisory Committee (ALPAC), 3 , 4 Automatic programming, 31.5 Autonomous cooperative systems, 3 13

B BALSA, 105 Barrier synchronization protocols, synchronization architectures based on. 275-8 Behavior rules, 170 Bilingual entries for head-switching divergence, 32-3 Block I 0 transfer, 335-6 Block-Start constraint, 314 Block statements, 226-7 Bottom-up model, 99 Bridge/gateway and control interface, 335, 336 B’VITAL, 50

C Call-graph, 101, 114-16, 121, 123-8, 132-5 internal detail, 118 modularity, 116 Candide French-English Machine Translation Project, 34-5 Cartridge Access Port (CAP), 154, 182-3 test subdomain, 174-5 Case Filter, 30 CAT, 50 Categorical divergence, 10-1 1,27-8 Category-partition testing, 149-50 CDIS, 89 Central Control Algorithm (CCA), 283-8, 33 I execution, 284-5 interpreter structure, 285-6 maximizing the overlap in the execution of instructions, 286-7 optimizing the interpreter loop, 285-90 variable instruction issue interpreters, 287-8 Centralized dimension, 316

365

366

SUBJECT INDEX

Centralized 10, 316-17 Change impact analysis, 97 Change Impact Viewer (CIV), 97, 119-28 class views inter-class relational view, 120-1 intra-class relational view, 122 comparison with other systems, 132-7 evaluation of results, 128-38 extensions, 138-40 file views inter-file relational view, 122-6 intra-file relational view, 126 future work, 138-40 impact analysis, 127-8, 137-8 intuitiveness, 129-30 open problems, 138-40 overall evaluation, 129-32 scalability, 130-2 static analysis, 119 usefulness, 129 visualization features, 1 19-26 Change-Of-State (COS), 328 CHAOS (Concurrent Hierarchical Adaptable Object System), 310 Chorus system, 3 11 Chromatic mPACT, 242 CICC system, 3 18 CIDC DRCS, 322 CIDC system, 318 CLASP, 151 Class-inheritance graphs, 101 Clock time, 333 CM-2, 246 CM-5, 278 Code analysis and generation, 340 Command language, 165 Command templates, 186 Common sub-expression induction, 261 Complex contextual ambiguity, 8 Complex semantic ambiguity, 7 Complex systems, 309 Computing, emerging technology trends, 309-10 Concurrent-interpretation model, 278-92 early experiments, 279-81 Conflational divergence, 1I Constraint-based MT (CBMT) techniques, 21-4 Constraint-based programming, 3 14 Context-free grammar, 146

Contextual ambiguity, 7-8 Control-application-centric programming, 313-14,340 Control asynchrony management, 239-302 Control network, 331 Control organization, 245-7 Control parallelism, 244-5 Control processors (CPs), 263,268 Control system architecture evolution, 318-22 architecture trends affecting, 304- 16 historical trends, 319 lifecycle, 312 Controller backplane, 323 Controller centric view, 340 Controller communication interface (Control Comm IF), 324 Controller network, 324 Cray T3D, 247

D Data management, 330 Data mapping, 245 Data masking scheme, 255 Data-parallel execution model, 274 Data-parallel programming model, 259-62 Data parallelism, 244-5 Data stream, 246 Data type invariants, 74 Database query/update system, 153 Declaring an exception, 194 Default decisions, 199 Default handlers, 227-8 Def/use graphs, 121, 124 Dependent tasks, 233-4 Derived types, 231-2 Detailed design level, 198 Deterministic Finite State Automata (DFSA), 262 Deterministic systems, 324 Device operating system, 333 Diagnostics, 325, 326 Dialogue-based MT (DBMT), 38-9 DICC DRCS, 318-22 DICC system, 318 DIDC DRCS, 320-1 DIDC system, 318,323 Digitization, 306

SUBJECT INDEX

Direct mapping, 15 Distinguished values, 217-19 Distributed control system (DCS), 318 Distributed diagnostics, 327 Distributed dimension, 316 Distributed 10, 317 Distributed memory, 248 Distributed Real-time Control System. See DRCS Distributed real-time operating system research, 310-11 Distributed services, 332 Distributed shared memory, 248 Document publishing tools, 13-14 Domain analysis, actions on objects, 165 Domain-based testing, reuse applications, 184 Domain knowledge, 151 Domain models building, 155-72 for system testing, 143-90 reverse engineering, 171-2 Domain reuse, 180-3 example, 183 Domain-specific languages, 339 DRCS, 303-52 autoconfiguration, 31 1-12 benefits, 343-4 communications, 334-7 control algorithm processing, 328-34 control processor architecture, 33 1 controller integration and packaging, 330-1 development and debugging environments, 339 diagnostics, 312 dimensions, 3 17 fault tolerance, 312 general technology trends impacting, 305-9 I 0 dimension, 325-8 language, 339 limitations, 343-4 man-machine interface (MMI), 341-3 overview, 304 programming, 337-41 taxonomy, 316-43 use of general purpose components, 307 Duplicate actions, 199 Dynamic barriers, 277

367

Dynamic periodic system, 328

E Elaboration failure, 23 1 EPGA, 266 Erroneous data, 194 Error handling, 217 Error states, 194,217 EUROTRA, 3-4 Event driven I 0 synchronization, 328 Event service, 332-3 Example-based MT (EBMT), 37 Exception category, 202 declarations, 230 definition, 194 granularity, 202 maps, 215-16 raising, 194 roles, 195 semantics, 202-10 Exception-based ineffective design patterns, 221-9 Exception-handling, 194,223-8 concepts, 193-5 definition, 193 design patterns, 191-238 detection, propagation and recovery responsibilities, 199-200 ineffective, 221-9 design strategies, 197-221 allocation of responsibility, 197 auxiliary functions, 200-2 coarse-grained exceptions, 205-7 combining origin-, cause- and recoverybased exceptions, 209-10 control-based approach, 219-20 data-based approaches, 217-19 detection functions, 200 exception semantics, 197 fine-grained exceptions, 207-9 global design patterns, 197 local design patterns, 197 recovery functions, 200 value-based approaches, 221 design structures, allocation of responsibility, 198-202 functions, 194-5

368

SUBJECT INDEX

lice cycle, 195-7 Exceptional condition, 193, 194 Execution autonomy, 291 Explicit raising of predefined exceptions, 222-3

Goofy, 104-5 Grammar-based test generation, 145-7 Granularity of tasks, 245 Grosch’s Law. 307

H F Factorization. 2 10- 15 Failure to rewme noiinnl processing, 217 Feature-interaction based ineffective design patterns, 22 1,229-37 File-inclusion graphs. 101 Firewalls, 225 Fixed-partition barriers, 276 Formal methods, 69, 7 I industrial applications, 88-90 light, 86 Formal models analysis techniques, 79-88 animation, 84-5 proof, 86-8 recent applications, XX-YO review of example model, 78-9 syntax, 84 tcsting, 84-5 type checking, 84 Frequency-based test generation, 148-9 Full barriers, 276 Function blocks, 339 Function fall-through, 223-4 Functional parallelism, 244-5 Functional testing, 149 Fuzzy-harrier implementation, 277

G CAM pyramid, 266 General concurrent interpretation, 283--4 General global partitionability, 267-8 Generalized m a p , 216 Generally Partitionable Architecture (GPA), 267-8 Global design patterns, 2 10- 17 Global virtual time (GVT), 273,274 Globalink, S3 Globally partitionable MSIMD machines, 292

Handling an exception. See Exceptionhandling Hard real-time system, 324 Hardware barrier niachines. 275-8 HARTS (Hexagonal Architecture for Real Tirue Systems), 3 10 Head-switching divergence, 10. 22-3, 28-9, 32 Hierarchical architectures, 266 Highly distributed control system, 3 15-16 Holonic concept, 3 13 Horizontal partitioning, 2 10, 2 I S Host Software Coniponerit (HSC), 154 HP SoftBench Static Analyzer, 101-2, 132-6 HSC-ACS, 157, 159, 165, 168

I IEEE 145 1.2 Smart Transducer Inlerfaces, 328 lmagix 4D, 102-4, 136-7 Impact analysis, 97, 107-14 features, 127-8 Implicit anonymous exceptions, 229 Inadvertent mappings. 225-6 Incense, I05 Incompatible coi~ventions,200 Jnconsistent assumptions, I99 Infinite task server, 233 Information overload, 100, 114- 15 Inspection, 83-4 Instruction stream, 246 Integrated I 0 device, 326, 328 Integrated 10 module, 331 Integrated system components, 327 Intelligent 10 devices, 320, 328 Interchangeable components, 308 Inter-controller traffic, 334-5 Interlingual representation, 19-20 Internal coiisislericy, 79-80

SUBJECT INDEX

Interoperability, 307 Interpreted instruction set, 283 Intracommand rules, 167 I0 centralized, 316-17 distributed, 317 I 0 chassis, 323 I 0 Comm IF, 323,326 I 0 connects, 323 I 0 data, 334, 336 processing, 325, 326 types, 335 I 0 device-module-interface, 328 I 0 devices, 323 integrated, 326, 328 intelligent, 320, 328 remote, 319 I 0 diagnostics, 327 I 0 dimension, 325-8 I 0 functions, 327 implementation, 326 I 0 modules, 323, 326,327 integrated, 331 I 0 network, 323, 326, 331 I 0 network communication interface ( I 0 Comm IF), 323, 326 I 0 synchronization, 328 I 0 transduction, 325 I 0 transfer, 328, 335-6 IOC classification, 3 18 IOC Taxonomy, 317-18,322 ISATEC Systola, 242

K KITSS, 151-3 Knowledge-based machine translation (KBMT), 24-6

L Label parameters, 220 Ladder logic, 339 Large-grained interpretation, 28 1-3 Lexical ambiguity, 6 Lexical-based MT (LBMT), 26-8 Lexical functional grammar (LFG), 22 predicate-argument relation, 23-4

369

Lexical invariance, 43 Lexical representations for thematic divergence, 3 1 Lexical selection, 8-9 Library Storage Modules (LSM), 154, 159, 161, 162 Limited Dynamic Partitioning, 265 LINGSTAT, 36 Literal translation, 29 LMUs, 174 Local area network (LAN), 337 Local design patterns, 217-21 Local virtual time (LVT), 273, 274 Logic circuits, 280 Logical processes (LPs), 273 Logical time, 333 LogoMedia, 106 Loop flattening, 261

M MACH multiprocessor operating system, 311 Machine translation (MT), 1-68 architectures, 14-20 black-box evaluation, 41-2,44 constraint-based, 21 -4 developer’s evaluation, 49-50 dialogue-based, 38-9 direct architecture, 14-16 end-user evaluation, 48-9 evaluation approaches, 41-6 evaluation challenges, 40-1 evaluation criteria, 42-5 evaluation examples, 48-54 evaluation of systems, 40-54 evaluation techniques, 46-8 example- (or case-/memory-) base (EBMT), 37 glass-box evaluation, 42 history, 3-5 hybrid paradigms, 39-40 interlingual architectures, 19-20 knowledge-based, 24-6 lexical-based, 26-8 LFG-based, 22-3 linguistic-based paradigms, 21-33 linguistic considerations, 5-1 1 neural network-based, 39

370

SUBJECT INDEX

non-linguistic-based paradigms, 34-9 operational considerations, 11-14 overview, 1-2 principle-based, 30- 1 research systems, 20-40 researcher’s evaluation, 50-4 rule-based, 28-9 shake and bake, 3 1-3 statistical-based, 34 test-suite construction and evaluation, 47-8 transfer architectures, 16-19 types of challenges, 5-14 types of systems, 15 Mainstream massive1y-parallel processing, 24 1 Man-machine interface (MMI), 316, 330, 341-3 Manufacturing Execution Systems (MES), 313,330,335 Mapping strategy, 215 MARS system, 310 Maruti system, 310 Maskable (static) barriers, 276-7 Masking scheme, 255 MasPar MP-l/MP-2 machines, 257, 258, 289 MasPar Parallel Application Language (MPL), 240,289 Master-slave controller architecture, 320 system, 321,333 Memory Data Register (MDR), 258 Memory indirection, 255 Memory organization, 247-8 Meta state, 262 MGAP-l/MGAP-2,242,257-8 MIDI, 106 MILAN, 286 MIMD machine, 247 advantages, 249 classification, 246 disadvantages, 249-50 distributed memory, 249 organization, 247-50 overview, 240-3 shared memory, 248 MIPS RS-3000 RISC instruction set, 286 MISD, 246 Missing actions, 199 Mitre, 48,50

MMI (man-machine interface), 316, 330, 341-3 Mode parameters, 158, 160 Model checking, 85-6 Model comparisons, 82-3 Model-oriented specifications, 72-9 analyses, 79-80 Modeling, 71 data, 73-5 functionality, 75-7 Moore’s Law, 305-6 MOUNT-DISMOUNT script rule, 169-70 Multi-language interaction, 225 Multi-path propagation, 232 Multiple controller architectures, 33 1-2 client-server, 332 federated, 332 hierarchical, 332 peer-to-peer, 332 Multiple-Instruction streams Multiple-Data streams (MIMD) machines. See MIMD machines Multiple-SIMD (MSIMD) model, 263-9, 278 Multiple system configurations, 185-6 Mutually synchronized systems, 333

N Nested block statements, 226-7 Networked controllers, 321 Neural-net test generation, 153 Neural network-based MT (NBMT), 39 Non-Deterministic Finite State Automaton (NDFSA), 262 Non-deterministic systems, 324 Non-parameters, 158 Non-real-time system, 333 Null handlers. 224-5

0 Object attributes, 158 Object element, 158, 159 analysis, 172 associated with selected commands, 168 Glossary, 161 type, 17 1

SUBJECT INDEX

Object hierarchy, 161 Object orientation, 313 Object-oriented analysis/design (OOA/OOD), 156-8 Object-oriented languages, 339 Open systems, 307-8 Open Systems Interface (OSI), 335 OPSILA architecture, 271 Optical character recognition (OCR), 13-14 Optimizations, 234 Overflow, 21 1 Oxford A236,242

P Pangloss system, 40 PAPERS project, 277 Parallel algorithms, 244-5 Parallel architectures, 245-7 Parallel controller, 33 1 Parallel Discrete-Event-Simulation (PDES), 272 Parallel processing, 240,242, 244 Parallelism degree, 245 Parameter attributes, 158, 159 Parameter binding rules, 170 Parameter inheritance rules, 164 Parameter value selection, 170- 1 Partial domain reuse, 181 Partial W-method, 148 Partition testing, 149-50 Partitionable SIMD/MIMD (PASM), 265 Partitioning, 210, 215-17 Periodic I 0 synchronization, 328 Personal voice messaging system, 153 Pipeline hazards, 289 P-kernel, 281-3 Planner-based test generation, 150-1 Point-to-point system, 337 POLKA, 104-5 Post-conditions, 169 Pre-conditions, 76, 169 Predefined exceptions, 222 Premature termination, 217 Preservation of firewall, 225 Preserved maps, 215-16 Principle-based MT (PBMT), 30-1 PRINCITRAN MT system, 30 Probabilistic context-free grammar (PCFG),

371

36 Procedure parameters, 220 Process diagnostics, 329 Processing elements (PEs), 240, 241, 263, 268, 292 Production coverage, 145-6 Production rule, 145-7 Program understanding, 98-100 Program visualization, 98 Programmable logic controller (PLC), 3 19 adapter mode, 320-1 Propagation of exceptions, 228-9 Purdom’s algorithm, 146 PVS, 86 Pyramidal architectures, 266-7

Q Quasi-deterministic systems, 324

R Raising an exception, 194 Rank-proces sor rectangle, 279 Real-time control processing, 324 Real-time services, 333 Recursion, 236-7 Refined maps, 216 Reliability, 72 Remote I 0 (RIO) devices, 319 Remote program services, 332 Renaming of predefined exceptions, 223 Return codes, 219,234-5 Reuse scenarios and experiences, 180-6 Reverse engineering domain analysis, 155, 171-2 Robot tape library, 153-5, 157-61, 164 Rule-based MT (RBMT), 28-9

S Sample derivation, 146 Script classes, 169 Script rules, 170-1 Scripts, 175, 184-6 Semantic ambiguity, 6-7 Shake and Bake MT (S&SBMT), 31-3

372

SUBJECT INDEX

Shared memory, 247-8 model, 340 Shared resources, 333 Signal conditioning, 325 Siliconization, 306 SIMD, 239-302 addressing autonomy, 255-6 advantages, 252 autonomous operation, 254-5 classification, 246 communication autonomy, 256-7 contention for control unit use, 290 control organization, 262-78 disadvantages, 252-3 evolution, 253-62 execution autonomy, 255 forms of autonomy, 257-8 hardware features. 254-9, 258-9 interpretation v. direct execution, 290 lack of hardware support for interpretation, 291 matching the interpretation environment to the host machine, 288-90 memory hierarchy, 259 organization, 25 1-3 organizational taxonomy categories, 243 overhead, 252,262,268 for managing activity status, 290 overview, 240-3 processing element, 25 1 program, 262 programming environment, 260 shared control multiprocessors, 290-2 superscalar (SSIMD), 269 Single-Instruction stream Multiple-Data streams (SIMD) machine. See SIMD Single-Instruction stream Single-Data stream (SISD) processor, 246 Single Program Multiple Data (SPMD) model, 270-2 SITE, 50 Sleuth, 171-5, 186, 187 test generation example, 176-80 Soft real-time system, 324 Software defects, 193-4 Software Development Plans (SDPs), 197 Software engineering formal methods, 69-94 modcling, 70 Software-pipelining technique. 289

Software Standards and Procedures Manuals (SSPMs), 197 Software visualization (SV), 96 criteria, 100-1 definition, 98 existing tools, 101-7 key criteria for evaluating systems, 100 multi-resolution, 115-17 scalability, 107, 114-19 three-dimensional, YS-141, 117-19 user interface issues, 11.5 Spacecraft command and data handling application, 153 Spatial invariance, 43 Specification, model-oriented, 72-9 SPHINX, 266,267 Spring distributed real-time operating system, 310 SQL code, 153 Start-Home constraint, 314 State-based modeling, 77-8 State machine based test generation, 147-8 State parameters, 158, 161 State transition diagram, 169-70 Static assignment, 264 Static barriers, 277 Static transfer, 328 Statistical-based MT (SBMT), 34-7 Status parameters, 217, 219 StorageTek HSC-ACS domain, 162 StorageTek HSC command language, 1.53, 157, 161 StorageTek HSC Release 1.2 domain model, 173 StorageTek object hierarchy, 162 Structural divergence, 10 Structural invariance, 43 Successive software releases, 184-5 Sum-of-Products, 270 Superscalar SIMD Machine (SSIMD), 269 Supervisory Control and Data Acquisition (SCADA), 3 I3 Suppression of range checks, 235-6 Synchronization architectures based on barrier synchronization protocols, 275-8 Synchronization models, 270-8 Synchronization service, 332 Syntactic ambiguity, 6 System data, 335

SUBJECT INDEX System failure, 194 System interfaces, 330 System-level features of feature-interaction based ineffective design patterns, 229-37 System testing, 144 approaches, 145-53 domain models for, 143-90 further work, 186-7 industrial application, 153-5 Systran, 52

T Target LSM (TLSM), 169 Task-graph, 244 Tasking, 232-4 Tense generation, 9-10 Terasys PIM, 242 Test cases, 175, 186 construction, 186 reuse, 180, 183-6 Test generation process, 173-6 Test scripts, 175 Test subdomain, 173-4 Test templates, 175 Testing competing systems, 181 successive system releases, 182 varying system configurations, 182 Thematic divergence, 10, 3 1 Three-dimensional (3-D) visualization of software structure, 95-141 Time division multiple access (TDMA) schemes, 335 Time service, 333 Time Warp, 273 TMC-CM-2,264,286 TMC-CM-5,277 Top-down model, 99 Tracking Manager, 84,87-9 Transfer mapping, 17-19, 52.53

373

Transfer Ram, 314 Transfer rule, 23 Translated maps, 2 16 Transparency distributed service, 332 TRON (The Real-time Operating system Nucleus), 310-1 1

U Underflow, 21 1 Universal Coordinated Time (UTC), 333 University of Washington Program Illustrator (UWPI), 105-6 Unset out parameters, 224

V Validation, 81-2 Variable instruction issue problem, 288 VDM models, 88, 89 VDM Specification Language (VDM-SL), 73-6,78,85,89 Verbmobil MT project, 24 Vertical partitioning, 21 1, 215 Viewpoint, 340 Virtual-Time Data-Parallel machine (VTDPM), 272-5 von Neumann model, 245,247

w WIL, 152 W-method, 148 World knowledge, 13 World Wide Web, 307

Z Zeus, 105, 106

This Page Intentionally Left Blank

Contents of Volumes in This Series

Volume 21 The Web of Computing: Computer Technology as Social Organization ROB KLINCAND WALT SCACCHI Computer Design and Description Languages DASG~JPTA SUBRATA Microcomputers: Applications, Problems, and Promise ROBERTC. GAMMILL Query Optimization in Distrihuted Data Base Systems GIOVANNI MARIASACCO AND s. BINGYAO Computers in the World of Chemistry PETER LYKOS Library Automation Systems and Networks JAMESE. RUSH

Volume 22 Legal Protection of Software: A Survey MICHAELC. GEMICNANI Algorithms for Public Key Cryptosystems: Theory and Applications S. LAKSHMIVARAHAN Software Engineering Environments I. WASSERMAN ANTHONY Principles of Rule-Based Expert Systems AND RICHARD 0. DUDA BRUCEG. BUCHANAN 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 ALFST. BERZTISSAND SATISH THATTE

Volume 23 Supercomputers and VLSI: The Effect of Large-Scale Integration on Computer Architecture LAWRENCE SNYDER Information and Computation J. F. TRAUBAND H. WOZNIAKOWSKI The Mass Impact of Videogame Technology THOMASA. DEFANTI Developments in Decision Support Systems AND ANDREW B. WHINSTON ROBERTH. BONCZEK,CLYDE W. HOLSAPPLE, Digital Control Systems PETER DORATOAND DANIELPETERSEN

375

376

CONTENTS OF VOLUMES IN THIS SERIES

International Developments In Information Privacy G. K. GIJFTA Parallel Sorting Algorithms s. LAKSHMIVARAHAN, SUDARSHAN K. DHALL,AND LESLIEL. MILLER

Volume 24 Software Effort Estimation and Productivity S. D. CONTE, H. E. DUNSMORE, AND V. Y. SAEN Theoretical Issues Concerning Protection in Operating Systems MICHAELA. HARRISON Developments in Firmware Enginecring AND BRUCED. SHRIVER SUBRATA DASGUPTA The Logic of Learning: A Basis for Pattern Recognition and for Improvement of Performance 9. BANERJI RANAN The Current State of Language Data Processing PAULL. GARVIN Advances in Information Retrieval: Where Is That /#*&@a Record? DONALDH. KRAFI’ The Development of Computer Science Education WILLIAM F. ATCHISON

Volume 25 Accessing Knowledge through Natural Language NICK CERCONE AND GORDON MCCALLA Design Analysis and Performance Evaluation Methodologies for Database Computers DAVIDK. HSIAO, AND PAULAR. STRAWSER STEVENA. DEMURJIAN, Partitioning of Massive/Real-Time Programs for Parallel Processing I. LEE,N. PRYWES, AND 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 J. B. GLICKMAN, AND C. O’TOOLE W. J. POPPELBAUM, A. DOLLAS, Parallel Algorithms for Some Computational Problems ABHAMOITRAAND s. SITHARAMA IYENGAR Multistage Interconnection Networks for Multiprocessor Systems S. C. KOTHARI Fault-Tolerant Computing WING N. TOY Techniques and Issues in Testing and Validation of VLSI Systems H. K. REGHBATI

CONTENTS OF VOLUMES IN THIS SERIES

377

Software Testing and Verification LEE J. WHITE Issues in the Development of Large, Distributed, and Reliable Software ATULPRAKASH, VIJAY GARG,TSUNEO YAMAURA, AND ANUPAM BHIDE C. v. RAMAMOORTHY,

Volume 27 Military Information Processing JAMESSTARKDRAPER Multidimensional Data Structures: Review and Outlook S. SITHARAMA IYENGAR, R. L. KASHYAP, V. K. VAISHNAVI, AND N. S. v. RAO Distributed Data Allocation Strategies ALANR. HEVNERAND ARUNARAO A Reference Model for Mass Storage Systems STEPHENW. MILLER Computers in the Health Sciences KEVIN c. O’KANE Computer Vision AZRlEL ROSENFELD Supercomputer Performance: The Theory, Practice, and Results OLAFM. LUBECK Computer Science and Inforniation Technology in the People’s Republic of China: The Emergence of Connectivity JOHNH. MAIER

Volume 28 The Structure of Design Processes SUBRATA DASGUPTA Fuzzy Sets and Their Applications to Artificial Intelligence AND MORDECHAY SCHNEIDER ABRAHAM KANDEL Parallel Architecture for Database Systems L. L. MILLER,S. H. PAKZAD, M. H. EICH,AND B. SHIRAZI A. R. HURSON, Optical and Optoelectronic Computing MIRMOJTABA MIRSALEHI, MUSTAFA A. G . ABUSHAGUR, A N D H. JOHNCAULFIELD Management Intelligence Systems MANFRED KOCHEN

Volume 29 Models of Multilevel Computer Security JONATHAN K. MILLEN Evaluation, Description, and Invention: Paradigms for Human-Computer Interaction JOHNM. CARROLL Protocol Engineering MlNG T. LIU Computer Chess: Ten Years of Significant Progress MONROE NEWBORN Soviet Computing in the 1980s RICHARD w . JUDYAND ROBERTw. CLOUGH

378

CONTENTS OF VOLUMES IN THIS SERIES

Volume 30 Specialized Parallel Architectures for Textual Databases L. L. MILLER,s. H. PAKZAD, AND JIA-BINGCHENG A. R. HURSON, Database Design and Performance MARK L. GILLENSON Software Reliability ANTHONY IANNINO AND JOHND. MUSA Cryptography Based Data Security AND YVO DESMEDT GEORGEJ. DAVIDA Soviet Computing in the 1980s: A Survey of the Software and its Applications w. JUDYAND ROBERTw . CLOUCH RICHARD

Volume 31 Command and Control Information Systems Engineering: Progress and Prospects STEPHENJ. ANDUIOLE Perceptual Models for Automatic Speech Recognition Systems J. PALAKAL, AND PIER0 COSI RENATO DEMORI,MATHEW Availability and Reliability Modeling for Computer Systems NITINMITTAL,AND KISHORs.TRIVEDI DAVID I. HEIMANN, Molccular Computing MICHAEL CONRAD Foundations of Information Science ANTHONY DEBONS

Volume 32 Computer-Aided Logic Synthesis for VLSI Chips SABURO MUROGA Sensor-Driven Intelligenl Robotics MOHANM. TRIVEDIAND CHUXIN CHEN Multidatabase Systems: An Advanced Concept in Handling Distributed Data AND M. W. BRIGHT A. R. HURSON 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 BRUCEW. WEIDE, WILLIAM F. OGDEN, AND STUART H. ZWEBEN Object-Oriented Modeling and Discrete-Event Simulation BERNARD P. ZIECLER Human-Factors Issues in Dialog Design THIAGARAJAN PALANIVEL AND MARTINHELANDER Neuroconiputing Formalisms for Computational Learning and Machine Intelligence S. GULATI,J. BARHEN, AND S. S. IYENCAR

CONTENTS OF VOLUMES IN THIS SERIES

Visualization in Scientific Computing THOMASA. DEFANTIAND MAXINED. BROWN

Volume 34 An Assessment and Analysis of Software Reuse TEDJ. BIGGERSTAFF Multisensory Computer Vision N. NANDHAKUMAR AND J. K . AGGARWAL Parallel Computer Architectures RALPHDUNCAN Content-Addressable and Associative Memory LAWRENCE CHISVIN AND R. JAMESDUCKWORTH Image Database Management WILLIAM I. GROSKYAND RAJIVMEHROTRA Paradigmatic Influences on Information Systems Development Methodologies: Evolution and Conceptual Advances RUDYHIRSCHHEIM AND HEINZK. KLEIN

Volume 35 Conceptual and Logical Design of Relational Databases S. B. NAVATHE AND G. PERNUL Computational Approaches for Tactile Information Processing and Analysis AND MOHANM. TRIVEDI HRISHIKESH P. GADAGKAR Object-Oriented System Development Methods ALANR. HEVNER Reverse Engineering JAMESH. CROSS 11, ELLIOTJ. CHIKOFSKY, AND CHARLES H.MAY,JR. Multiprocessing J. FLECKENSTEIN, D. H. GILL,DAVIDHEMMENDINGER, C. L. MCCREARY, CHARLES JOHN D. MCGREGOR, ROY P. PARGAS, ARTHURM. RIEHL,AND VIRGIL WALLENTINE The Landscape of International Computing AND HSINCHUN CHEN EDWARDM. ROCHE,SEYMOUR E. GOODMAN,

Volume 36 Zero Defect Software: Cleanroom Engineering HARLAN D. MILLS Role of Verification in the Software Specification Process MARVINV. ZELKOWITZ Computer Applications in Music Composition and Research GARYE. WITTLICH, ERICJ. ISAACSON, AND JEFFREYE. HAS Artificial Neural Networks in Control Applications V. VEMURI Developments in Uncertainty-Based Information GEORGEJ. KLIR Human Factors in Human-Computer System Design MARYCAROL DAYAND SUSAN J. BOYCE

379

380

CONTENTS OF VOLUMES IN THIS SERIES

Volume 37 Approaches to Automatic Programming CHARLES RICHAND RICHARD c.WATERS Digital Signal Processing STEPHEN A. DYERAND BRIANK.HARMS Neural Networks for Pattern Recognition s. C. KOTHARIAND HEEKUCKOH 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 GUNTHERPERNUL Functional Representation and Causal Processes B. CHANDRASEKARAN Computer-Based Medical Systems JOHNM. LONG Algorithm-Specific Parallel Processing with Linear Processor Arrays JOSEA. B. FORTES,BENJAMIN W. WAH, WEIJA SHANG, AND KUMARN. GANAPATHY Information as a Commodity: Assessment of Market Value ABBEMOWSHOWITZ

Volume 39 Maintenance and Evolution of Software Products ANNELIESE VON MAYRHAUSER Software Measurement: A Decision-Process Approach WARREN HARRISON Active Databases: Concepts and Design Support THOMASA. MUECK Operating Systems Enhancements for Distributed Shared Memory Lo VIRGINIA The Social Design of Worklife with Computers and Networks: A Natural Systems Perspective ROBKLINGAND TOMJ E W E ~

Volume 40 Program Understanding: Models and Experiments A. VON MAYRHAUSER AND A. M. VANS Software Prototyping ALANM. DAVIS

CONTENTS OF VOLUMES IN THIS SERIES

381

Rapid Prototyping of Microelectronic Systems APOSTOLOS DOLLASAND J. D. STERLING BABCOCK Cache Coherence in Multiprocessors: A Survey AND C. R. DAS MAZINS. YOUSIF, M. J. THAZHUTHAVEETIL, The Adequacy of Office Models JOEYF. GEORGE,OLIVIA R. LIU SHENG, AND JAY F. NUNAMAKER CHANDRA S. AMARAVADI,

Volume 41 Directions in Software Process Research H. DIETERROMBACH AND MARTIN VERLAGE The Experience Factory and Its Relationship to Other Quality Approaches VICTORR. BASILI CASE Adoption: A Process, Not an Event JOCKA. RADER On the Necessary Conditions for the Composition of Integrated Software Engineering Environments DAVIDJ. CARNEY AND ALANW. BROWN Software Quality, Software Process, and Software Testing DICKHAMLET Advances in Benchmarking Techniques: New Standards and Quantitative Metrics THOMAS CONTE AND WEN-ME1 W. HWU An Evolutionary Path for Transaction Processing Systems CARLTON PU, AVRAHAM LEFF,AND SHU-WEI, F. CHEN

Volume 42 Nonfunctional Requirements of Real-Time Systems TEREZAG. KIRNERAND ALANM. DAVIS A Review of Software Inspections VOTTA ADAMPORTER, HARVEY sly, AND LAWRENCE Advances in Software Reliability Engineering JOHND. MUSAAND WlLLA EHRLICH Network Interconnection and Protocol Conversion MINGT. LIU A Universal Model of Legged Locomotion Gaits S. T. VENKATARAMAN

Volume 43 Program Slicing AND KEITHBRIANGALLAGHER DAVIDw . BINKLEY Language Features for the Interconnection of Software Components AND ROLAND T. MITTERMEIR RENATEMOTSCHNIG-PITRIK Using Model Checking to Analyze Requirements and Designs JOANNEATLEE,MARSHACHECHIK, AND JOHNGANNON Information Technology and Productivity: A Review of the Literature AND SHINKYU YANG ERIKBRYNJOLFSSON The Complexity of Problems WILLIAM GASARCH

382

CONTENTS OF VOLUMES IN THIS SERIES

3-D Computer Vision Using Structured Light: Design, Calibration, and Implementation Issues FRED W. DEPIEROAND MOHANM. TRIVEDI

Volume 44 Managing the Risks in Information Systems and Technology (IT) ROBERTN. CHARETTE Software Cost Estimation: A Review of Models, Process and Practice FIONAWALKERDEN A N D ROSS JEFFERY Experimentation in Software Engineering SHARILAWRENCE PF'LEEGER Parallel Computer Construction Outside the United States RALPHDUNCAN Control of Information Distribution and Access RALFHAUSER Asynchronous Transfer Mode: An Engineering Network Standard for High Speed Communications RONALD J. VETTER Communication Complexity EYALKUSHILEVITZ

Volume 45 Control in Multi-threaded Information Systems PABLO A. STRAUB AND CARLOS A. HURTADO Parallelization of DOALL and DOACROSS Loops-a Survey A. R. HURSON,JOFORDT. LIM,KRISHNA M. KAVI,AND BENLEE Programming Irregular Applications: Runtime Support, Compilation and Tools JOELSALTZ,GAGANAGRAWAL, CHIALINCHANG,RAJADAS,GUYEDJLALI,PAULHAVLAK, YUAN-SHIN HWANG,BONGKIMOON,RAWPONNUSAMY, SHAMIKSHARMA, ALANSUSSMAN AND MUSTAFA UYSAL Optimization Via Evolutionary Processes SRILATA RAMANAND L. M. PATNAIK Software Reliability and Readiness Assessment Based on the Non-homogeneous Poisson Process YANG AMRITL. GOELAND KUNE-ZANG Computer-supported Cooperative Work and Groupware JONATHAN GRUDINAND STEVEN E. POLTROCK Technology and Schools GLENL. BULL

Volume 46 Software Process Appraisal and Improvement: Models and Standards MARKC. PAULK A Software Process Engineering Framework JYRKIKONTIO Gaining Business Value from IT Investments PAMELASIMMONS Reliability Measurement, Analysis, and Improvement for Large Software Systems JEFFTIAN

CONTENTS OF VOLUMES IN THIS SERIES

Role-based Access Control RAVISANDHU Multithreaded Systems M. KAVI,BEN LEEAND ALLIR. HURSON KRISHNA Coordination Models and Languages GEORGEA. PAPADOPOULOS AND FARHADARBAB Multidisciplinary Problem Solving Environments for Computational Science ELIASN. HOUSTIS.JOHNR. RICEAND NARENRAMAKRISHNAN

Volume 47 Natural Language Processing: A Human-Computer Interaction Perspective BILLMANARIS Cognitive Adaptive Computer Help (COACH): A Case Study EDWINJ. SELKER Cellular Automata Models of Self-replicating Systems JAMES A. REGGIA,HUI-HSIENCHOU, AND JASOND. LOHN Ultrasound Visualization THOMAS R. NELSON Patterns and System Development BRANDON GOLDFEDDER High Performance Digital Video Servers: Storage and Retrieval of Compressed Scalable Video SEUNCYUP PAEK AND SHIH-FUCHANG Software Acquisition: The Custom/Package and Insource/Outsource Dimensions SEIDMANN, AND WILLIAM RICHMOND PAUL NELSON,ABRAHAM

Volume 48 Architectures and Patterns for Developing High-performance, Real-time ORB Endsystems DOUGLASC. SCHMIDT, DAVIDL. LEVINEAND CHRIS CLEELAND Heterogeneous Data Access in a Mobile Environment - Issues and Solutions J. B. LIMAND A. R. HURSON The World Wide Web HAL BERCHELAND DOUGLASBLANK Progress in Internet Security J. ATKINSONAND J. ERICKLINKER RANDALL Digital Libraries: Social Issues and Technological Advances HSINCHUN CHEN AND ANDREAL. HOUSTON Architectures for Mobile Robot Control AND JAMESA. HENDLER JULIOK. ROSENBLATT

Volume 49 A survey of Current Paradigms in Machine Translation AND JOHNw . BENOIT BONNIEJ. DORR,PAMELA w. JORDAN Formality in Specification and Modeling: Developments in Software Engineering Practice J. S. FITZCERALD 3-D Visualization of Software Structure MATHEWL. STAPLES AND JAMESM. BIEMAN

383

384

CONTENTS OF VOLUMES IN THIS SERIES

Using Domain Models for System Testing A. VON MAYRHAUSER AND R. MRAZ Exception-handling Design Patterns WILLIAM G. BAIL Managing Control Asynchrony on SIMD Machines-a Survey AND PHILIP A. WILSEY NAELB. ARU-GHAZALEH A Taxonomy of Distributed Real-time Control Systems I. R. ACRE,L. P. CLARE AND s. SASTRY

This Page Intentionally Left Blank