27.07.2013 Views

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

2 Why We Need Model-Based Testing

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

244 Compositional <strong>Model</strong>ing<br />

It is clearly also a trace of M2. It is also a trace of SetupC because it is an instance<br />

of the trace<br />

ReqSetup()<br />

ResSetup(_,_,STATUS("Completed"))<br />

ReqWork()<br />

Cancel()<br />

ResWork()<br />

14.3.2 Crosscutting<br />

It is often easier to write separate model programs for different features and to<br />

use the product construction to create the product rather than creating the product<br />

directly. When creating the product directly, one has to take into account all the<br />

possible combinations of the state variables from the different features. Moreover,<br />

the full model program can be developed incrementally by adding more feature<br />

model programs without having to change the existing ones.<br />

Another advantage of creating separate model programs is that it helps to separate<br />

crosscutting concerns by using distinct state variables and in this way simplifies<br />

compositional reasoning. Imagine, for example, a model program with a single<br />

feature that includes all the features of SP. When doing so, it is natural to introduce<br />

a single state variable that maps request IDs to compound “request info” values. A<br />

request info describes the relevant information about a pending request in a given<br />

state, namely the command associated with it, the mode of the request, and the<br />

number of requested credits. Separate analysis of the features now requires fairly<br />

sophisticated analysis techniques because the state information about the different<br />

features is stored in a shared state variable.<br />

14.3.3 Trace inclusion<br />

For scenario control, it is sometimes useful to refer to the state variables of a feature<br />

of a model program in order to write a scenario for it. In other words, there is a given<br />

model program M with a feature F1 that is the contract and there is a dependent<br />

feature F2 of M that may read the state variables of F1 but it may not change the<br />

values of those variables. A property that is preserved in this case is that the set of<br />

traces of M[F1]isasuperset of the set of traces of M[F1,F2]. Such use of features<br />

is usually safe because no new traces can arise.<br />

Two typical uses of dependent features for scenario control are state-dependent<br />

parameter generation and enabling condition strengthening. Both uses were illustrated<br />

earlier in this chapter with the CreditScenario scenario in Figure 14.16.<br />

more free ebooks download links at:<br />

http://www.ebook-x.com

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!