STRATEGIES FOR REAL-TIME SYSTEM SPECIFICATION

Transcription

1

2 STRATEGIES FOR REAL-TIME SYSTEM SPECIFICATION

3 This page intentionally left blank

4 STRATEGIES FOR REAL-TIME SYSTEM SPECIFICATION Derek J. Hatley By Imtiaz A. Pirbhai Dorset House Publishing 353 West 12th Street New York, New York 10014

5 Library of Congress Cataloging-in-Publication Data Hatley, Derek J., Strategies for real-time system specification. Bibliography: p. Includes index. 1. Real-time data processing. 2. System design. I. Pirbhai, Imtiaz A., '. II. Title. QA76.54.H ' ISBN CREDITS Cover Design: Jeff Faville, Faville Graphics Back Cover: Hatley photo: Bultman Studios, Inc.; Pirbhai photo: Stewart Auer. The text of the book was set by the authors using the LaTEX document preparation system in cooperation with Smiths Industries. The graphics were prepared by the authors using Macintosh Plus and MacDraft. Copyright 1987 by Derek J. Hatley and Imtiaz A. Pirbhai. Published by Dorset House Publishing Co., Inc., 353 West 12th Street, New York, NY All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Distributed in the United Kingdom, Ireland, Europe, and Africa by John Wiley & Sons Ltd., Chichester, Sussex, England. Printed in the United States of America Library of Congress Catalog Card Number ISBN: Digital release by Pearson Education, Inc., June, 2013

6 To Sue DJH To my father, Baba Anwar Shah Taji, and in memory of my mother IAP

7 Acknowledgments First and foremost, we thank Wendy Eakin, our editor and publisher, who gently but firmly led these two neophyte authors through the rigors of writing a book. You too should thank her, dear Reader: For most of our careers we have worked on or with engineering specifications and standards, and if you are at all familiar with those kinds of documents, you will understand that she is all that stands between you and total boredom. Many people have contributed in many ways to the work presented here, and while we can mention only a few, we thank you all. Bruce Chubb, Angelo Dimitriou, Rex Morin, and Rod Wierenga gave management support for development and introduction of the requirements method. Dave Bulman sat in on the method's original conception, and, with his great knowledge and experience, helped us sift out the good ideas from the bad. The original Methods Team consisted of Kathy Hornbach, Bill Kelly, Martie Lorenz, John McCreary, and George Wood. Don Morrow remains the preeminent practitioner of the method itself, while John TenCate is master of the art of transforming the resulting model into a real system. Linda Goggins succeeded in the enormous task of coordinating and compiling the first (manual) application of the method. Kent McPherson performed some miracles with LATEX, the document preparation system for this book, to make it work the way we wanted. Tim Petersen, Irv Reese, Dick Schoenmann, and Peter Sutcliffe provided the management support needed for the development of the architecture method, as well as support for the further expansion and acceptance of both the requirements and architecture methods in the user community. Dan Bacon, Rodney Bell, James Bouhana, Bob Doering, Peter Hruschka, Lou Mazzucchelli, Don Morrow, Rick Swanborg, Tony Wasserman, and Bob Weisickle reviewed various drafts of the book and improved it immeasurably with their insights. Finally, we give a very special acknowledgment to Paul Gartz. Paul has been an enthusiastic champion of these methods, and an inspiration to the rest of us working on them. His aggressive canvassing on behalf of the methods has been responsible for their acceptance by management and the industry. VI

8 Contents List of Figures Foreword Preface xv xxiii xxv PART I: The Overall Strategy 1 1 Overview The Birth of the Requirements Model The Birth of the Architecture Model Compatibility of the Models Applicability of the Models The System Life Cycle 8 2 The Role of the Methods Structured Methods: What They Are System Requirements Model System Architecture Model System Specification Model The Development Life Cycle Structured Methods: What They Are Not Summary 32 PART II: The Requirements Model 33 3 Overview The Structure of the Model 37 vii

9 viii CONTENTS 4 The Process Model Data Context Diagrams Data Flow Diagrams Leveling and Balancing The Numbering System Data Flows Data Stores Process Specifications Interpreting the Process Model Summary : 59 5 The Control Model Control Context Diagrams Control Flow Diagrams Control Flows Data Conditions Control Stores Control Specifications Process Controls Summary 76 6 Finite State Machines Combinational Machines Sequential Machines Incorporating Finite State Machines into CSPECs Summary 97 7 Timing Requirements Repetition Rate Input-to-Output Response Time Summary Requirements Dictionary Primitive Attributes Group Structure Dictionary Data Bases Summary Requirements Model Interpretation and Summary The Requirements Model Interpreted 1ll 9.2 Requirements Model Summary 113

10 CONTENTS ix PART III: Building the Requirements Model Overview Model Users and Builders The Sources of Requirements The Model Building Process Getting Started User Requirements Statements Separating Data and Control Establishing the System Context Partitioning the Top Levels, Summary Developing the Model's Structure Abstraction and Decomposition The Seven-Plus-or-Minus-Two Principle Grouping and Decomposing Processes Grouping and Decomposing Flows Naming Processes and Flows Use of Stores Functionally Identical Processes De-emphasizing the Control Model Control Intensive Systems The Dilemma of Detail: Requirements Versus Design The Final Product Summary Preparing Process Specifications The Role of Process Specifications The Different Types of PSPECs Some Important Signal Conventions Structured English Annotating with Comments Summary Preparing Control Specifications Avoiding Control Specifications...., Combinational Control Sequential Control Multi-Sheet CSPECs 182

