2 Why We Need Model-Based Testing
2 Why We Need Model-Based Testing
2 Why We Need Model-Based Testing
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
228 Compositional <strong>Model</strong>ing<br />
terms) that are considered when combining actions, not the methods (the C# code).<br />
Section 14.3 (below) explains in detail how actions are combined.<br />
The action ReqSetup(m,c), where m is a message ID and c a requested number of<br />
credits, has an update rule, given by the method Req, that records in the state variable<br />
requests that m has an outstanding credit request for c credits, and removes m from<br />
the window. The guard of this update rule is defined by the conjunction of the two<br />
predicates (Boolean methods) named ReqEnabled (recall that an action method is<br />
enabled only when all of its enabling conditions are true). The first predicate requires<br />
m to appear in the window, and the second one requires c to be positive.<br />
A Requirement attribute associated with each of the predicates provides a connection<br />
between the model program and the corresponding section or paragraph in<br />
the natural language document, and motivates the split of the enabling condition<br />
into two predicates, rather than just one predicate.<br />
The action ResSetup(m,c, ), where m is a message ID and c is a granted number<br />
of credits, has an update rule given by the action method Res. It adds to the window<br />
the set of new IDs {maxId + 1,...,maxId + c}, which is empty if c is zero, records<br />
that the new maximum ID is maxId + c and removes m from the pending requests<br />
map. This action is enabled if m is an outstanding request, and the granted credits<br />
do not exceed the requested credits.<br />
Accepting states<br />
It is useful to identify those states where no requests are pending. From the clients<br />
point of view, these are states where the server is stable; that is, the server is not<br />
processing a request. All accepting traces of the credits model program have to end<br />
in an accepting state.<br />
State invariants<br />
An important property of the credits algorithm is that the client must not starve. In<br />
other words, it should never be the case that the client runs out of credits and cannot<br />
send further requests. This does not mean that the server always has to grant at<br />
least one credit to the client in every response. It may be that the client has pending<br />
requests that will eventually grant the client more credits. Thus, the state invariant<br />
is that if there are no pending requests then the window must be nonempty.<br />
Exploration<br />
A natural question that arises here is whether the model program in Figure 14.1 has<br />
any unsafe states, that is, states reachable from the initial state that violate the state<br />
invariant. If this is the case then the model program should be amended.<br />
To explore the credits model program, we use a finite state machine (FSM)<br />
model program that restricts the credits model program to a finite set of states (see<br />
more free ebooks download links at:<br />
http://www.ebook-x.com
Change language