Previous UML Classes Table of Contents UML Packages Next


15.3.7 ProtocolTransition

ProtocolStateMachines


*Generalizations

   • Transition (from BehaviorStateMachines ) on page 594

   Description

   A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for an operation. Transitions of protocol state machines have the following information: a pre condition (guard), on trigger, and a post condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that belongs to the context classifier of the protocol state machine.

   The protocol transition specifies that the associated (referred) operation can be called for an instance in the origin state under the initial condition (guard), and that at the end of the transition, the destination state will be reached under the final condition (post).

   Attributes

   No additional attributes

   Associations

Issue

8408 -change ‘\’ to ‘/’

/referred: Operation[0..*] This association refers to the associated operation. It is derived from the operation of
the call trigger when applicable.

Issue 8446 -add subsets constraints 9196 -add subsets ‘ownedRule’

   Constraints

   [1] A protocol transition always belongs to a protocol state machine.

   container.belongsToPSM()

   [2] A protocol transition never has associated actions.

   effect->isEmpty()

   [3] If a protocol transition refers to an operation (i.e., has a call trigger corresponding to an operation), then that operation should apply to the context classifier of the state machine of the protocol transition.

   Additional Operations

   [1] The operation belongsToPSM () checks if the region belongs to a protocol state machine.

   context Region ::belongsToPSM () : Boolean result = if not stateMachine->isEmpty() then

   oclIsTypeOf(ProtocolStateMachine)else if not state->isEmpty() thenstate.container.belongsToPSM ()else false

   Semantics

   No effect action

   The effect action is never specified. It is implicit, when the transition has a call trigger: the effect action will be the operation specified by the call trigger. It is unspecified in the other cases, where the transition only defines that a given event can be received under a specific state and pre-condition, and that a transition will lead to another state under a specific post condition, whatever action will be made through this transition.

   Unexpected event reception

   The interpretation of the reception of an event in an unexpected situation (current state, state invariant, and pre-condition) is a semantic variation point: the event can be ignored, rejected, or deferred; an exception can be raised; or the application can stop on an error. It corresponds semantically to a pre-condition violation, for which no predefined behavior is defined in UML.

   Unexpected behavior

   The interpretation of an unexpected behavior, that is an unexpected result of a transition (wrong final state or final state invariant, or post condition) is also a semantic variation point. However, this should be interpreted as an error of the implementation of the protocol state machine.

   Equivalences to pre and post conditions of operations

   A protocol transition can be semantically interpreted in terms of pre-and post conditions on the associated operation. For example, the transition in Fig ure 15.13 can be interpreted in the following way:

   






   Figure 15.13 - Example of a protocol transition associated to the "m1" operation

   Operations referred by several transitions


   Figure 15.14 -Example of several transitions referring to the same operation

Issue 8408 -add figure number cross-refernce

   In a protocol state machine, several transitions can refer to the same operation as illustrated in Figure 15.14 . In that case, all pre-and post conditions will be combined in the operation pre-condition as shown below:

   Operation m1()

   Pre: S1 is in the configuration state and C1

    or

    S3 is in the configuration state and C3

   Post: if the initial condition was S1 is in the configuration state and C1

   then S2 is in the configuration state and C2

    else

   if the initial condition was S3 is in the configuration state and C3

   then S4 is in the configuration state and C4

   A protocol state machine specifies all the legal transitions for each operation referred by its transitions. This means that for any operation referred by a protocol state machine, the part of its precondition relative to legal initial or final state is completely specified by the protocol state machine.

   Unreferred Operations

   If an operation is not referred by any transition of a protocol state machine, then the operation can be called for any state of the protocol state machine, and does not change the current state.

   Using events in protocol state machines

   Apart from the operation call event, events are generally used for expressing a dynamic behavior interpretation of protocol state machines. An event that is not a call event can be specified on protocol transitions.

   In this case, this specification is a requirement to the environment external to the state machine: it is legal to send this event to an instance of the context classifier only under the conditions specified by the protocol state machine.

   Just like call event, this can also be interpreted in a dynamic way, as a semantic variation point.

   Notation

   The usual state machine notation applies. The difference is that no actions are specified for protocol transitions, and that post conditions can exist. Post conditions have the same syntax as guard conditions, but appear at the end of the transition syntax.

   




   Figure 15.15 - Protocol transition notation