An important property of protocols is that enough information is present in
messages, usually in message headers, so that it is possible to maintain a consistent
view of the state of the protocol on both sides of the protocol users.
In the protocol model in this chapter, the actions of the model program represent
the messages of the protocol. A run of the model program represents a session where
client and server exchange messages, as shown in Figure 14.18. The steps we follow
in the feature-oriented modeling of a protocol are the following:
223
224 Compositional Modeling
1. First, the action vocabulary is identified. Typically the action vocabulary corresponds
to the set of possible value combinations of particular fields in the
message header. Consider for example two fields, one that identifies whether a
message is a Request or a Response, and another field that identifies a particular
operation that is being performed, say a Read or a Write. The actions symbols
could then be ReadRequest, ReadResponse, WriteRequest, WriteResponse.
2. Second, a mapping is defined from concrete messages ???on the wire??? to abstract
actions in the model program. This mapping may omit all fields of a message
that are not used in any of the features. For example, fields that represent layout
constraints on the message structure may be omitted.
3. Third, a separate model program is written for each feature.
Pages:
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298