*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’
• postCondition: Constraint[0..1] Specifies the post condition of the transition, which is the condition that should be obtained once the transition is triggered. This post condition is part of the post condition of the operation connected to the transition. {Subsets Element::ownedElement and subsets Namespace ::ownedRule}
• preCondition: Constraint[0..1] Specifies the precondition of the transition. It specifies the condition that should be verified before triggering the transition. This guard condition added to the source state will be evaluated as part of the precondition of the operation referred by the transition if any. {Subsets Transition::guard and subsets Namespace ::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:
1. The operation m1 can be called on an instance when it is in the protocol state S1 under the condition C1.
2. When m1 is called in the protocol state S1 under the condition C1, then the protocol state S2 must be reached under the condition C2.
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