11 x CONTENTS 14.5 Fitting CSPECs In Summary Defining Timing Timing Overview Response Time Specification Summary Managing the Dictionary Flow Types Dictionary Symbols Summary 199 PART IV: The Architecture Model Overview Requirements-to-Architecture Template Architecture Model Symbols Architecture Diagrams Architecture Context Diagrams Flows and Interconnects Architecture Flow Diagrams Architecture Interconnect Diagrams Summary Architecture Dictionary and Module Specifications Architecture Module Specification Architecture Interconnect Specification Timing Requirements Architecture Dictionary Summary Completing the Architecture Model Allocation to Hardware and Software The Hardware and Software Architectures The Complete Architecture Model 238

12 CONTENTS xi PART V: Building the Architecture Model Overview Architecture Development Process Systems Come in Hierarchies Enhancing the Requirements Model Input and Output Processing User Interface Processing Maintenance and Self-Test Processing The Complete Enhanced Requirements Model Technology-Independent Versus Technology-Nonspecific Organizational Implications Summary Creating the System Architecture Model Architecture Context Diagram Architecture Flow and Interconnect Diagrams Example of AFD and AID Mapping Model Consistency and Balancing The Complete Architecture Model Summary Creating the Hardware and Software Architecture Models Hardware and Software Partitioning Applying the Template to Software Requirements Developing the Software Architecture The Hardware and Software Architecture Process Summary Architecture Development Summary Partitioning the Modeling Process 286 PART VI: Examples Automobile Management System Problem Statement Requirements and Architecture Development Requirements Model Architecture Model 319

13 xii CONTENTS 27 Home Heating System Problem Statement Requirements Model Architecture Model Vending Machine Customer Dialogue Requirements Model Architecture Model 355 APPENDICES 363 APPENDIX A: Standard Symbols and Definitions 363 A.1 Introduction 363 A.2 Standard Symbols 363 A.2.1 Dataflow 363 A.2.2 Controlflow 364 A.2.3 CSPEC bar 364 A.2.4 Process 365 A.2.5 Store 365 A.2.6 Terminator (source or sink, also external) 365 A.2.7 Architecture module 366 A.2.8 Information flow vector 366 A.2.9 Information flow channel 367 A.3 Requirements Model 367 A.3.1 Context diagrams 368 A.3.2 Flow diagrams 370 A.3.3 Process and control specifications 372 A.3.4 Timing specifications 376 A.3.5 Requirements dictionary 377 A.3.6 Requirements model balancing rules 379 A.4 Architecture Model 382 A.4.1 Architecture context diagram 382 A.4.2 Architecture flow and interconnect diagrams 384 A.4.3 Architecture module and interconnect specifications A.4.4 Architecture dictionary 388 A.4.5 Balancing rules 390

14 CONTENTS xiii APPENDIX B: Making the Models into Documents 392 B.I Organizing the Models 392 B.2 Military Standards 396 APPENDIX C: Information Modeling: The Third Perspective 398 References 403 Index 405

15 This page intentionally left blank

16 List of Figures A Map of the Book xxvi 1.1 The universal hierarchy of systems The total system life cycle Vending machine DFD Vending machine PSPEC Composite data entries from vending machine dictionary Vending machine CFD Vending machine CSPEC Primitive control entries from vending machine dictionary The structure of the requirements model Vending machine AFD Vending machine AMS Vending machine architecture dictionary entries Vending machine AID Vending machine AIS Augmented vending machine architecture dictionary The structure of the architecture model The formation of the system specification Requirements-to-architecture iterative loop System, software, and hardware specification structure Overlapping systems development phases Development life cycle spiral Composite chart of the requirements model The process structure (highlighted) Data context diagram Data flow diagram Transaction centers Four levels of data flow diagrams superimposed' 47 xv

17 xvi LIST OF FIGURES 4.6 Leveling, numbering, and parent/child relationships Data flows Splitting flows between levels Two examples of process specifications The structures of structured English The primitive network The control structure (highlighted) Control context diagram Control flow diagram Variations on CSPEC bars Comparison between discrete and continuous signals A data condition The model as a feedback control loop Process controls Controlling a transaction center Decision table for a heating system Condensed decision tables for a heating system Rotary combination lock: a sequential machine State transition diagram State transition table State transition matrix State transition matrix (alternate form) Combinational CSPEC, with its DFD and CFD Sequential CSPEC, with its DFD and CFD Block diagram of composite CSPEC Composite CSPEC Typical multi-sheet control specification Response time specifications Timing diagram to supplement the response time specification Typical primitive continuous signal definitions Typical primitive discrete signal definitions Requirements dictionary symbols Dictionary listing Indented explosion of a large group flow Primitive network with control structure 112

