15.3.6 ProtocolStateMachine

*Generalizations

   • StateMachine (from BehaviorStateMachines ) on page 586

   Description

   A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier can be called in which state and under which condition, thus specifying the allowed call sequences on the classifier’s operations. A protocol state machine presents the possible and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions. In this manner, an instance lifecycle can be created for a classifier, by specifying the order in which the operations can be activated and the states through which an instance progresses during its existence.

   Attributes

   No additional attributes

   Associations Constraints

   [1] A protocol state machine must only have a classifier context, not a behavioral feature context.

   (not context->isEmpty( )) and specification->isEmpty()

   [2] All transitions of a protocol state machine must be protocol transitions. (transitions as extended by the ProtocolStateMachines package).

   region->forAll(r | r.transition->forAll(t | t.oclIsTypeOf(ProtocolTransition )))

   [3] The states of a protocol state machine cannot have entry, exit, or do activity actions.

Issue 8407 -add missing parentheses

   region->forAll(r | r.subvertex->forAll(v | v.oclIsKindOf(State) implies (v.entry->isEmpty() and v.exit->isEmpty() and v.doActivity->isEmpty())))

   [4] Protocol state machines cannot have deep or shallow history pseudostates.

   region->forAll (r | r.subvertex->forAll (v | v.oclIsKindOf(Psuedostate) implies ((v.kind <> #deepHistory) and (v.kind <> #shallowHistory)))))

   [5] If two ports are connected, then the protocol state machine of the required interface (if defined) must be conformant to the protocol state machine of the provided interface (if defined).

   Semantics

   Protocol state machines help define the usage mode of the operations and receptions of a classifier by specifying:

• In which context (under which states and pre conditions) they can be used.

• If there is a protocol order between them.

• What result is expected from their use.

   The states of a protocol state machine (protocol states) present an external view of the class that is exposed to its clients. Depending on the context, protocol states can correspond to the internal states of the instances as expressed by behavioral state machines, or they can be different.

   A protocol state machine expresses parts of the constraints that can be formulated for pre- and post conditions on operations. The translation from protocol state machine to pre- and post conditions on operations might not be straightforward, because the conditions would need to account for the operation call history on the instance, which may or may not be directly represented by its internal states. A protocol state machine provides a direct model of the state of interaction with the instance, so that constraints on interaction are more easily expressed.

   The protocol state machine defines all allowed transitions for each operation. The protocol state machine must represent all operations that can generate a given change of state for a class. Those operations that do not generate a transition are not represented in the protocol state machine.

   Protocol state machines constitute a means to formalize the interface of classes, and do not express anything except consistency rules for the implementation or dynamics of classes.

   Protocol state machine interpretation can vary from:

1. Declarative protocol state machines that specify the legal transitions for each operation. The exact triggering condition for the operations is not specified. This specification only defines the contract for the user of the context classifier.

2. Executable protocol state machines, that specify all events that an object may receive and handle, together with the transitions that are implied. In this case, the legal transitions for operations will exactly be the triggered transitions. The call trigger specifies the effect action, which is the call of the associated operation.

   The representation for both interpretations is the same, the only difference being the direct dynamic implication that the interpretation 2 provides.

Issue 8407 -fix hyphenation

   Elaborated forms of state machine modeling such as compound transitions, sub-state machines, composite states, and concurrent regions can also be used for protocol state machines. For example, concurrent regions make it possible to express protocol where an instance can have several active states simultaneously. sub state machines and compound transitions are used as in behavioral state machines for factorizing complex protocol state machines.

   A classifier may have several protocol state machines. This happens frequently, for example, when a class inherits several parent classes having protocol state machine, when the protocols are orthogonal. An alternative to multiple protocol state machines can always be found by having one protocol state machine, with sub state machines in concurrent regions.

   Notation

   The notation for protocol state machine is very similar to the one of behavioral state machines. The keyword {protocol} placed close to the name of the state machine differentiates graphically protocol state machine diagrams.