Le 17/02/2016 16:20, Kris a écrit :
On Tue, Feb 16, 2016 at 9:50 PM, Vicente Botet [via Boost] < ml-node+s2283326n4683550h69@n4.nabble.com> wrote:
Le 16/02/2016 17:44, Krzysztof Jusiak a écrit :
I would assume following order according to the spec + a bit of rationality?
1. guard [to enable transition] 2. exit src state 3. actions... 4. CHANGE THE STATE TO DST HERE? 5. entry dst state
I agree. It was evident to me, but I can not point to any wording.
Great to hear that. However, above sequence makes exception handling a bit harder as with guards we haven't left the src state but with actions we started the exit already.
1. When exception happens in a guard * src state is unchanged
2. When exception happens in an action * src state is exited
Moreover, following below sequence
3. actions... 4. CHANGE THE STATE TO DST HERE?
makes it harder to process internal events
"src"_s + event / process_event(other_event) = "dst"_s , "src"_s + other_event = X // most likely, should be this one as we haven't changed the state yet? , "dst"_s + other_event = X
and, therefore, maybe it's better to have it the other way around?
3. CHANGE THE STATE TO DST HERE? 4. actions...
I have never used process_event in an action on the same state machine (You are re-entering the state machine :( ). The single think you can do is to post it (push in a queue) or call process_event in another state machine. However you must ensure the there are no cycles. The asynchronous way avoids always the possible cycles. In some projects I have defined a hierarchy of state machines and the upper layer state machines use synchronous communication to communicate to lower state machines and the reverse, lower layer use always asynchronous communication with upper layer state machines (half sync/half async). There are 3 features that I'm missing in UML state machines that I found in SDL [1]. Maybe these features have no sense with synchronous state machines. * Procedures that can contain states. The difference with nested states is that procedures are stack based and return to the point of call when the procedure terminates. You can reuse a procedure inside a state machine several times of course. * Synchronous Remote Procedures that allows to do a call/replay at once. This avoids the use of wait states on which the every other event tan the replay is deferred. * Synchronous Remote Variables that allows to read a remote variable.The same here; but just to query for the value of a remote variable. Vicente [1] https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwi1vqWwqP_KAhUGWhoKHa-DB3oQFghEMAQ&url=http%3A%2F%2Fwww.itu.int%2FITU-T%2Fstudygroups%2Fcom10%2Flanguages%2FZ.100_1199.pdf&usg=AFQjCNFwOMg8j5RuW77nxtjPuj3c8eq2mQ&sig2=svSxdC5kgb1EBGDbnchYwg [2] https://fr.wikipedia.org/wiki/Specification_and_Description_Language