2 Why We Need Model-Based Testing

Advanced Topics 225
Only a subset of the information that is present in the concrete messages of the protocol
is relevant for modeling these protocol features. Therefore, concrete messages
of the protocol are mapped to the abstract actions of the model program as follows.
Each message has a particular command field that indicates the operation requested
by the client or responded by the server. For this protocol it is natural to map the kind
of the message, that is, whether it is a request or a response message, together with
the command field of the message to one action symbol. This is because there are
only a couple of dozen commands in total and different features are very naturally
related to different groups of commands. Without loss of generality, we suppose that
the commands are Setup, Work, and Cancel. The corresponding action symbols are
as follows:
• ReqSetup and ReqWork are action symbols that represent requests from the client
to execute the commands Setup and Work, respectively. A setup (work) request
is an action ReqSetup(m,c) (ReqWork(m,c)), where m is a message ID and c is a
number of requested credits.
• ResSetup and ResWork are action symbols that represent responses from the
server to commands Setup and Work, respectively. A setup (work) response is
an action ResSetup(m,c,s) (ResWork(m,c,s)), where m is a message ID, c is a
number of granted credits, and s is a status value.
• Cancel is used as an action symbol that represents a request from the client to
cancel a previous operation; that is, the command is Cancel. Acancel request
has the form Cancel(m), where m is a message ID. There is no response to a
cancel request.
Each action symbol has a number of parameters that corresponds to the number of
relevant fields in the messages. As said, not all of the fields of messages are relevant.
If we were to consider more features of the protocol, the number of parameters of
the action symbols would be bigger but the remaining arguments would be ignored
in the model programs of the above features.
14.2.1 Credits feature
The protocol is designed to prevent the client from overwhelming the server with too
many requests. The client can only use certain message identifiers to communicate
with the server. Each identifier can only be used once. The identifiers that the client
can use can be seen as a pool of numbers. The client can ask for additional credits
in the requests that it sends to the server in order to expand the pool. The server
may grant credits in its responses to the client. The number of credits granted by the
server determines how the pool grows or shrinks as time progresses. There is quite
more free ebooks download links at:
http://www.ebook-x.com