New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entry/exit actions on composite states? #43
Comments
Thanks @Ulenspiegel for reporting this issue. Your investigation is right, it was a bug, which should be fixed now by krzysztof-jusiak/msm-lite@8bb2bc9. The problem was that I will also verify your second concern with on_entry/on_exit not being called when transitioning to/from composite state. |
Yup, compiles and runs just fine now. The issue doesn't seem to be completely fixed, though: it appears that composite state's
on_entry /on_exit defined on ls* leaf states. |
Thanks @Ulenspiegel, you are right,
The order of entering sub state machine is reveresed though.
I'm not sure whether it should be like that or the way you have specified it. I tried to look for it in the UML spec, but I couldn't find an definite answer? |
That's just fantastic; thanks! I think the fix already covers most use cases, provided one's careful about ordering. As for order of entry/exit actions, I'm looking at UML state machine article in wiki, last paragraph in "Entry and exit actions" chapter:
In UML 2.5 spec, I think it's implied in chapter 14.2.3.9.6 "Transition execution sequence" — states are exited from bottom up towards lowest common ancestor, and then downwards to the target state, as on the illustration. I think the part "...execution of Behaviors follows the rules of State entry (or composite State entry) described earlier" implies that external transitions trigger entry/exit events the usual way, when state is exited/entered (14.2.3.4.3). Take a closer look and double check, just in case I misread that section. I think it's also the least surprise way — logically, nested state inherits behaviour of composite state, so in a way, nested state has "is-a" relation to its enclosing state. So, entry action of composite state must enforce invariants that should always hold true when any nested state is entered. |
on_entry /on_exit defined on ls* leaf states. |
Hm-m... Is it right, though? I think ordering of entry is still broken - leaf states ("Entering ls1_1" on the line before last, for instance) are activated before their parent states ("Entering ss1" on the last line). |
Thanks @Ulenspiegel for pointing that out. It should be fixed by krzysztof-jusiak/msm-lite@4800b8a. order of entry/exit actions:
Entering ss1
Entering ls1_1
Leaving ls1_1
Entering ls1_2
Leaving ls1_2
Entering ls1_1
Leaving ls1_1
Leaving ss1
Entering ss2
Entering ls2_1
Leaving ls2_1
Entering ls2_2
Leaving ls2_2
Entering ls2_1
Leaving ls2_1
Leaving ss2
Entering ss1
Entering ls1_1
|
Is there a way to assign entry/exit actions to composite states? Maybe I'm not looking hard enough, but the following code can't be compiled:
Is it implemented? As I understand it, transition between composite states should start with exit action of current leaf state, traverse upwards to enclosing state of transition while successively calling exit actions of composite states as they're being left, and then, similar way, successive call entry actions of state hierarchy it enters down to the final destination leaf/leaves. (In addition, I think leaf state's
on_entry
/on_exit
aren't called when transitioning to/from composite state, but that's separate concern.)P.S.: I'd gladly assign the label 'question' to the issue, but it appears I can't assign labels.
The text was updated successfully, but these errors were encountered: