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

2

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?

uml state-machines

share|improve this question

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Actually the 2.5 specs are very explicit on that. OMG even released a paper specifically for state machines: omg.org/spec/PSSM/About-PSSM Unfortunately it's not my domain so I can't answer the question.
  
  – Thomas Kilian
  Nov 20 '18 at 18:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I don't know what the spec says. But it'd find it weird behavior if the order of events in the deferred queue would be changed (by checks). I'd expect that deferred events stay in the queue and that the algorithm checks starting at the "old" end of the queue and works its way to the "young" end. If it finds a non-deferred event, it takes it out of the queue and processes it (possibly by discarding it). I cannot think of any situation where enqueue would make more sense - or any sense for a fact.
  
  – DrP3pp3r
  Nov 20 '18 at 19:37
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Thomas Kilian, thank you for the document link. I didn't know the document. I will check it. In ptc-17-04-04.pdf, 9.3.16 Deferred seems to be what I wanted to. At first, I got confused because there is no /defer notation, but now I understand note(UML) Deferes Continue means Continue/defer. I don't know why the author doesn't use UML notation. Anyway, I will check the document covers my case.
  
  – Takatoshi Kondo
  Nov 20 '18 at 23:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @DrP3pp3r, thank you for the comment. You mean the state should be s4 after all events are processed because e1 is sent before e3. I think that it is reasonable. But I think the processing order of the deferred events might be unspecified in the UML spec. If it is unspecified, the state-machine library author can choose other way. Boost.MSM, C++ state-machine library that supports UML 2.x semantics, seems to de-queued and en-queued, so the final state is s5. Here is the test code wandbox.org/permlink/v5hRtdJXRek8RidW
  
  – Takatoshi Kondo
  Nov 21 '18 at 1:40
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @TakatoshiKondo. Yes, that's what I meant. I've got to check if yasmine behaves correctly.
  
  – DrP3pp3r
  Nov 21 '18 at 5:56
  

  
  
  
  

 | 
show 1 more comment

2

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?

uml state-machines

share|improve this question

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Actually the 2.5 specs are very explicit on that. OMG even released a paper specifically for state machines: omg.org/spec/PSSM/About-PSSM Unfortunately it's not my domain so I can't answer the question.
  
  – Thomas Kilian
  Nov 20 '18 at 18:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I don't know what the spec says. But it'd find it weird behavior if the order of events in the deferred queue would be changed (by checks). I'd expect that deferred events stay in the queue and that the algorithm checks starting at the "old" end of the queue and works its way to the "young" end. If it finds a non-deferred event, it takes it out of the queue and processes it (possibly by discarding it). I cannot think of any situation where enqueue would make more sense - or any sense for a fact.
  
  – DrP3pp3r
  Nov 20 '18 at 19:37
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Thomas Kilian, thank you for the document link. I didn't know the document. I will check it. In ptc-17-04-04.pdf, 9.3.16 Deferred seems to be what I wanted to. At first, I got confused because there is no /defer notation, but now I understand note(UML) Deferes Continue means Continue/defer. I don't know why the author doesn't use UML notation. Anyway, I will check the document covers my case.
  
  – Takatoshi Kondo
  Nov 20 '18 at 23:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @DrP3pp3r, thank you for the comment. You mean the state should be s4 after all events are processed because e1 is sent before e3. I think that it is reasonable. But I think the processing order of the deferred events might be unspecified in the UML spec. If it is unspecified, the state-machine library author can choose other way. Boost.MSM, C++ state-machine library that supports UML 2.x semantics, seems to de-queued and en-queued, so the final state is s5. Here is the test code wandbox.org/permlink/v5hRtdJXRek8RidW
  
  – Takatoshi Kondo
  Nov 21 '18 at 1:40
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @TakatoshiKondo. Yes, that's what I meant. I've got to check if yasmine behaves correctly.
  
  – DrP3pp3r
  Nov 21 '18 at 5:56
  

  
  
  
  

 | 
show 1 more comment

2

2

2

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?

uml state-machines

share|improve this question

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

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?

uml state-machines

uml state-machines

share|improve this question

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

share|improve this question

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

share|improve this question

share|improve this question

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