18 LIST OF FIGURES xvii 11.1 Signal and process categories Typical PSPEC: a primitive requirements statement Assuming the worst: all conceivable functions included Functions reduced after checking system scope Diagram with a first-cut control flow Composite top-level data and control flow diagram DFD 0: Control & Monitor Auto CFD 0: Control & Monitor Auto Correction of uneven flow distribution Correction of clustered processes Splitting and merging data flows Decomposing data flows Splitting off unused flows Flows with common members Multiple flows Two-way flows The half-arrow T convention A flow tree Functionally identical processes Composite chart of the model for control intensive system A PSPEC with equations A tabular PSPEC A flight profile used in a PSPEC Geometrical relationships used in a PSPEC Continuous, discrete-valued, and time-discrete signals A full decision table A reduced decision table An ambiguous set of input combinations Alternative representation of transaction center control Data flow diagram showing throttle control Control specification showing throttle control A multi-sheet state transition matrix Organization of a composite CSPEC A floating CSPEC Dictionary, response time, PSPEC, and CSPEC timing specifications 191

19 xviii LIST OF FIGURES 16.1 Flow types and their attributes Architecture model components Requirements template Architecture template Architecture template for the Automobile Management System Architecture model layering Architecture module symbol Information flow vector symbol Information flow channel symbols ACD for a flight management system ACD for the Automobile Management System AFD for a flight management system AFD for a data acquisition subsystem Architecture template for a flight management system Architecture template for a data acquisition subsystem AFD 0: Automobile Management System AFD layering AFD 2: Shaft Interface Module AFD 5: Throttle Interface Module AID for a flight management system Redundancy of architecture modules Redundancy of architecture channels AID 0: Automobile Management System AID 2: Shaft Interface Module Architecture model support components Architecture module specification A DFD, CFD, and their CSPEC to be allocated Splitting CSPECs for allocation Traceability matrix for the Automobile Management System Interconnect channel and corresponding AIS A typical AIS Partial architecture dictionary for the Automobile Management System Partitioning between hardware and software System, hardware, and software requirements hierarchy System, hardware, and software architecture hierarchy

20 LIST OF FIGURES xix 20.4 A vertical slice through the architecture model Hierarchical nature of natural systems Hierarchical nature of systems development Outside-in approach to architecture development Input and output buffers for the requirements model Input and output processes for the Automobile Management System Enhancements to the Automobile Management System DFD for user interface processing DFD/CFD for the driver interface process User interface buffer to the requirements model Enhancements for maintenance and self-test buffer Maintenance processing added to the requirements model Enhanced DFD for Automobile Management System Enhanced CFD for Automobile Management System Architectural enhancements to the requirements model ACD for the Automobile Management System Generic DFD/CFD/CSPEC AFD 0: Automobile Management System AID 0: Automobile Management System Architecture module specification for the Automobile Management System Architecture interconnect specification for the Automobile Management System Architecture dictionary for the Automobile Management System Architecture development process Hierarchical nature of the Automobile Management System DFD of requirements allocated to the automobile management computer module CFD of requirements allocated to the automobile management computer module AID for automobile management computer hardware configuration Requirements allocated to hardware Enhanced hardware requirements AFD for shaft interface module 278

21 xx LIST OF FIGURES 24.8 AID for shaft bus receiver Enhanced DFD for the automobile management computer software Enhanced CFD for the automobile management computer software A structure chart Software development structure Hardware and software architecture development process Iterative process for developing system requirements and architecture System modeling process Hardware and software partitioning process Hardware and software modeling process Application of requirements and architecture modeling to large systems Integrated system, hardware, and software model 291 A.1 Data flow: A solid arc with a name 364 A.2 Control flow: A dashed arc with a name 364 A.3 CSPEC bar: A short unlabeled bar 364 A.4 Process: A circle with a name and a number 365 A.5 Store: A pair of parallel lines containing a name 365 A.6 Terminator: A rectangle containing a name 366 A.7 Architecture module: A rounded rectangle containing a name and number 366 A.8 Information flow vector: A solid or dashed line with a name. 367 A.9 Architecture information flow channels 367 A.10 Components of the requirements model 368 A.11 Sample data context diagram 369 A. 12 Sample control context diagram 370 A.13 Sample data flow diagram 371 A.14 Data flow diagram naming and numbering rules 372 A.15 Sample control flow diagram 373 A.16 DFD and CFD naming and numbering 373 A. 17 Samples of process specifications 374 A.18 Process specification naming and numbering rules 375 A.19 Generic CSPEC for combinational system 376 A.20 Sample CSPEC for combinational system 377 A.21 Generic CSPEC for sequential system 378

22 LIST OFF1GURES xxi A.22 Sample CSPEC for sequential system 379 A.23 Illustration of flow decomposition in the requirements dictionary 381 A.24 Components of the architecture model 382 A.25 Architecture template 383 A.26 Sample architecture context diagram 383 A.27 Sample architecture flow diagram 385 A.28 AFD naming and numbering rules 386 A.29 Sample architecture interconnect diagram 387 A.30 Sample architecture module specification 388 A.31 Sample architecture interconnect specification 389 A.32 Example of enhancements to dictionary 389 C.1 Requirements projections of a system 399 C.2 Architecture template with three requirements projections.. 400

23 This page intentionally left blank

