Section 8.4. Protocol State Machines

8.4. Protocol State Machines

Protocol state machines capture the behavior of a protocol, such as HTTP or a challenge-response speakeasy door. They aren't tied to a particular implementation of a protocol; rather, they specify the state changes and events associated with a protocol-based communication.

Unlike in behavioral state machines, states in protocol state machines represent stable situations where the classifier isn't processing any operation and the user knows its configuration.

Figure 8-16. State machine extension

Protocol state machines differ from behavioral state machines in the following ways:

• entry, exit, and do activities can't be used.

• States can have invariants. Place invariants in square brackets under the state name.

• The keyword protocol is placed in curly braces after the state machine name to indicate the state machine is a protocol state machine.

• Transitions in protocol state machines have a precondition (in place of the guard in normal transitions), the trigger, and a post condition. The notation for a protocol transition is as follows:

     [precondition] event / [postcondition]

• Each transition is associated with zero or one operation on the owning classifier. The transition guarantees that the precondition will be true before the operation is invoked, and that the post condition will be true before entering the target state.

• The effect activity is never specified for a protocol transition.

Figure 8-17 shows a simplified version of the Simple Mail Transport Protocol (SMTP) protocol. Because protocol state machines don't not allow activities, there is little detail about what the SMTP server actually does when receiving a command from the client. By design, the protocol state machine tells you only what state the protocol implementation will be in, not what it does to get there or how it keeps itself occupied. See "Variations on Statechart Diagrams" for an example of modeling a protocol in more detail.