[msm] eUML guard/action location
Hi Michael,
What do you think about this instead?
CurrentState() + cool_event()[Guard()]/(action()) = DestState()
I think it more closely matches the UML syntax.
It's a good idea and it surely matches the UML syntax better. I think the operator precedence will also work. There are however 2 issues: - the current order "CurrentState() + cool_event() = DestState() [Guard()]/(action())" has been chosen to closely match the "normal" row syntax. Only guard and action have been inverted because of operator precedence. - anonymous events. In this case, you have no event, so your syntax would become: CurrentState() [Guard()]/(action()) = DestState() But now the guard/action are "attached" to the source state, which means 2 grammars to support with the corresponding flow of compiler risks and compile-time increases. The first issue is only my worry that users would be confused (eUML already being quite a change). I'd be interested to hear from others about it. The second issue is not so big that it's not worth a try. I think I'll have a look at it and if it works we can then decide which one we prefer. Regards, Christophe
On Mon, 2009-12-07 at 10:37 +0100, Christophe Henry wrote:
Hi Michael,
What do you think about this instead?
CurrentState() + cool_event()[Guard()]/(action()) = DestState()
I think it more closely matches the UML syntax.
The first issue is only my worry that users would be confused (eUML already being quite a change). I'd be interested to hear from others about it.
I like this suggestion - but really - it is not a huge issue. I assumed that the only reason guard was last in the transition table syntax was because it was optional. I don't personally find it confusing if euml picks a different order.
Christophe Henry wrote:
CurrentState() + cool_event()[Guard()]/(action()) = DestState()
It's a good idea and it surely matches the UML syntax better. I think the operator precedence will also work. There are however 2 issues:
- the current order "CurrentState() + cool_event() = DestState() [Guard()]/(action())" has been chosen to closely match the "normal" row syntax. Only guard and action have been inverted because of operator precedence.
The "normal" and suggested syntax seem consistent, though the guard/action are less visible among transitions with them by not hanging off the right. It also means that viewing the transitions is harder or contains more whitespace. That is, the start/event/next flow is interrupted. I do like the choice of [] for the condition (guard) and () for the behavior (action).
- anonymous events. In this case, you have no event, so your syntax would become:
CurrentState() [Guard()]/(action()) = DestState()
What about this: CurrentState() any[Guard()]/(action()) = DestState() Pick another name for "any" if you like.
But now the guard/action are "attached" to the source state, which means 2 grammars to support with the corresponding flow of compiler risks and compile-time increases.
By requiring a special type for anonymous events when there's a guard/action, you eliminate that problem. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
- anonymous events. In this case, you have no event, so your syntax would become:
CurrentState() [Guard()]/(action()) = DestState()
What about this:
CurrentState() any[Guard()]/(action()) = DestState()
Pick another name for "any" if you like.
Hi Rob - I like this too and nearly made the same suggestion. ROOM triggers are a bit more complicated with a port and signal (the event) associated. Either can be described as '*' or any. Ok... I looked up MSM's anonymous transitions again and now I don't like it (o; Christophe ... as far as I can tell by looking at the docs, the MSM use of anonymous transitions transforms the source state to *almost* be a UML choice pseudo state. What I was describing above was actually a transition that matches any event. But an event must occur to "step" the machine forward. Perhaps some refinement can be made such that anonymous transitions can only be associated with a choice pseudo state (introducing the actual choice concept). I am still looking for a way to do what I described. A transition that takes "any" event. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
participants (4)
-
Christophe Henry -
Darryl Green -
Michael Caisse -
Stewart, Robert