2 Why We Need Model-Based Testing

5.6.2 Code
Systems with Finite Models 75
are sensitive to the number of digits, so we choose 99.9 and 100.0. These particular
values are not important; we assume that any other numbers with the same number
of digits would behave the same way. Limiting temperatures to just two values is an
example of data abstraction.
There are several ways to limit the temperature to two values. We could replace the
numeric type with an enumerated type. We could even replace the single ServerSend
method (where the temperature is a parameter) with two parameterless methods,
each coded with one particular temperature. It is more convenient for testing if the
methods and parameters are similar in the model and the implementation, so we keep
the single method with its numeric parameter, but limit the number of parameter
values with the Domain attribute, which we will describe in the next section.
The actions and state variables we chose determine the level of abstraction of this
model program. Many implementation details are left out. We do not need any actual
network machinery (IP addresses, port numbers, sockets, etc.) because we model the
client, the server, and the network in a single model program. Other simplifications
become possible because the model program can use global information that is not
available to the separate client and server programs of the implementation. This will
become clear in the next section.
The client/server model program appears in Figures 5.7–5.11. Compare this to
the implementation code in Chapter 2, Figures 2.3–2.5. Usually a model program
is much shorter than the implementation. That is not the case here, because the
implementation is so simple (it is really just a wrapper around some methods in
the .NET socket class). Much of the code in the model is enabling conditions,
which describe the control structure that must be present in any applications that
use the implementation (such as Monitor and Logger, Chapter 2, Section 2.5). The
structure of this model program, like all model programs, is similar to the first one
(Section 5.4, Figures 5.4 and 5.5). The following paragraphs explain some features
that might not be obvious.
Unlike the implementation, here the client and server are not instances. The state
of both client and server are static variables in one static class, and the actions of both
are static methods in this class. Therefore, we use a C# static class. The compiler
checks that all the variables and methods in a static class are declared static.
There are different methods for the actions of the client and the server, with
different names. The ClientSocket and ServerSocket action methods here model
the Socket methods of the client and server classes in the implementation, and so
on. All of the action methods in a model (in the model namespace) must have
different names. It is possible to have more than one class in a model, but even then
more free ebooks download links at:
http://www.ebook-x.com