2 Why We Need Model-Based Testing

7 Structuring Model
Programs with
Features and
Composition
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.
7.1 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. But is it useful to consider every run? In other words, does every
run have a different effect? Let’s look more closely. Figure 7.2 shows the first few
transitions of all the runs, where the client and server each perform the initial actions
of the protocol shown in Chapter 2, Figure 2.2: the server executes Socket, Bind,
more free ebooks download links at:
http://www.ebook-x.com
115