24 Foreword "Most systems people use the term real-time rather loosely," the young manager said. We were seated over dinner with three members of her staff and some other managers who took part in the day's seminar. "They say they've got a real-time constraint when they're worried about impatient insurance brokers or bankers sitting in front of their terminals. A real-time system, in their minds, is just one that needs to be 'quick as a bunny.' If they fail to meet that constraint, their users might be inconvenienced or even annoyed. When we use the term, it means something rather different." Her co-workers began to smile, knowing what was coming. "We build systems that reside in a small telemetry computer, equipped with all kinds of sensors to measure electromagnetic fields and changes in temperature, sound, and physical disturbance. We analyze these signals and transmit the results back to a remote computer over a wide-band channel. Our computer is at one end of a one-meter long bar and at the other end is a nuclear device. We drop them together down a big hole in the ground and when the device detonates, our computer collects data on the leading edge of the blast. The firs: two-anda-quarter milliseconds after detonation are the most interesting. Of course, long before millisecond three, things have gone down hill badly for our little computer. We think of that as a real-time constraint." J had been lecturing that day on the use of data flow modeling techniques for system specification. There had been the odd question about the use of such techniques for real-time systems, and my (typically glib) answer was that the techniques were applicable, though perhaps not totally sufficient. After all. my own earliest work with data flow modeling had been at Bell Labs and at La CEGOS Informatique. in both cases working on real-time systems. Or were those real-time systems? Maybe they were really just systems that needed to be 'quick as a bunny'? The young manager's graphic example had left me in some doubt. It has always been clear that something more than the basic tools of structured analysis are needed to specify timing and synchronization requirements. xxiii

25 xxiv FOREWORD In the simplest case, that "something" could be as trivial as a set of textual annotations, perhaps directly on the data flow diagrams. But for even slightly more complicated cases, there is the possibility of linked timing and ordering constraints that may involve a dozen or more system components. There has been a need for a systematic way to deal with such constraints. Over the last few years, I began to hear favorable reports of some realtime modeling techniques called the Hatley/Pirbhai Extensions. This multiperspective approach combined data flow decomposition with model components constructed in control- and information-space. The result appealed to me as a specification technique that was not only applicable, but for most cases sufficient for real-time systems. I contacted the developers and started to try out their extensions. The act of writing a Foreword is a kind of endorsement. It says, if nothing else, "Read this book, it couldn't hurt." In this case, I can be considerably more positive than that. I can tell you that I learned valuable new techniques from Hatley and Pirbhai, and that I apply them regularly on real-world realtime applications. October 1987 Camden, Maine Tom DeMarco The Atlantic Systems Guild

26 Preface This book describes two methods for specifying, respectively, the requirements for and the design structure of software-based systems. Although the methods grew up around real-time embedded systems, systems of all types and sizes have benefited from them, largely because of their flexibility and adaptability. The methods can be viewed as an integrated toolkit from which all the tools are compatible, but only those that are useful for the particular job need be used. The subject of this book is neither computer science nor software. Although the vast majority of the systems to which the methods are applied will in fact be implemented using software in digital computers, the methods do not address how to write that software or how to design that hardware. What the methods do address is how to specify the problems that the hardware and software must solve. Organization and audience of the book The book is intended for a wide range of readers. We assume that you are involved, or at least interested, in software-based systems, but that your needs may range from just a general understanding to an in-depth working knowledge. We have tried to organize the book to make it easy for you to select those parts that are of specific interest to you and to avoid those that are not. The figure on the following page shows the layout of the book. Part I provides an overview from which everyone will benefit. Parts II and IV describe what the methods are, and if you only need to understand the specifications resulting from their use, then these two parts are enough for you to read. If you need to prepare specifications, then you will also need to read Parts III and V, which describe how to use the methods. Part VI contains examples of the application of the methods, and we conclude the book with appendices and a brief bibliography. Decide what your area of interest is requirements analysis, design, or both and what depth of understanding you need general familiarity, use xxv

27 xxvi PREFACE A Map of the Book of the completed specifications, or building the specifications and it will be clear from the figure which parts of the book you should read. Derek J. Hatley Wyoming, Michigan Imtiaz A. Pirbhai Seattle, Washington

28 STRATEGIES FOR REAL-TIME SYSTEM SPECIFICATION

29 This page intentionally left blank