asked Nov 20 '18 at 10:11

Takatoshi KondoTakatoshi Kondo

1,290915

1,290915

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Actually the 2.5 specs are very explicit on that. OMG even released a paper specifically for state machines: omg.org/spec/PSSM/About-PSSM Unfortunately it's not my domain so I can't answer the question.
  
  – Thomas Kilian
  Nov 20 '18 at 18:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I don't know what the spec says. But it'd find it weird behavior if the order of events in the deferred queue would be changed (by checks). I'd expect that deferred events stay in the queue and that the algorithm checks starting at the "old" end of the queue and works its way to the "young" end. If it finds a non-deferred event, it takes it out of the queue and processes it (possibly by discarding it). I cannot think of any situation where enqueue would make more sense - or any sense for a fact.
  
  – DrP3pp3r
  Nov 20 '18 at 19:37
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Thomas Kilian, thank you for the document link. I didn't know the document. I will check it. In ptc-17-04-04.pdf, 9.3.16 Deferred seems to be what I wanted to. At first, I got confused because there is no /defer notation, but now I understand note(UML) Deferes Continue means Continue/defer. I don't know why the author doesn't use UML notation. Anyway, I will check the document covers my case.
  
  – Takatoshi Kondo
  Nov 20 '18 at 23:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @DrP3pp3r, thank you for the comment. You mean the state should be s4 after all events are processed because e1 is sent before e3. I think that it is reasonable. But I think the processing order of the deferred events might be unspecified in the UML spec. If it is unspecified, the state-machine library author can choose other way. Boost.MSM, C++ state-machine library that supports UML 2.x semantics, seems to de-queued and en-queued, so the final state is s5. Here is the test code wandbox.org/permlink/v5hRtdJXRek8RidW
  
  – Takatoshi Kondo
  Nov 21 '18 at 1:40
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @TakatoshiKondo. Yes, that's what I meant. I've got to check if yasmine behaves correctly.
  
  – DrP3pp3r
  Nov 21 '18 at 5:56
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Actually the 2.5 specs are very explicit on that. OMG even released a paper specifically for state machines: omg.org/spec/PSSM/About-PSSM Unfortunately it's not my domain so I can't answer the question.
  
  – Thomas Kilian
  Nov 20 '18 at 18:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I don't know what the spec says. But it'd find it weird behavior if the order of events in the deferred queue would be changed (by checks). I'd expect that deferred events stay in the queue and that the algorithm checks starting at the "old" end of the queue and works its way to the "young" end. If it finds a non-deferred event, it takes it out of the queue and processes it (possibly by discarding it). I cannot think of any situation where enqueue would make more sense - or any sense for a fact.
  
  – DrP3pp3r
  Nov 20 '18 at 19:37
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Thomas Kilian, thank you for the document link. I didn't know the document. I will check it. In ptc-17-04-04.pdf, 9.3.16 Deferred seems to be what I wanted to. At first, I got confused because there is no /defer notation, but now I understand note(UML) Deferes Continue means Continue/defer. I don't know why the author doesn't use UML notation. Anyway, I will check the document covers my case.
  
  – Takatoshi Kondo
  Nov 20 '18 at 23:50
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @DrP3pp3r, thank you for the comment. You mean the state should be s4 after all events are processed because e1 is sent before e3. I think that it is reasonable. But I think the processing order of the deferred events might be unspecified in the UML spec. If it is unspecified, the state-machine library author can choose other way. Boost.MSM, C++ state-machine library that supports UML 2.x semantics, seems to de-queued and en-queued, so the final state is s5. Here is the test code wandbox.org/permlink/v5hRtdJXRek8RidW
  
  – Takatoshi Kondo
  Nov 21 '18 at 1:40
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @TakatoshiKondo. Yes, that's what I meant. I've got to check if yasmine behaves correctly.
  
  – DrP3pp3r
  Nov 21 '18 at 5:56
  

  
  
  
  

Actually the 2.5 specs are very explicit on that. OMG even released a paper specifically for state machines: omg.org/spec/PSSM/About-PSSM Unfortunately it's not my domain so I can't answer the question.

– Thomas Kilian
Nov 20 '18 at 18:35

