Skip to main content

2003 | Buch

Come, Let’s Play

Scenario-Based Programming Using LSCs and the Play-Engine

verfasst von: David Harel, Rami Marelly

Verlag: Springer Berlin Heidelberg

insite
SUCHEN

Über dieses Buch

This book does not tell a story. Instead, it is about stories. Or rather, in technical terms, it is about scenarios. Scenarios of system behavior. It con­ centrates on reactive systems, be they software or hardware, or combined computer-embedded systems, including distributed and real-time systems. We propose a different way to program such systems, centered on inter­ object scenario-based behavior. The book describes a language, two tech­ niques, and a supporting tool. The language is a rather broad extension of live sequence charts (LSCs), the original version of which was proposed in 1998 by W. Damm and the first-listed author of this book. The first of the two techniques, called play-in, is a convenient way to 'play in' scenario­ based behavior directly from the system's graphical user interface (QUI). The second technique, play-out, makes it possible to execute, or 'play out', the behavior on the QUI as if it were programmed in a conventional intra­ object state-based fashion. All this is implemented in full in our tool, the Play-Engine. The book can be viewed as offering improvements in some ofthe phases of known system development life cycles, e.g., requirements capture and anal­ ysis, prototyping, and testing. However, there is a more radical way to view the book, namely, as proposing an alternative way to program reactivity, which, being based on inter-object scenarios, is a lot closer to how people think about systems and their behavior.

Inhaltsverzeichnis

Frontmatter

Prelude

Frontmatter
1. Introduction
Abstract
What kinds of systems are we interested in? Well, first and foremost, we have in mind computerized and computer embedded systems, mainly those that are reactive in nature. For these reactive systems, as they are called, the complexity we have to deal with does not stem from complex computations or complex data, but from intricate to-and-from interaction — between the system and its environment and between parts of the system itself.
David Harel, Rami Marelly
2. Setting the Stage
Abstract
In this chapter we set the stage for the rest of the book, by describing some of the main ideas in systems and software engineering research that lead to the material developed later. We discuss visual formalisms and modeling languages, model execution and code generation, the connection between structure and behavior, and the difference between implementable behavior and behavioral requirements. We then go on to describe in somewhat more detail some of the basic concepts we shall be expanding upon, such as the inter-/intra-object dichotomy, MSCs vs. LSCs, the play-in and playout techniques, and the way all these fit into our global view of the system development process.
David Harel, Rami Marelly
3. An Example-Driven Overview
Abstract
In this chapter, we overview the main ideas and principles of our work. The purpose of the overview is to give a broad, though very high-level, view of the LSC language, the play-in methodology for specifying inter-object scenariobased behavior, and the play-out mechanism for executing such behavior. We will touch upon many issues, but will not dwell on the details of the language constructs, nor the methodology, nor the tool. The overview is presented as a guided walk-through, using a simple example of a reactive system.
David Harel, Rami Marelly

Foundations

Frontmatter
4. The Model: Object Systems
Abstract
Scenario-based languages, such as LSCs, are not restricted to particular systems, architectures or modeling techniques. They can serve to specify the behavior of either sequential or parallel systems, based on either centralized or distributed architectures, and they can be used to describe the interaction between processes, tasks, functions and objects. The same applies to virtually all the ideas and techniques described in this book. However, it will be convenient for us to use a single system model throughout the book. Since object-orientation appears to be the most dominant development methodology today, we will use the basic 00 notions and terminology in our system model as well.
David Harel, Rami Marelly
5. The Language: Live Sequence Charts (LSCs)
Abstract
Message sequence charts (MSCs) were discussed in Chap. 2. They were adopted long ago by the International Telecommunication Union (the ITU, formerly the CCITT), and constitute a visual scenario-based language that is popular in the realm of object-oriented systems for capturing behavioral requirements. The language also manifests itself in the UML, somewhat modified, and is referred to there as sequence diagrams.
David Harel, Rami Marelly
6. The Tool: The Play-Engine
Abstract
In the previous two chapters we introduced two basic foundations of our approach, the system model and the language, and our goal is to use the latter to describe the behavior of the former, by playing in. The result of the play-in process is a formal specification in the language of LSCs, and this specification can then be executed and tested by playing out different scenarios and observing system responses. The link between the two foundations of language and model and the play-in/play-out methodology is provided by the Play-Engine tool.
David Harel, Rami Marelly

Basic Behavior

Frontmatter
7. Variables and Symbolic Messages
Abstract
In this chapter we present our first extension to the basic constant-message LSCs discussed in Chap. 5. It involves the simplest means LSCs have for specifying generalized scenarios, namely, variables and symbolic messages.
David Harel, Rami Marelly
8. Assignments and Implemented Functions
Abstract
We often want to use data manipulation algorithms and functions that are applied to specified variables. These algorithms and functions usually cannot (and should not) be described using LSC-style interactions between objects but are better viewed as external pieces of computation or logic to be worked into the scenarios. In this chapter we discuss these, and the assignment statements that can be used to apply them.
David Harel, Rami Marelly
9. Conditions
Abstract
In this chapter we discuss guarding conditions in LSCs, and the way their being true or false impacts execution.
David Harel, Rami Marelly
10. Branching and Subcharts
Abstract
In this chapter we discuss ways of using conditions to help control the execution flow of a chart, and how this works with the main LSC structuring mechanism — the subchart.
David Harel, Rami Marelly

