In this chapter we describe two mechanisms for structuring model programs at a large scale: features and composition. Each provides a way to combine model programs in order to create a new one, or to write a model program as a collection of parts that are themselves complete (or nearly complete) model programs.

Both mechanisms are so versatile that they can be used in many ways. In Chapter 14 we use them to model interacting features. In this chapter we use them to limit analysis and testing to particular scenarios of interest. We also show how composition can be used in analysis to check temporal properties defined by sequences of actions.

Scenario control

The problem of limiting analysis and testing to particular runs of interest is called scenario control. Scenario control is necessary because we usually write a model program to act as a specification or contract, so it describes everything the implementation must do, might do, and must not do. As a result, the model program usually describes a large number of runs. When we analyze, and especially when we test, we usually do not want to consider all of these runs. We would like to limit our consideration to a particular scenario: a collection of runs (perhaps just one) that are pertinent to some issue.

Here is an example that shows why we need scenario control. Figure 7.1 shows the true FSM we obtained by exploring the client/server model program we developed in Chapter 5, Section 5.6. There are many paths through this FSM; each path describes a different run.