Actually the 2.5 specs are very explicit on that. OMG even released a paper specifically for state machines: omg.org/spec/PSSM/About-PSSM Unfortunately it's not my domain so I can't answer the question.

– Thomas Kilian
Nov 20 '18 at 18:35

I don't know what the spec says. But it'd find it weird behavior if the order of events in the deferred queue would be changed (by checks). I'd expect that deferred events stay in the queue and that the algorithm checks starting at the "old" end of the queue and works its way to the "young" end. If it finds a non-deferred event, it takes it out of the queue and processes it (possibly by discarding it). I cannot think of any situation where enqueue would make more sense - or any sense for a fact.

– DrP3pp3r
Nov 20 '18 at 19:37

I don't know what the spec says. But it'd find it weird behavior if the order of events in the deferred queue would be changed (by checks). I'd expect that deferred events stay in the queue and that the algorithm checks starting at the "old" end of the queue and works its way to the "young" end. If it finds a non-deferred event, it takes it out of the queue and processes it (possibly by discarding it). I cannot think of any situation where enqueue would make more sense - or any sense for a fact.

– DrP3pp3r
Nov 20 '18 at 19:37

@Thomas Kilian, thank you for the document link. I didn't know the document. I will check it. In ptc-17-04-04.pdf, 9.3.16 Deferred seems to be what I wanted to. At first, I got confused because there is no /defer notation, but now I understand note(UML) Deferes Continue means Continue/defer. I don't know why the author doesn't use UML notation. Anyway, I will check the document covers my case.

– Takatoshi Kondo
Nov 20 '18 at 23:50

@Thomas Kilian, thank you for the document link. I didn't know the document. I will check it. In ptc-17-04-04.pdf, 9.3.16 Deferred seems to be what I wanted to. At first, I got confused because there is no /defer notation, but now I understand note(UML) Deferes Continue means Continue/defer. I don't know why the author doesn't use UML notation. Anyway, I will check the document covers my case.

– Takatoshi Kondo
Nov 20 '18 at 23:50

@DrP3pp3r, thank you for the comment. You mean the state should be s4 after all events are processed because e1 is sent before e3. I think that it is reasonable. But I think the processing order of the deferred events might be unspecified in the UML spec. If it is unspecified, the state-machine library author can choose other way. Boost.MSM, C++ state-machine library that supports UML 2.x semantics, seems to de-queued and en-queued, so the final state is s5. Here is the test code wandbox.org/permlink/v5hRtdJXRek8RidW

– Takatoshi Kondo
Nov 21 '18 at 1:40

@DrP3pp3r, thank you for the comment. You mean the state should be s4 after all events are processed because e1 is sent before e3. I think that it is reasonable. But I think the processing order of the deferred events might be unspecified in the UML spec. If it is unspecified, the state-machine library author can choose other way. Boost.MSM, C++ state-machine library that supports UML 2.x semantics, seems to de-queued and en-queued, so the final state is s5. Here is the test code wandbox.org/permlink/v5hRtdJXRek8RidW

– Takatoshi Kondo
Nov 21 '18 at 1:40

@TakatoshiKondo. Yes, that's what I meant. I've got to check if yasmine behaves correctly.

– DrP3pp3r
Nov 21 '18 at 5:56

@TakatoshiKondo. Yes, that's what I meant. I've got to check if yasmine behaves correctly.

– DrP3pp3r
Nov 21 '18 at 5:56

 | 
show 1 more comment

1 Answer
1

active

oldest

votes

1

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.

share|improve this answer

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question. Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.


• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53390674%2fcorrect-order-of-deferred-events-in-state-machine-of-uml-2-x%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

1

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.

share|improve this answer

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

add a comment | 

1

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.

share|improve this answer

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

add a comment | 

1

1

1

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.

share|improve this answer

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

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.

share|improve this answer

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

share|improve this answer

share|improve this answer

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

answered Nov 21 '18 at 4:05

Takatoshi KondoTakatoshi Kondo

1,290915

1,290915

add a comment | 

add a comment | 

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question. Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.


• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question. Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.


• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53390674%2fcorrect-order-of-deferred-events-in-state-machine-of-uml-2-x%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

This page is only for reference, If you need detailed information, please check here