Design Methods for Reactive Systems
Yourdon, Statemate, and the UML
- Michael Jackson, Independent Consultant, U.K. By
- R. Wieringa, University of Twente, Enschede, The Netherlands
Design Methods for Reactive Systems describes methods and techniques for the design of software systemsparticularly reactive software systems that engage in stimulus-response behavior. Such systems, which include information systems, workflow management systems, systems for e-commerce, production control systems, and embedded software, increasingly embody design aspects previously considered alonesuch as complex information processing, non-trivial behavior, and communication between different componentsaspects traditionally treated separately by classic software design methodologies. But, as this book illustrates, the software designer is better served by the ability to intelligently pick and choose from among a variety of techniques according to the particular demands and properties of the system under development.Design Methods for Reactive Systems helps the software designer meet today's increasingly complex challenges by bringing together specification techniques and guidelines proven useful in the design of a wide range of software systems, allowing the designer to evaluate and adapt different techniques for different projects. Written in an exceptionally clear and insightful style, Design Methods for Reactive Systems is a book that students, engineers, teachers, and researchers will undoubtedly find of great value.
Students, engineers, teachers, and researchers in software development or software engineering.
Hardbound, 500 Pages
Published: January 2003
Imprint: Morgan Kaufmann
"This book presents a refreshing but serious and conscientious approach to the work of developing useful software. Roel Wieringa, being a philosopher as well as an engineer, is determined to convey understanding along with practice, and insight along with information. He is not blinded by ephemeral fashions in notation, but draws eclectically from both new and old ideas and techniques. He looks critically at widely used techniques and notations, and judges clearly what should be adopted because it is simple and good, what must be supplemented from another source because it is deficient, and what must be discarded because it is too complicated." From the Foreword by Michael Jackson, Independent Consultant, UK "Design Methods for Reactive Systems is a most welcome addition to the literature on systems and software engineering. It is serious and balanced, refreshingly general and hype-free, and is one of the very few books in this area that is not a user manual for a particular methodology. It concentrates admirably on the difficult subject of reactive systems and their behavior, going to considerable lengths to present an impartial view of the main approaches to this subject." Dr. David Harel, Dean, Faculty of Mathematics and Computer Science, The Weizmann Institute of Science, Israel "Wieringa's book is one of the most significant design textbooks of the decade. Wieringa uses his undoubted experience in both practical and theoretical design to create a textbook that moves beyond the "statics" of transformational (predetermined) systems to the "dynamics" of reactive systems. In its turn, it lays down the foundations and provides the rationale for a subsequent subject on software product engineering. As such, it fills a very definite need." M. Whitelaw, Charles Stuart University, Wagga Wagga, Australia "To use methods well, it's vital to have a good grasp of their conceptual underpinnings. Most books in this area focus solely on notation and don't clarify the important issues. This book is different. It's intellectually rigorous, insightful, and original. In particular, the coverage of UML is far more substantial and reasoned than I have found in any of its 'official' texts." Daniel Jackson, Laboratory for Computer Science, MIT "This book makes a significant contribution to the software engineering literature. Although the emphasis is on the use of notations to express the functionality of reactive systems, the case studies used throughout the book also highlight the importance of nonfunctional or quality attributes. The summaries included in each chapter are very useful as a shortcut if the reader lacks the time to cover the chapter. The questions and exercises will be useful for instructors and students." Dr. Mario R. Barbacci, Software Engineering Institute, Carnegie Mellon University "This book is a primer for reactive system developers. I have worked for over 20 years developing telecom systems and automotive electronics. If this book had been around earlier, it could have helped us avoid many costly problems we encountered." Felix Bachmann, Carnegie Mellon University, Software Engineering Institute
- FOREWORDPREFACEPART I Reactive System Design1 Reactive Systems1.1 Examples of Reactive Systems1.2 Reactive versus Transformational Systems1.3 Four Case Studies and Three Examples1.4 Summary1.5 Questions and Exercises2 The Environment2.1 External Interactions2.2 Domains2.3 The Subject Domain2.3.1 Physical Entities2.3.2 Conceptual Entities2.3.3 Lexical Entities2.4 The Functions of Reactive Systems2.5 The Connection Domain2.6 Summary2.7 Questions and Exercises3 Stimulus-Response Behavior3.1 Cause and Effect Chains3.2 Events, Conditions, and Actions3.3 Events and Stimuli3.3.1 Assumptions about Observers3.3.2 Event Recognition3.3.3 Unobservable Events3.3.4 Observing Temporal Events3.4 Responses and Actions3.4.1 Assumptions about Actors3.4.2 Response Computation3.4.3 Unrealizable Actions3.5 Summary3.6 Questions and Exercises4 Software Specifications4.1 The System Engineering Argument4.2 Specifications4.3 The Role of Assumptions4.4 Operational Property Specifications4.5 Summary4.6 Questions and ExercisesPART II Function Notations5 Mission Statement5.1 Notation5.2 Relating System Purpose to Environment Purpose5.2.1 Design Levels5.2.2 Goal Analysis5.3 Guidelines for Finding a Mission Statement5.3.1 Statement of Purpose5.3.2 Responsibilities5.3.3 Composition5.3.4 Exclusions5.4 Summary5.5 Questions and Exercises6 Function Refinement Tree6.1 Notation6.1.1 Connection with Other Notations6.2 Design Guidelines6.2.1 Construction6.2.2 Validation6.3 Summary6.4 Questions and Exercises7 Service Description7.1 Notation7.2 Guidelines7.3 Summary7.4 Questions and ExercisesPART III Entity Notations8 Entity-Relationship Diagrams8.1 Entities and Attributes8.1.1 Entity Types8.1.2 Absolute Cardinality Properties8.2 Relationships8.2.1 Relative Cardinality Properties8.2.2 Association Entities8.3 Generalization8.4 Summary8.5 Questions and Exercises9 ERD Modeling Guidelines9.1 The Subject Domain Boundary9.2 Entities versus Attributes9.3 Entity versus Relationships9.4 Taxonomic Structures9.4.1 Rules of Classification9.4.2 Static versus Dynamic Specialization9.4.3 Classification and Counting9.4.4 Subtypes versus Roles9.5 Validation9.5.1 Consistency9.5.2 Checking Validity by Elementary Sentences9.5.3 Checking Validity by Snapshots9.5.4 Identification9.5.5 Validation Summary9.6 Summary9.7 Questions and Exercises10 The Dictionary10.1 Domain Ontology10.2 Syntactic Categories10.3 Path Expressions10.4 Extensional and Intensional Definitions10.5 Guidelines10.5.1 When to Define a Term10.5.2 Definitions by Genus and Difference10.5.3 Operational Definitions10.5.4 Abbreviations and Correspondence Rules10.6 Summary10.7 Questions and ExercisesPART IV Behavior Notations11 State Transition Lists and Tables11.1 Event Lists11.2 State Transition Tables11.3 Decision Tables11.4 Summary11.5 Questions and Exercises12 State Transition Diagrams12.1 Mealy Diagrams12.2 Variables12.3 Statecharts12.3.1 State Reactions12.3.2 State Hierarchy12.3.3 Parallelism12.4 Summary12.5 Questions and Exercises13 Behavioral Semantics13.1 Discretization13.2 Wait States and Activity States13.3 Pre- and Postconditions13.4 Triggering13.5 Step Semantics versus Single-Transition Semantics13.5.1 Concurrent Transitions13.5.2 Concurrent Events13.6 Multistep Semantics13.7 Action Semantics13.8 Time13.9 Summary13.10 Questions and Exercises14 Behavior Modeling and Design Guidelines14.1 Two Examples14.1.1 The Training Department14.1.2 The Heating Controller14.2 Guidelines14.2.1 The System Engineering Argument14.2.2 Finding a Behavior Description14.2.3 From the Environment to the System14.3 Summary14.4 Questions and ExercisesPART V Communication Notations15 Data Flow Diagrams15.1 External Entities15.2 Flows15.3 Stores15.4 Processes15.4.1 Kinds of Processes15.4.2 States of a Process15.4.3 Data Process Specification15.4.4 Control Process Specification15.5 Parameterized DFDs15.6 Summary15.7 Questions and Exercises16 Communication Diagrams16.1 Requirement-Level Components16.2 Communication Channels16.3 Decomposition16.4 Allocation and Flowdown16.5 Summary16.6 Questions and Exercises17 Communication Semantics17.1 Component Behavioral Semantics17.2 Communication Channels17.3 The Network17.4 The Environment17.5 Summary17.6 Questions and Exercises18 Context Modeling Guidelines18.1 The System Boundary18.2 Context Diagrams18.3 The Context Boundary18.4 Structuring the Context18.5 Summary18.6 Questions and Exercises19 Requirements-Level Decomposition Guidelines19.1 Architectures19.2 Encapsulation versus Layering19.3 Architectural Styles19.4 Requirements-Level Architecture Guidelines19.4.1 Functional Decomposition19.4.2 Subject-Oriented Decomposition19.4.3 Communication-Oriented Decomposition19.4.4 Behavior-Oriented Decomposition19.4.5 Choosing Decomposition Guidelines19.5 Evaluation19.5.1 Syntactic Coherence Checks19.5.2 Traceability Check19.5.3 Data Access Check19.5.4 Executing the Model19.5.5 The System Engineering Argument19.5.6 Generating a Throw-away Prototype19.5.7 Quality Attributes Check19.6 Summary19.7 Questions and ExercisesPART VI Software Specification Methods20 Postmodern Structured Analysis (PSA)20.1 Notations20.2 Coherence Rules20.3 Choosing Notations20.4 Summary20.5 Questions and Exercises21 Statemate21.1 Notations21.1.1 Temporal Events21.1.2 Starting, Suspending, Resuming, and Stopping Activities21.2 Choosing Notations21.2.1 Placing Activity in a Statechart or in an Activity Chart21.2.2 Representing Parallelism in Statecharts or in Activity Charts21.3 Execution Semantics21.4 Summary21.5 Questions and Exercises22 The Unified Modeling Language (UML)22.1 Notations22.2 Activity Diagrams22.2.1 Wait State and Activity States22.2.2 Sequence22.2.3 Hierarchy22.2.4 Parallelism22.2.5 Choice22.3 Static Structure Diagrams22.3.1 SSDs and ERDs22.3.2 Representing Classes and Objects22.3.3 Stereotypes22.3.4 The Meaning of a SSD22.4 Behavior Specification22.4.1 Specifying the Effect of Operation Calls22.4.2 Specifying the Effect of Signal Receptions22.4.3 Specifying Object Life Cycles22.4.4 Differences between Operations and Signals22.5 Communication and Coherence22.6 Static Structure Design Guidelines22.7 Execution Algorithm22.8 Collaboration and Sequence Diagrams22.9 Summary22.10 Questions and Exercises23 Not Yet Another Method (NYAM)23.1 Software Design Context23.2 From Flyweight to Heavyweight Use of Notations23.3 Design Approach23.4 Engineering Arguments23.5 Formality and Precision23.6 SummaryAppendicesA A Training Information SystemB An Electronic Ticket SystemC A Heating Control SystemD An Elevator Control SystemE Answers to Selected ExercisesGLOSSARYBIBLIOGRAPHIC REMARKSBIBLIOGRAPHYINDEXOnline Materials (www.mkp.com/dmrs/)E (continued) Answers to Selected Exercises (pass protected)F A Controller for a Compact Dynamic Bus StationG A Cruise Control SystemH A Logistics Information SystemSlides for TeachersHandout of the SlidesNotes for Teachers