30 Chapter 3 Overview Our strategy is to establish what the desired end product is, before describing how to produce it. Consequently, in Part II, we describe in detail the completed requirements model, as it would be received by the user, and in Part III, we describe how to construct the model. The principal tools of the requirements model are flow diagrams: graphical models of signal flow r s and processes acting on those flow r s. Flow diagrams consist of data flow diagrams and control flow diagrams. The former are essentially the same as the DFDs of DeMarco [4]; the latter are similar to DFDs but with some important and unique differences. The other components of the requirements model are process specificatiolis and the requirements dictionary (which are similar to DeMarco's minispecifications and data dictionary), and control specifications (which are unique to this method). You might w? onder why we are describing here those parts of the method that have been described so often, and so well, before. The answer is, first, that w r e want the book to stand alone as a complete description of the whole method. Second, the earlier descriptions allowed a commendable degree of flexibility in the ways the method could be used. This has resulted in many different conventions being adopted in its use. It is therefore important to explain the particular conventions we have adopted in extending the method. If you have already been using "basic" structured analysis, you might very w r ell find that some of our conventions are quite different from yours. Key features of the method are It is a purely abstract model of the requirements, not a physical model of the design. It thus represents what has to be designed, not how to design it. 35

31 36 OVERVIEW It is diagrammatic, exploiting our ability to absorb visual information more effectively than textual or verbal information ("a picture is worth a thousand words"). It hides unnecessary detail at any given level, and provides for progressive decomposition from that level down the information hiding, abstraction, and decomposition principles put forward by Parnas [13] thus allowing presentation of the requirements from a top-level overview down to the most intricate detail. It meets the needs of large, complex systems, including real-time systems, for representation of a process structure and a control structure. It does this by integrating DeMarco's structured analysis with finite state machine theory. Neither of the methods alone can meet these needs. It has built-in consistency checks within and between all its components. This feature of structured analysis has been extended to the whole structure, taking the guesswork out of the rigor and consistency of the model. t It is self-indexing, another feature of structured analysis that has been successfully extended. It is easy to find your way around the resulting model without referring to page or paragraph numbers (although formal documentation requirements usually force us to keep these numbers). The first of these features the abstract nature of the model deserves special emphasis, because it seems to be the one that newcomers to the method find hardest to grasp. Perhaps the best way to approach it is to understand the motivation for wanting such a feature, and this is best understood by reviewing the history of structured methods development. Although structured methods generally represent their subject matter in a top-down fashion, the methods themselves have evolved in a bottom-up fashion. As software-based systems grew larger and more complex, the first obvious problem to be overcome was unmanageable and incomprehensible code. The need to solve this problem gave rise to structured programming in the form of constraints on module size, entry and exit points, branching, and so on. It also gave rise to high order languages, and, more recently, to program design languages. Structured programming improved the quality of the code within individual modules, but still, as systems continued to grow in size and complexity, the interactions between the modules became as complex as the earlier code had been. Structured design methods, in which modules are constrained to communicate with each other in an organized way, were developed to deal

32 THE STRUCTURE OF THE MODEL 37 with this complexity. These methods improved the quality of the software structure external to the modules, such that if both structured design and structured programming methods were conscientiously applied, the resulting system \vould work exactly as the designer intended. Unfortunately, it still often happens that what the designer intended is not what the user wanted! The reason for this is that as the technology allows us to make systems that have ever larger capacity and complexity, the requirements themselves for such systems become large, complex, and difficult to describe and understand. Thus, the need was established for a method to represent the functional requirements of a system in an organized and understandable way, and in a way that is entirely independent of the eventual design and implementation of the system. Given such a model, various designs can be developed and compared without changing the requirements representation. DeMarco's structured analysis method was designed to meet this need for data processing systems, and the extended structured analysis method described here was designed to meet the need for more general systems. The model does, unfortunately, have a machine-like appearance; moreover, we are used to models that are intended to represent the actual design structure or implementation. As should now be clear, this is not the intent here. Again, it is a purely abstract model, with highly idealized properties, whereby each of its processes is independently data triggered and infinitely fast unlikely characteristics for a real system. These properties are deliberately chosen for the very reason that we can ignore the constraints of the physical world, and concentrate exclusively on the required functionality. As we build a requirements model, we follow this separation principle by including those characteristics that are of concern to the users, and deliberately excluding those that are not. The latter are left to the designer, and the moment we allow them to migrate into the requirements model, then we are including items that are not requirements; in so doing, we are placing unnecessary and artificial constraints on the designer. We will remind you of this property at appropriate places throughout Parts II and III to emphasize its importance in each aspect of the model. 3.1 The Structure of the Model Figure 3.1 is a composite chart, which enlarges on the diagram of Figure 2.7, and illustrates how the major components of the requirements model relate to each other. We will describe the major roles and relationships of these components before going into their individual details in the following chapters.

33 38 OVERVIEW Figure 3.1. Composite chart of the requirements model.

34 THE STRUCTURE OF THE MODEL 39 At the top of Figure 3.1 are the data context diagram and the control context diagram. These show, respectively, the data and the control signals flowing between the system and the external entities with which the system must communicate. They also show the overall function of the system in the form of a single process. These diagrams represent the highest-level, or most abstract, view 7 of the requirements, and show T the central role the system is required to perform within its external environment. Next (below the context diagrams in Figure 3.1) are two more flow diagrams the level 1 DFD and CFD. They too represent the overall function of the system in graphical form, but in somewhat more detail than the context diagrams. Below the level 1 diagrams are level 2 diagrams. For purposes of illustration, the figure shows just one DFD and one CFD at level 2, but, in fact, each of the several subprocesses on the level 1 diagrams may have its own level 2 DFD and CFD, so there will be several diagrams at this level. Just as the level 1 diagrams represent a more detailed statement of the system's purpose, so the level 2 diagrams represent more detailed statements of the purposes of the subprocesses on the level 1 diagram. Similarly, level 3 diagrams decompose the processes and signal flows on the level 2 diagrams into more detailed statements, with a further multiplication of the number of diagrams. This decomposition continues level by level, each step revealing finer and finer details of the originally stated system's purpose. The decomposition ends, for any given subprocess on the DFD side, with a concise statement of the purpose of a process using simple text, equations, tables, or diagrams. This statement constitutes a process specification, as illustrated at the bottom of the column of DFDs. A process that is described by a process specification is called a functional primitive, or just a primitive. On the CFD side, the decomposition parallels that of the DFDs, but some of the control signals flow to and from control specifications, shown in the center column of Figure 3.1. The CSPECs describe the finite state machine functions of the system, which we will discuss in Chapter 6. Each CSPEC is associated with a specific CFD the one adjacent to it in the diagram. It will usually control processes, but only those in the specific DFD adjacent to it in the figure. This close association of a DFD, CFD, and CSPEC is an important part of the structure and self-consistency properties of the requirements model. The system input-to-output timing requirements are shown in the timing specification, shown between the context and level 1 diagrams (and detailed in Chapter 7). These specifications simply list events that are detected at the system inputs (the system stimuli), the corresponding events that are

35 40 OVERVIEW required to occur at the system outputs (the system responses), and the timing constraints within which the system must generate these responses. Finally, Figure 3.1 shows the requirements dictionary. Although it is shown outside the main structure, the RD serves a vital role throughout the model since it contains precise definitions of all the data and control flows in all their levels of decomposition. The remaining chapters of Part II describe each component of the method in detail, but it is important not to lose track of how they fit into the overall structure of Figure 3.1 as you study them. For the purposes of this description, we refer to the DFDs and PSPECs as the process model, the CFDs and CSPECs as the control modelj and the two of them with the requirements dictionary and timing specifications as the requirements model. This is in keeping with the evolution of the methods: The process model corresponds to the classical structured analysis model; the control model is the part we added, derived from finite state machine theory; and the requirements model is the complete, integrated combination of the two.

36 Index Actions, 15, 83-88, 93, 97, logic, 93, 94, 184 naming, 177, 189 Activation table: see Process activation table Architecture communication channels: AIS and, redundancy of, in AID, Architecture context diagram (ACD), , ,263-64, components in, 211 example, 212, 213, 383 for Automobile Management System, 264, 322 Architecture dictionary (AD), 20,25, , , , of Automobile Management System, 233, 325 of vending machine example, 22,23,358 Architecture flow diagram (AFD), 20,25, , , decomposition of, examples, 215, 216 naming and numbering rules, 384, 386 of Automobile Management System, 218, 220, 266, , 322 of vending machine example, 21,357 structure chart and, 282 Architecture interconnect diagram (AID), 21-22, 25, , 213, , , decomposition of, layering rules, 222 naming and numbering rules, 222, 385, 386 of Automobile Management System, , 323 of vending machine example, 22,357 redundancy in, 219, Architecture interconnect specification (AIS), 22, 23, , , of Automobile Management System, 231, 324 of vending machine example, 23,359 Architecture model, 7,12,19-27,99, Automobile Management System, balancing, 238, , , 368, components, decomposition of, 215 hierarchy of, 207 illustration, 24 implementation of, in hardware and software, of Home Heating System example, summary, 24-25, , symbols of, vending machine example, Architecture module, 20,208 automobile management computer module example, ,274-77, decomposition of, 215 defined, 366 implementation of, in ACD, 211 in AID, 219, naming rule, 208, 366 number in AFD, 214 partitioning of requirements, redundancy of, 219,221 symbols, 208, 366 timing constraints and, Architecture module specification (AMS), 20, 25, 215, of Automobile Management System, 268, 324 of vending machine example, 21 traceability matrix and, 226, Architecture template, , 217, , , 383,

37 406 INDEX benefits of, for Automobile Management System, 206 software requirements and, Automobile management computer module, , , Automobile Management System, ACD example, 213, 322 AD example, 234, 325 AFD example, 218, 220, 322 AID example, 223, 323 AIS for, 324 AMS example, , 324 architecture model of, 239, architecture template for, 206 control diagrams for, 301 CSPEC for, 303, 308, 312, 314 data vs. control issues, enhanced CFD for, 258,321 enhanced DFD for, 257, 320 flow names in, 148 hierarchical nature of, 273 input and output processing for, PSPEC of, 160, , 309, 312, 315 RD for, response time specification, 100 safety requirements in, 245 sequential machine in, STD in, 85, 87 STM in, 88, 89 system context, timing specification, 304 top-level partitioning, traceability matrix for, 230 transient signal in, 163 user interface processing, Automated tools, 6, 206,404 used for balancing, 49,140,166 used for dictionary, 107,140,197,199, 395 Avionics system example, 4-7 Backus-Naur form, , Balancing: architecture model, , requirements model, 47-49,113,123, (see also specific entries) Balzer, R., 139,404 Bar symbol, 65-66, 71, 89, 93, 185, 364, 371 Boehm, B., 29,403 Boolean equation form, 79-80,97,171,198 Booth, T., 86, 173, 403 CASE tools, 6, 404 Combinational control specification, 90-93, Combinational machine, 78-82, 114, 152, 157, CSPEC for, Comment: in PSPEC, 55, 167 in requirements dictionary, Conditional construct, 166 Consistency checking, 5, 36 of architecture model, of CSPECs, 71 ofdfds,49,50 of requirements model, 36,48, 50, 52, 113,115 Constantine, L., 6, 282, 404 Context diagram: context process in, 137 control, 38-39, 41, 61-63, 76, 301, 369 data, 38, 39,41-44, 59, 63, 368 level 1 and, nonprimitive flows and, primitive flows in, 67-68, timing requirements and, 99 (see also Control context diagram, Data context diagram) Context process, 43-44, 63, 137 Continuous (analog) machine, 77-78,97 digital computer and, 78 PSPECs and, 77 Continuous signals, 67-68, 77-78, 103, 125, 165 example of primitive in RD, 104, Control context diagram (CCD), 38-39,41, 61-63, 76, 301, of Automobile Management System, 301 of vending machine example, 344 Control flow, 13,41, 61, 64-68, 103 defined in requirements dictionary, 67, 104, 115 determined in requirements model, graphic convention, 61,63, 67, 364 naming, 364 types and attributes, Control flow diagram (CFD), 13, 15,19, 35, 64-68,76,113, allocation in architecture model, balancing, 64, 113 composite example of, 33 control store on, 70, 76,150, 365 control flow on, 15-16, control signals and, 15-16,67

38 INDEX 407 Control flow diagram (CFD), 13,15, 19, 35, 64-68,76, 113, allocation in architecture model, balancing, 64 control store on, 70, 150 decomposition of, 39,65 interface with CSPEC (bar symbol), 65-66, 71, 89, 90, 185, 364, leveled, 39,64,113 link to DFD, 69,71 naming and numbering, 64,113-14, of automobile management computer module, 275,281 of Automobile Management System, 258, 302ff. of vending machine example, 16,356 sample, 373 Control model, 13, 15-19,40, control-intensive system and, implementation details and, purpose of, 152 vending machine example, Control outputs, 73 (see also Process controls) Control signal, 15-16, 67 RD and, 16 symbol for, on CFD, 15 (see also Control flow) Control specification (CSPEC), 15, 16, 19, 39, 64-67, balancing, 95, 368, bar symbol on, 65-66, 71, 89, 93, 185, 364, combinational vs. sequential control, 90-93, , composite, 93-94, 184 decision table and, finite state machines and, 39, 73, 89-97, 188 floating, 187 interface with CFD, 65-66, 71, 89, 90, 185, 364 multi-sheet conventions for, 95-97,114, naming and numbering, 71,114 of Automobile Management System, 303, 308, 312, 314 of combinational machine, 79-82, , of vending machine example, 17,20 PAT in, placement of, in model, primitive, process controls and, 73-76,90 purpose of, 73, 114, 169 rule for allocation in architecture model, state transition diagram and, 65, 90,92, 93 timing requirements in, 188 transaction center and, 75, users' guide for, 95,114,153,185 Control store, 70, 76, (see also Data store) naming, 70, 150, 365 Control structure, 5 balancing, 76 determining in requirements model, , illustrated, 62,112 Cruise control system example: see Automobile Management System Data abstraction, 137,209 (see also Information abstraction) Data condition, 19, 69-70, 76, 114 example, 69 Data context diagram (DCD), 38,39,41-44, external primitive flows in, 191 of Automobile Management System, 301 of vending machine example, 344 Data flow, 41, 43, 44,49-52, 59 arcs, balancing, 47-49, 59,143^4 consistency checking of, 49, 50, 52 data stores and, 52,150 decomposition of, 50,143 defined, 363 determined from user requirements statement, graphic conventions, 43, 50-51,143-47, 364 in requirements dictionary, 13,103,115, naming rules, 46, 50, , , 363 primitive, 49 splitting and merging, 50, 143 types and attributes, Data flow diagram (DFD), 13,19, 35,44-53, 114, allocation in architecture model, composite example of, 133 data signal and, 67 decomposition of, 39,45,47

39 408 INDEX leveling and balancing, 39,45,47-49, 59, 113 link to CFD, 69,71 naming and numbering, 49, of automobile management computer module, 274,280 of Automobile Management System, 302ff. of vending machine example, 14 parent/child relationship, 45,47-49 sample, 45, 371 Data modeling: see Information modeling Data process, determining, 128 Data store, 52-53, 59, defined, 44,365 flows and, 150 naming rules, 52-53, 150, 365 symbol, 44 Data structure: determined in requirements model, Date, C., 194, 403 Decision table (DT), 73, 79-82, 97, 114, 166, 375 Home Heating System example, in CSPEC, luggage lock example, 79 PAT, 90-91, STM and, transaction center and, Decomposition, 36, of flows, of processes, 45, ± 2 principle, DeMarco, T., 5, 35, 36, 37, 56, 403 structured analysis method of, 5,95 Design, constraints, 203 internal timing requirement and, 98,102, 114, 190 phase, 155 Discrete signal, 67-68, 77-78, ,125, 165 example of primitive in RD, 104, Don't care condition, 80,172,173,189,194 Entity, in ACD, 211 Equation, in PSPEC, Event, 15, 83-88, 93, 97, asynchronous, 150 logic, 93, 94, 184 naming, 189 response time, Feedback control loop, 71-73,114 Finite state machine, 77-97, 125, 153 combinational, 78-82, 152, 157, , control model and, 40,70-73,76 control structures and, 5,113 CSPEC and, 15, 39, 73, model, 77 sequential, 78, 83-89,176-82, 375, theory, 5, 36, 89 Flavin, M, 403 Flight management system example, 78 response time specification, 100 Flow arcs, 43-44, symbol on CFD, 65 symbol on DFD, 16 Flow diagram: see Control flow diagram, Data flow diagram Flows: allocation in AMS, balancing, (see also Control flow, Data flow) Functional primitive: see Primitive process Functional requirements, 3-10,13,19 (see also Control model, Process model, Timing requirements) Fundamental entity, 208 Hardware design, requirements allocated to hardware, 277 Hardware/software implementation of architecture model, , example, 236 Hardware/software models, Hierarchical representation, 4,9-10,28-29, 36,39 of Automobile Management System, 273 Hofstadter, D., 216,403 Home Heating System example, Hopcroft, J., 86,403 Implementation, system, 10, 12, 56,114 architecture, 229 of process model, 56 timing constraints and, Information abstraction, 5, 36,113, Information flow channel, 213 in AFD and AIS, 25 in AID, 219 naming rule, 209, 367 symbol, 209, 367

40 INDEX 409 Information flow vector, defined, 366 inacd,211 naming rule, 209, 367 symbol, 209, 367 Information hiding, 36,137,185 Information modeling, 13, ,404 Input and output processing, 26, Input-to-output response time, ,113 Interface definition, 7,26, ,260 Iteration: of architecture model, 203, of development process, 10,26-30 of requirements model, 123,139 Leveling: CFDs, 39,64, 113 DFDs, 39, 45, 47-49, 59, 113 PSPECs, 53, 70 Logical function, 43 Maintenance processing, in architecture model, 26-27, , Martin, J., 194, 403 McMenamin, S., 12, 150, 403 Mealy sequential machine model, 86,314 Mellor, S., 86, 404 Methods Team, 6 Military standards (documentation), Miller, G., , 403 Modeling process, 286 Module, 20,24 automobile management computer example, 274 software, (see also Architecture flow diagram) Module specification: see Architecture module specification Moore sequential machine model, 86,314 Myers, G., 6, 283, 403 Naming rules: abbreviations used, in AFD, 384, 386 of processes and flows, 46,50,138,140, , Numbering system: of flow diagrams, 49, of multi-sheet CSPECs, 95-97, 114 Objects (flows), naming, 46,148 Operational requirements specification, 192 Page-Jones, M., 128, 283, 404 Palmer, J., 12, 150, 403 Parnas, D., 36, 137, 139, 283, 404 Partitioning, 30 in Automobile Management System, modeling process, of architecture model for hw/sw implementation, , , 289 of requirements model, 113 Physical configuration, 24,25 Physical modules, Physical requirements, 3, 7,43, Primitive flow, 67-68, attributes of, , decomposing groups of, 140 defined, 103,194 examples of, 104 grouping, 140, 194 symbol in dictionary, 106 Primitive network, 58, 112 Primitive process, 13, 39, 48, 53, 58, 59, CFD and, 65 network of, 58,112 PSPEC and, 13, 65 Process, allocation in AMS, controls, 73-76, 111 data, 128 defined, 365 functionally identical, naming rule, 46,147-49, 365 numbering system, 49 on CCD, 61 on CFD, parallel, 56 physical, 208 primitive, 13, 39, 49, 53, 58-59, 65, sequential, 55 symbol for, 41 timing requirements in, 191 Process activation table (PAT), 15,90,91, , 375 example, 91 of vending machine example, 17,20 Process activators, 73 CSPEC and, Process controls, 73-76, 90 in leveled DFDs, 74 Processing, input and output: Automobile Management System,

41 410 INDEX in architecture model, Processing, user interface, 26-27, Process model, 13,40,41-60 interpreting, Process specification (PSPEC), 13,19, 35, 39, 53-55, 59, 372, 374 balancing, 53, 70,159, 166 comment in, 55 conditional statement in, continuous machines and, 77 data condition and, data signal and, 67 examples, 54,129, 374 functional primitives, 53 leveling and balancing, 53,70 naming and numbering rules, of Automobile Management System, 160, ,309,312,315 of vending machine example, 14 role of, structured English in, 53, 55-56, transient signal in, types of, user requirements and, 55,158 Process structure: categories, 127 in requirements model, 113 Project dictionary: abbreviations and, list of word types, 166 Prototyping, 30 Putnam, L., 404 Putnam model, 6,404 Real-time systems, 36 characteristics of, 3» 77,98 development methods for, 1 Iff. Redundancy requirement, 26,27 data store and, 53 in AFD, 218 in AID, 219, in Automobile Management System, 277 Reliability requirement, ,243 Requirements: data vs. control, ,152 defined, 10,12 functional, 3, 99 physical, 3, 24 processing, in PSPECs, timing, 39-40, , , , , 244 Requirements dictionary (RD), 13,19, 35,40, , attributes of, cockpit display example, 105 data flow types in, flow decomposition in, 381 flows in, 67, 103, 115 in a computerized data base, ,194 indented explosion of, 107,109 naming rules, 379 of Automobile Management System, of vending machine example, 15,18,354 primitives in, symbols in, , , 378 timing signals in, Requirements model, 4, 7,12, 13-19,25-27, 35-^0, adding physical constraints, allocation of components in Automobile Management System, builders, components of, 37-40,113-15, consistency checking of, 36,49, 50, 52, 113, 115 decomposition and, 45,122-23, enhanced, implementation details and, 152 leveling and balancing, 47-49, 113, naming and numbering in, 47ff., 113 of Home Heating System, of vending machine example, overview of, 18-19, 35-40, primitives in, 113 redundancy and, 26-27,53 role of automata theory, 89 self-indexing, 5, 36,115 signals in, 162-^63 timing in, tools of, 35 users, Response time specification, 13, 19, , 115 (see also Timing specification) Schuldt, G., 13, 404 Self-test processing, 26-27, Sequential control specification, 90,92,93 Sequential machine, 78, 83-89, 95, 97, 114, 152, 157, , 375 combination lock example, CSPEC for, 378, 379 math representation, 178 Mealy and Moore models, 86,178-79