CODEWITHSUNDEEP
umlstate-machinesysmlmagic-draw
bodgesoc
bodgesoc

Reputation: 321

State transitions if condition is true on entry or becomes true later

I am developing a state machine model in MagicDraw. Very nearly all of my state transitions are doubled up, as this is how I was told to do it during the handover period.

ie, between two states I will have both [MyInteger >= 50] and when(MyInteger >=50)

The first operates if the condition is true on entry into the state, and the second if the condition becomes true while the state is already active.

This seems to be necessary because "when" only triggers on a false to true transition, and plain guards only appear to be evaluated on entry into the state.

Is there any way to combine these into a single arrow in the diagram? What I have works, but looks untidy.

I am talking specifically about the Cameo Simulation Toolkit in MagicDraw.

Upvotes: 3

Views: 434

Answers (2)

www.admiraalit.nl
www.admiraalit.nl

Reputation: 6089

I do not have any experience with this simulation toolkit, but I can tell you about how to interpret UML in general.

Summary: You may write the condition for a transition without brackets and without when. If that condition contains a variable x, you may assume that it is re-evaluated when the value of x changes and if the condition becomes true, the transition will be executed. One exception is described below.

I have seen many UML state machine diagrams, but I have never seen one with a transition in the form of when(...).

Example:

state machine diagram with two states

The initial state is State1. The condition x > 50 is immediately evaluated. If x > 50, the transition to State2 is executed. If not, the state machine remains 'waiting' in state State1. When the value of x changes after some time, such that the condition becomes true, then the transition to State2 is executed.

In general, a state machine diagram is just one piece of the greater design of an application. Another piece of the design may define how and when variable x is changed. For example, it may define use cases, where a user or an external system updates x. Normal practice is that you assume that the state machine somehow knows that it shall re-evaluate its transition conditions when one of the variables in these conditions changes and the state machine is 'waiting'.

It becomes tricky when the state machine itself is responsible for updating x, for example:

state machine with entry activity

In this case, the initial state is again State1, but it first executes its entry behavior, incrementing x until it is 81, and then evaluates the transition condition. In this case, the transition is executed not when x becomes 50, but when it becomes 81. The reason is that the state machine is not 'waiting' while it executes its entry behavior.

Upvotes: 0

Axel Scheithauer
Axel Scheithauer

Reputation: 3680

This is not completely correct. The first is called a completion transition. It fires, when the originating state completes its behavior. Behavior means here the substates and the entry and do behaviors. So, it is correct, when you want to leave the state on the completion event and on the change event you need two transitions. I for myself have not encountered such situations.

Maybe a state machine is not the right solution for your problem. I don't know what you are trying to achieve.

It is possible to have multiple triggers for one transition. However, not in combination with a completion transition, since UML recognizes such transitions by the absence of a trigger. It is possible to join the two transitions with a junction point and define the effect on the one outgoing transition segment. This way, you at least don't need to repeat it on both transitions.

Upvotes: 2

Related Questions