There is one model program per feature. The composition
of all the feature model programs is the model program of the whole system. It
helps to separate concerns and helps to keep the individual feature model programs
managable size. When the features use disjoint state variables it is a matter of style
whether to introduce separate model programs (with distinct namespaces) or to use a
single model program (with a single namespace) and with multiple Feature classes.
14.4.2 Scenario control
The most common style of scenario contol is to write an FSM model program that
describes a particular pattern of actions. Such a pattern is usually a regular expression
(see also Exercise 4 in this connection). For testing, there is often a startup phase
consisting of a particular sequence of actions that drive the system under test to a
particular state, followed by an exploration phase that allows most of the actions to
be explored exhaustively, followed by a finalization phase that is again a particular
sequence of actions that causes the system under test to be cleaned up so that a new
test run can be started.
For scenario control one can also use dependent features of model programs for
state-dependent enabling condition strengthening.
14.4.3 Parameter generation
A typical use of FSM model programs is to restrict parameter domains of actions of
the contract model program so that the composition of the contract model program
and the FSM scenario is explorable.
Pages:
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326