File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes State machine quick question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "State machine quick question" Watch "State machine quick question" New topic

State machine quick question

Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154

Following on from an earlier post I'm trying to design a state machine and wondered if anyone with more experience of these could give me their opinion on this situation.

I'm using a table driven approach where I have rows holding the following

Current State, Event, Condition, Transition, Next State

Where each one of these is a Class

Current State = where you are now.
Event = What happened, plus potential input data
Condition = What must be satisfied for transition to occur.
Transition = Stuff that will happen on the transition
Next state = What the next �current� state is.

I have a situation where I may need to display a list of "Diagnostic" candidates.

a)If Diagnostic candidates are available display the diagnostic candidate screen.

b)If Diagnostic candidates aren�t available go to another screen

Effectively the next state is dependent on a non-trivial excercise.

I could use

Event 1 Condition1= Are diagnostic candidates, Do Stuff, Diagnostic state
Event 1 Condition2= Aren�t diagnostic candidates, Do Stuff, Another state

To determine if there are diagnostic candidates is a fairly time consuming process, this set up will cause the Condition1 and 2 to execute the same code.

Would it be better to have an Event like this

Event1, null, Check if candidates and issue appropriate event, null.

EventWithCandidates,null,do stuff, Diagnostic screen state

EventWithoutCandidates,null, do stuff, Another screen state.

The one thing that worries me about this is that the top entry has no "next state", and I would have to accommodate for this in the state machine code, also the Transition object would be issuing an Event, rather than the client.

Another way would be for Condition1 to set up the candidate list somewhere and Condition2 be coded to look for this, but this introduces a sequential dependency between conditions.

Or I could condition the Transition and State logic on the condition output but that seems naff.

How is this usually done, is there a better way?

TIA Graham

[ November 07, 2005: Message edited by: Graham VMead ]
[ November 07, 2005: Message edited by: Graham VMead ]
Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154
Just had a thought, should really get the candidate list in the Event, that would do it.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I think I've always managed to get the conditions you mention into the current state or into the event. With or without diagnostics could be the current state ...

I don't know if that makes sense in your world. This can lead you into having many states in excruciating detail. See if the following links (from a school project that generates database data) make sense. The diagram is an RTN format description of a subset of DDL syntax. The spreadsheet matches this and drives the program. When an event occurs (a parser token is found) it sends the "message" to the processing engine which invokes a command and goes to the next state.

Visio Diagram
[ November 07, 2005: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154
Hi Stan,

Thanks for the reply. My main problem is that with

Current State Event Condition Action Next state

CurrentState Event1 Condition1= Candidates exist,Stuff, Diagnostic state
CurrentState Event1 Condition2= Candidates dont exist,Stuff, Another state

Say I have a situation where no candidates exist,

If I put the candidate check in the conditions, the logic to get candidates will be issued twice once in Condition1 and again in Condition2.
This could end up introducing a performance hit.

Many states could potentially move to the Diagnostic state, so I would have to introduce the candidate check into all of these.

This was why I was thinking of putting it in the PotentialDiagnosticEvent

I suppose its as broad as its long, any Event that may lead to the Diagnostic state would need this check.
Frank Carver

Joined: Jan 07, 1999
Posts: 6920
Most non-trivial state-based systems encounter problems like this. From your description it seems that all your "states" are probably associated with something visible (such as a user input screen). I have usually handled this using the introduction of "invisible" or "navigation" states.

The job of an invisible state is to perform complex processing that doesn't belong to any particular visible state, but that helps the system decide which visible state to show next.

For example:

So from the users' piont of view it steps directly from one screen to another, but from the point of view of there is another intermediate state whose job is solely to decide which visible state follows.

The step of moving the "next state" calculation out of the state itself into an external state specification is a vital one, but the step of separating processing from the visible states into invisible states is just as important for a rpobust application.

Has that helped, or did I miss your point?

Read about me at ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154
Hi Frank,

Yes that is what I'm looking for,

Using your example

SCREEN A "next button" INVIS 1
INVIS 1 "has diagnostics" SCREEN B
INVIS 1 "no diagnostics" SCREEN C
SCREEN X "continue" SCREEN Y

In your example am I right in assuming the INVIS 1 state is responsible for the processing to find if there are candidates?

The application is based around screen navigation (with a few other bits and bobs).

One last question, using your example a normal transtion could be

Assume current state is SCREEN X

Event myEvent = new Event("continue");
State nextState =;

Using the invis way

Assume current state is SCREEN A

Event myEvent = new Event("next button");
State nextState =;

what mechanism do you use so that internally the stateMachine knows this is a 2 stage process


get the continue Event,

resolve it to the invis1 state,

find the candidates, (does the Invis 1 state object do this?)

Issue "nocandidates"/"candidates" event (Does invis 1 state issue next on statemachine or is statemachine coded to recognise this as intermediate state?)


Frank Carver

Joined: Jan 07, 1999
Posts: 6920
what mechanism do you use so that internally the stateMachine knows this is a 2 stage process?

It shouldn't care. Every transition is still just a single step. The invisible state simply raises one of its exit events when it has made its decision just like the screens do when a user presses a button or whatever.

I have written systems which have many more "invisible" states than visible ones. Sometimes there might be a chain of several invisible states before another visible state appears which requires a decision from a user.
Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154

sorry to be dense

The example I'm looking at goes to the next state by issuing a next method on the statemachine passing in an Event

Are you saying that in this case the invis1 state would

a) Find whether there are candidates
b) Issue next() method on state machine passing in appropriate Event type
Frank Carver

