Design Methods for Reactive Systems
Post date: Oct 08, 2011 5:7:17 PM
Yourdon, Statemate, and the UML
The application of well-known specification techniques to reactive systems is the focus of this book. A reactive system is "a system that, when switched on, is able to create desirable effects in its environment by responding to events." This perspective is not restricted to classical control systems (called directive systems in the book), but is also useful in a broader spectrum of information systems. In fact, this book's approach fits event-driven programming environments perfectly. Such environments are commonly used to develop modern graphical user interfaces.
While traditional transformation systems manifest a predetermined stateless behavior, and analysis of these is focused on how inputs are deterministically transformed into outputs, reactive systems are state-based, and exhibit a dynamic stimulus-response behavior. Basically, the reactive system under development (SUD) interacts with its environment by exchanging messages. Events in the environment arrive as stimuli to the SUD, and system responses are converted into actions in the environment. One of the recurring themes in the book, which is highlighted by the system engineering argument, is the importance of the environment. The argument states that the assumptions about the environment, plus the design specification, determine the properties of the resulting system, once the SUD is introduced. As a consequence, Wieringa advocates a more thorough environment specification than is usually done.
Wieringa focuses on specification techniques, describing their notations, explaining their semantic details, and offering some guidelines for their correct use. These techniques are arranged into four groups:
Function notations are useful for reaching an agreement with the customer, and are, therefore, best written in the customer's language (plain English).
Entity notations describe the subject domain, and are entity-relationship diagrams, complemented by a dictionary of key terms.
Behavior notations focus on the transformation of stimuli into responses, with accompanying state changes in the SUD.
Communication notations are focused on the information exchange between systems, and complement the view offered by behavior notations.
Once these types of notations are thoroughly surveyed, Wieringa wraps up the discussion of specification techniques with a chapter devoted to requirements-level system architectures, similar in spirit to the Object Management Group's model-driven architecture approach.
In the final part of the book, three different specification methodologies are described to illustrate how they combine different notations. Those methodologies are postmodern structured analysis (a Yourdon-style variant of structured analysis), Harel et al.'s Statemate, and a subset of the unified modeling language (UML), where the author introduces communication diagrams to ensure coherence between static structure diagrams (object and class diagrams) and behavior descriptions (statecharts).
Finally, in the last chapter, Wieringa presents "not yet another method" (NYAM), "the gist of existing methods," where he acknowledges that there is no silver bullet, and no single recipe for all specification problems. In fact, not all notations need to be used for all systems. The proper choice depends on the SUD functionality, and the notation's intended use (from informal prototypes to formal model checking).
In short, the author does his best to cover a wide range of specification techniques, and offers valuable insight into their underpinnings, complementing his discussions with case studies, exercises, and an uncommonly well-written glossary. The origins and rationale behind some of Wieringa's ideas can be found in the bibliographic remarks, along with some gems in the bibliography that deserve further reading.
The major shortcoming I found in this book was in its deviation from terminology and notation standards. For example, the author dismisses common terms, such as use cases or nonfunctional requirements, because of their possible connotations. In the first case, he prefers to use the term "service," although his focus on delivered value is akin to Constantine's essential use cases [1]. With respect to nonfunctional requirements, which have "the connotation that whether this property is present cannot be objectively decided" (p. 44), Wieringa misses the opportunity to use the goal analysis technique, which Gilb advocates [2], and about which it is clearly stated in this book that "all critical attributes can be specified in measurable testable terms."
Wieringa introduces his own share of new notations and variants (even the overly complex UML is somewhat expanded). We do not need more new models and notations, however; we certainly need better tools, and more practitioners to effectively apply known techniques [3]. With regard to this need, Wieringa's book is of value for practitioners, and food for thought for thinkers in general, and researchers in particular. If you want to fully understand the details of, and parallelisms between, specification notations, Wieringa is one of the best places to start.
-- Fernando Berzal, ACM Computing Reviews, 2003
References
[1] Constantine, L.L.; Lockwood, L.A.D.: Software for Use: A practical guide to the models and methods of usage-centered design (1st ed.). ACM Press/Addison-Wesley Publishing Co., New York, NY, 1999.
[2] Gilb, T.: Principles of Software Engineering Management. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1988.
[3] Wiegers, K.: Read my lips: No new models!. IEEE Software 15, 5(1998), 10-13.