1

I am new to state machine modeling and while trying to model a system, I have a question.

An example will explain it better:

Considering a system that does calling (probably a customized cell phone device) with possible states:

idle->calling->signal-dropping->handle->call ended

idle->calling->OS problem->handle->call ended

idle->calling->battery drained->handle->call ended

idle->calling->some other problem->handle->call ended

Above example is in form state1->transition1->state2->transition2->state3

Question is: Is there any significance of these intermediate states? Should they be shown/ modeled explicitly in UML or even programming?

Note: It would be helpful if anyone can mention (some existing if applicable) technical term used to describe this scenario

3
  • You might find it useful to model "calling" as a state, and then the four problems as triggers. If "handle" requires a definite amount of time (either in code execution or in user interaction), then "handle" might also be made into a state.
    – rwong
    Jun 16, 2014 at 10:46
  • @rwong Can You elaborate it with the example?
    – Devesh
    Jun 16, 2014 at 10:58
  • 1
    Actually, I originally only meant to say this general advice: think hard for yourself whether something should be a "state" or a "transition". The decision depends on how you intend to use the state machine (in software or hardware), so it's not possible for an outside like me to give a definite answer. In general, a state is something that last for a certain period of time, is visible to other parts of the system, and will remain in that state in the absence of any new input events (triggers).
    – rwong
    Jun 16, 2014 at 11:06

1 Answer 1

2

As usual, there is no definite answer for how you must model something. Everything that is valid according to whatever modeling language you apply is available and can potentially be used that way.

That being said, intermediate states are nothing out of the ordinary. I even have to correct the comment made by @rwong, that a state remains unchanged in the absence of input events. This is definitely not the case. In particular, the UML standard defines something called a completion transition (UML SSS 15.3.14), for which the semantics is defined such that you can immediately transition to the next state, after the source state has finished its entry and do activities.

So yes, intermediate states can be modeled, and yes, a lot of state machines exist, which do model intermediate states. Whether it makes sense in your scenario or not, however, cannot be easily answered.

In order to answer your questions: Yes, these states can be very significant, but that's mostly due to the behavior your model assigns to them. Whether they should be explicitly modeled has to be decided on a per state basis. If it is insignificant, and you really just have a transition, then it may be better not to model it explicitly. It's also a judgement call each time, whether you assign an action to the transition or use an intermediate state with a completion transition. A rule of thumb here is that it's justified to use an explicit state, as soon as you have a reasonably complex behavior attached to it. If you just increase a counter variable, however, a transition action is easily sufficient to model that. As for the technical term, I think the UML concept of completion transition seems to be the best fit for what you described.

As a side-note: in your examples, you have different intermediate states reachable after the idle state, and in this case, modeling the intermediate states explicitly immediately shows up a problem: how do you distinguish which transition to use? calling is not your only trigger really, because that would mean your idle state has at least four transitions that trigger based only on calling, whereas you should have mutually exclusive trigger conditions (including guards) for the transitions. If you don't, your state machine becomes non-deterministic, which is something you probably won't want.

I also suggest that you read up on state machines in the UML SSS to get a grip on other typical terms related to state machines. Judging from their absence in your post, I guess you could profit from thinking about the differences between states, transitions, triggers, guards, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.