[SOLVED] Correct order of deferred events in state-machine of UML 2.x

Correct order of deferred events in state-machine of UML 2.x

UML 2.x's state-machine diagram supports deferred events. Here is the state-machine.

When I send e1, e2, e3, and e4 to the sm1 in this order, which is the expected state? If e1 is de-queued from the defer queue and en-queue again to the defer queue in s2, and e2 is consumed to transition to s3, the head of the defer queue is e3 in s3, so that the expected state is s5. However, If e1 keeps the original position (head) and skip it, then e2 is consumed, the expected state is s4.

Does the UML 2.x specification define which is correct?

Solution

Thanks to the comments, I got the answer.

Deferred event position

I use the word defer queue in the state-machine diagram, but there is no such concept in UML 2.5.1(latest) specification.

See the site: https://www.omg.org/spec/UML/About-UML/

the file: formal-17-12-05.pdf

UML 2.5.1 defines event pool.

In the 14.2.3.4.4 State history,

--start quote

Deferred Events

A State may specify a set of Event types that may be deferred in that State. This means that Event occurrences of those types will not be dispatched as long as that State remains active. Instead, these Event occurrences remain in the event pool until:

a state configuration is reached where these Event types are no longer deferred or,
if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State (i.e., a kind of override option).

An Event may be deferred by a composite State or submachine States, in which case it remains deferred as long as the composite State remains in the active configuration.

--end quote

The important point is "Instead, these Event occurrences remain in the event pool until". The word remain implies keeping the original position in the event pool.

Event evaluation order

The events in the event pool has order.

See the site: https://www.omg.org/spec/PSSM/About-PSSM/

the file: ptc-17-04-04.pdf

9.3.16.2 Deferred 001, RTC Steps Step7 indicates that the event evaluating order is head("old") to tail("young").

Conclusion

The event evaluation order in the event pool is head to tail. Deferred events are just remained their original position. Hence e1 should be evaluated at s3 in my diagram.

Note

The Boost.MSM (version 1.68.0) implementation is not correct. https://wandbox.org/permlink/v5hRtdJXRek8RidW

I will report the issue about that.