2 Why We Need Model-Based Testing

134 Structuring Model Programs with Features and Composition
0
Message("99.9")
1
Message("999.9")
2
Calibrate()
3
Figure 7.18. Reactive system: scenario FSM for safety analysis.
The preceding example resembles simulation or interactive exploration in checking
just one run. But a scenario model program can describe more than one run.
In the next example we take advantage of this to reveal the safety violations in the
reactive system that we exposed by a different technique in Chapter 6, Section 6.3.1.
Recall that we had to write a Boolean expression that described the safe states. Now
we will describe the safety violation in terms of actions, not states.
A safety violation occurs if the program performs a calibration after it receives a
message that contains an out-of-range temperature. In order to enable the calibration,
the program must first receive an in-range temperature. The safety violation can be
described by a scenario that contains just those three actions:
FSM(0,AcceptingStates(),Transitions(
t(0,Message("99.9"),1),
t(1,Message("999.9"),2),
t(2,Calibrate(),3)))
It is not necessary to include any other action in the scenario, because they will
be filled-in by interleaving when we compose the scenario with the contract model
program. Recall that any actions that are not explicitly included in the vocabulary of
the scenario model program can interleave among its actions when it is composed.
Here we make use of that fact to complete the runs. Many interleavings are possible,
so this scenario describes many runs.
We compose this scenario machine (whose FSM appears in Figure 7.18) with
the contract model program (whose FSM, with unsafe states highlighted, appears in
Figure 6.9 in Chapter 6). The projection of the product onto the scenario resembles
more free ebooks download links at:
http://www.ebook-x.com