Advanced Behavior: Multiple Charts

Frontmatter
11. Executing Multiple Charts
Abstract
In previous chapters we presented various LSC constructs. Besides discussing the play-in process for each construct, we also discussed its semantics when monitoring a system against an LSC specification, and then showed how it can be played out directly within its host LSC. However, the focus so far was on the semantics of the construct within a single LSC. An LSC specification will typically consist of a number (often a large number) of charts, and playout’s most subtle issues arise from their combination and interaction. In this chapter we focus on executing multiple LSCs, as well as on overlapping incarnations of a single LSC.
David Harel, Rami Marelly
12. Testing with Existential Charts
Abstract
Universal charts, which must be satisfied by any run that satisfies their prechart, ‘drive’ the model by their action/reaction nature. In contrast, existential charts, which can get by with only a single satisfying run, can be used as system tests or as examples of object interactions. In this chapter, we deal with the uses of existential charts and the way they are monitored by the Play-Engine.
David Harel, Rami Marelly

Advanced Behavior: Richer Constructs

Frontmatter
13. Loops
Abstract
In this chapter, we discuss how to specify iteration in LSCs, in the form of the various kinds of looping constructs the language supports.
David Harel, Rami Marelly
14. Transition to Design
Abstract
So far, we have seen how the play-in/play-out approach and its implementation in the Play-Engine help in the process of capturing and validating scenario-based behavioral requirements. As we have seen, the graphical user interface of the system is used extensively in both play-in and play-out. In the former the GUI objects are used to specify user actions and system reactions, and in the latter they are used to reflect the system reactions as the specification is executed, and to allow the user to input external events. We have also seen how existential LSCs can be used to specify system tests and how they can be monitored in the Play-Engine for successful completion. If we indeed want to think of our methodology and tool as being useful not only for requirements but also for specifying the system’s actual implementable behavior, we have to talk about making a smooth transition from the requirements phase into the design phase. This chapter is devoted to discussing some of the issues raised by this possibility.
David Harel, Rami Marelly
15. Classes and Symbolic Instances
Abstract
In Chap. 7 we showed how scenarios can be generalized using symbolic messages. Symbolic messages are but one aspect of defining generic scenarios — the simpler one. This chapter addresses symbolic object instances, which is the more complicated and more powerful aspect of genericity.
David Harel, Rami Marelly
16. Time and Real-Time Systems
Abstract
In this chapter, we extend the language of LSCs and the Play-Engine with means for dealing with time. We use a single discrete clock that is linked to the host computer’s internal clock. We also assume the synchrony hypothesis. Hence, in terms of playing out the behavior on an actual simulating computer, we essentially have a real-time mechanism. The resulting extension is extremely expressive.
David Harel, Rami Marelly
17. Forbidden Elements
Abstract
So far, we have shown how the language of LSCs and its various proposed extensions are used to specify what a system can do and what it must do. Of course, the fact that we have hot elements at our disposal allows us to lay out a variety of constraints on the allowed behavior, outlawing parts that we do not want. The ultimate in such disallowed behavior are anti-scenarios, where we use a hot false condition to forbid an entire scenario, the one appearing in the prechart, from occurring.
David Harel, Rami Marelly

Enhancing the Play-Engine

Frontmatter
18. Smart Play-Out (with H. Kugler)
Abstract
In this chapter we provide a brief overview of smart play-out1, a predictive strengthening of the play-out mechanism, which uses methods from program verification — mainly model-checking. 1 Smart play-out is the central topic of the Ph.D. work of Hillel Kugler (cosupervised by Amir Pnueli), who is also the main co-author of this chapter.
David Harel, Rami Marelly
19. Inside and Outside the Play-Engine
Abstract
In this chapter, we give a brief overview of the Play-Engine’s architecture, and provide schematic descriptions of the way it handles its two main functions, play-in and play-out.
David Harel, Rami Marelly
20. A Play-Engine Aware GUI Editor
Abstract
This chapter describes GUIEdit, a rather rudimentary editor we have built to help the user construct GUI applications that can be used with the Play-Engine.
David Harel, Rami Marelly
21. Future Research Directions
Abstract
The play-in/play-out methodology is very new. The first ideas for play-in were conceived of only in 1998, around the time that the first version of the LSCs paper [27] was being written. While we do feel that our work, including its implementation in the form of the Play-Engine, has matured enough to be deserving of a detailed book-length treatment, there are still many issues that have not been dealt with yet at all, and others that require considerable further investigation before they can be finalized. Thus, we regard our work as still being a research-level effort, with much remaining to be done.
David Harel, Rami Marelly
Backmatter
Metadaten
Titel
Come, Let’s Play
verfasst von
David Harel
Rami Marelly
Copyright-Jahr
2003
Verlag
Springer Berlin Heidelberg
Electronic ISBN
978-3-642-19029-2
Print ISBN
978-3-642-62416-2
DOI
https://doi.org/10.1007/978-3-642-19029-2