Joined: Jan 07, 1999
Posts: 6920

When the code in the invisible state (which works out if there are any diagnostic candidates) gets an answer, then the state should change. So it gives the state machine some sort of "I have diagnostic candidates" or "I do not have diagnostic candidates" event. The state machine uses this event to decide which state object (visible or invisible) to call next.

It might help to think of visible states showing something them waiting for user input, while invisible states set up some processing and wait for a result. Then end result of both is the same - an event of some sort is passed to the state machine so it can work out what to do next.
Graham VMead
Ranch Hand

Joined: Sep 22, 2003
Posts: 154

Thanks a lot for your help. If its not a real pain, have you got any tips on the following,

Say I've got a screen (HTML) with 3 tabs e.g Summary, Diagnostics, Log.

Each tab has the concept of internal states, so Diagnostics has sub states e.g "Show diagnostic candidates" "process candidate" etc. The user has the ability to jump from say "Show Diagnostic candidates" in the "Diagnostic" pane to "Summary". On returning to the "Diagnostic" pane the system must remember the "Diagnostic" sub state and show the appropiate screen.

From trawling the net this seems to be "Orthogonal" states, but I have yet to find an implementation example.

Would this be implemented with a top level State machine class holding a list of Child "State machines".

The Top level state machine would know which current state it was in "Summary" "Diagnostic" "Log" etc.

When the top level SM received an Event how would it know which Child SM to route to. I've seen an example where it routes the event to all child SM's in turn?!

How would it distinguish between an event that changed the top level current state e.g going from diagnostics to summary, and one that was a change in a childs state, e.g diagnostic screen 1 to screen 2.

May be I'm on the wrong track.

TIA Graham
Frank Carver

Joined: Jan 07, 1999
Posts: 6920
If I read you right this sounds like another common state machine problem. Am I right in rephrasing it as:

You want to bne able to use the same state behaviour, but with a different set of destination states depending on what you have done in the program.

If that's the case, i'd personally steer clear of "sub state machines" or "internal states" and try very hard to keep it all at one level.

Remember that when you have "invisible states" there is nothing tying you to the idea that one screen always equals one state. It's perfectly reasonable to also have state transitions that take place while one screen is on display. One visible screen could easily correspond to two or more states ("diagnostoc with candidates", "diagnostic with summary", etc.)
I agree. Here's the link:
subject: State machine quick question
It's not a secret anymore!