Composite state with concurrent regions

[frankk]

In a composite state with concurrent sub-states (i.e., regions), when does the composite state as a whole complete? When all of the regions complete, or when any one of them does?

[jeshaw2]

To paraphrase Harel's specification of State Charts, the basis of the UML State Chart,  if an object is in one of its concurrent states, it must be in all of its concurrent states.  Therefore, I'd say when all the regions complete.

[«Midnight»]

Jim's reference is accurate, but the inference is not quite correct.

Actually, when you reach the incoming edge of the composite sub-states, all concurrent states start, for the reason Jim cites.

For the same reason, when any concurrent sub-state reaches the outgoing edge (or its end state if that is shown) then all the concurrent sub-states exit. Of course any exit actions - for all the concurrent sub-states - are performed.

To repeat, this is in keeping with Harel's notes, as sort of a corollary. Since we must be in all concurrent states at the same time, exiting any of them causes us to leave them all. Otherwise we cannot 'escape' to the next state.

If you need to model a situation where all states must complete to effect a transition, you can use a synchronization bar. It's buried in the specification somewhere.

David

[frankk]

Thank you :-)

[jeshaw2]

[SNIP]

For the same reason, when any concurrent sub-state reaches the outgoing edge (or its end state if that is shown) then all the concurrent sub-states exit. Of course any exit actions - for all the concurrent sub-states - are performed.
[SNIP]
David

David;  What do you make of this statement?

UML 2.2.1, Sect 15.3.11 Composite State

A transition to a final state represents the completion of behavior in the enclosing region. Completion of behavior in all orthogonal regions represents completion of behavior by the enclosing state and triggers a completion event on the enclosing state. Completion of the topmost regions of an object corresponds to its termination.

I would think that the event of one region's completion forcing the completion of other regions would cause the other regions to terminate abnormally or unexpectedly in the middle of their process.

Jim

[«Midnight»]

Good question Jim,

AFAIK my read on this is pretty much mainstream.

I take "orthogonal" to refer to unrelated, or non-concurrent, states. That is, if you complete all of the non-concurrent states the region will end.

In general, when a state ends it should either roll back or complete its work, as specified. Such specification may (optionally) provide for interruption or error signals. You should not have an 'abrupt' [for lack of a better word coming to mind] termination, in the sense that there is always a way out, even if it is a set of defaults. [For example, if you have provided an exit action this would be executed, if you provided for rollback on interruption, this would occur.]

The top-level phrase refers to those states that are enclosed by the entire element, not an 'inner' region. When you exit this 'compartment' you are exiting the element. The same 'rules' apply.

Now if we go back to your earlier note on concurrent states, the process is slightly different. These states are not orthogonal, they are directly related, simply by virtue of being concurrent. As you noted, you must be 'in' all concurrent states at once. My commentary pointed out that this means that if you exit any of these states you exit the set; it is an all or nothing proposition.

So the main difference here is that in the orthogonal case all the streams must compete to cause exit from the region, in the concurrent case completion of any state causes exit.

You can mix and match these cases, with a fair degree of versatility. There are some difficult situation though. Consider cases where (completion of) any of several subsets should case a state change, but not every subset would qualify. Or where several sets of streams should cause an exit if they all complete, but the individual streams of these sets - even in combination with other streams - are not alone sufficient, and the entire set of streams should not always be required. These can require some fancy footwork. There are ways to handle these cases well, though there are trade-offs that need to be considered (like some many other good thing). This whole subject lies outside our current scope though.

David

[KP]

So, a couple of examples to illustrate the difference between concurrent and orthogonal sub-states:

1. I am in two states from different sub-state machines: a) I'm waiting on delivery of a horse blanket I won on eBay, and b) I'm waiting for VS to finish a build. These two states are orthogonal because they are independent of each other and one finishing has no effect on the other.

2. I am in two states from different sub-state machines: a) I'm browsing the Sparx forum, and b) I'm waiting for VS to finish a build. These two states are concurrent, because as soon as the "build" state machine exits, I am forced to exit the "forum" state machine (and get on with some real work!)

Have I understood correctly?

[sargasso]

3) I am in no state to even state what state I would have to be in, to be in more than one state at a time. Ergo, I will remain in the state of Minnesota.. no that's too specific. Maybe that's too confusing, I'll just rest intestate.

the ghost of bruce (heheheheheheh)

[«Midnight»]

So if you're going to be buried outside of Minnesota, will that involve taking the intestate interstate?

[Paolo F Cantoni]

So if you're going to be buried outside of Minnesota, will that involve taking the intestate interstate?

Yes, but if you're pronouncing in American, you might have been saying the "innerstate innerstate" so we wouldn't understand you anyway...

But it WAS good!

Paolo

[«Midnight»]

I'm from the Frozen North, so I can never understand when someone's talkin' merkin anyway, so no loss.

As long as they're roaming around in those large vehicles, looking for places to be buried, it all makes sense. It's the rest of the time that I cannot fathom.