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?
uml state-machine
|
show 1 more comment
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-machine
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. Inptc-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
meansContinue/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 iss5
. 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
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-machine
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-machine
uml state-machine
asked Nov 20 '18 at 10:11
Takatoshi KondoTakatoshi Kondo
1,305915
1,305915
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. Inptc-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
meansContinue/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 iss5
. 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. Inptc-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
meansContinue/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 iss5
. 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
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.
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
});
}
});
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
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
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 21 '18 at 4:05
Takatoshi KondoTakatoshi Kondo
1,305915
1,305915
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.
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
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
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
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
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
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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
meansContinue/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