umlstate-machine

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. state-machine-diagram

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:

    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.