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.
5.6.2 Code
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.
Pages:
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123