The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

state machine type software specification

I've been thinking about software for at a clinic.  This software may be used by doctors, nurses, non-medical staff.  The important thing is that I am thinking in terms of some sort of state machine. 

A new patients comes in
An existing patient just finished her checkup
A patient forgot to bring his wallet
A staff person forgot to record an event in the software
etc., etc.

I get the feeling that modeling this clinic (for the purpose of software design) as a state machine will clearly show the use cases that have been thought about..and the ones which have been missed.

Now this method of requirement gathering or design specification may be common knowledge, but I am just starting to look into this (I've been a programmer in the securities industry for a few years...but never saw this).  Are there any good books that talk about design of software using this method?

A clinic office management software may be used by a large variety of clinics...I'm just curious how other people model business processes...a single person can't visit more than one or two clinics to do 'market research." 

(by the way, I used clinics just as an example, it could also be restaurants, karate schools, gyms, anything really).

Hope my question makes sense.  Thanks.
Falcon Send private email
Thursday, September 22, 2005
I see some problems with this approach.
If I understand your idea correctly, you want to model patients (possibly staff) as being in a given state (for the purpose of the system) and for each state map out all likely events which may change the state and all the operations you may apply to a person in a given state.


If this is right, expect a combinatorial explosion of substates. E.g.: the man with the status "broken leg", when you discover he actually forgot his wallet, will need to go to "broken leg + no-ID", possibly followed by "broken leg + no-ID + Allergy to XXX (stated)" which is slightly different from by "broken leg + no-ID + Allergy to XXX (confirmed)".

Now try to imagine building state-transition tables or graphs for stuff with hundreds of possible states.

You may check this: for some pointers to a proposed solution to alleviate this problem, but even if this helps, I doubt you can really map a complex reality with this approach.
Paolo Marino Send private email
Thursday, September 22, 2005
One more thing:
There was apparently a full design methodology based on state charts, and you can download the book for free here:

Not sure if it was geared to your kind of problem (I doubt it, the application domain for this stuff is generally for embedded devices and similar things), but you can give it a look.
Paolo Marino Send private email
Thursday, September 22, 2005
You do need some sort formalism.

State machines are good because almost everything is a state machine, programmers just don't seem to like them. You can deal with substate explotion to some extent by using hierarchical state machines.

Another approach is to use rules.

Or another approach is to simply the problem so that it can be managed without a lot of complicated means. Maybe to get most of what you need you can drop 80% of the complexity?
son of parnas
Thursday, September 22, 2005
Hospitals and clinics are not good state machine examples because they have transitions in between almost any two internal states. ICUs are in particular difficult to model. Life saving takes precedence over computer data entry 8) and that breaks the chain of events the computer needs to track. Single example out of many, the ICD9 or ICD10 codes are the last thing that are entered into the computers. That usually happens after patient's discharge.

More problems relate to off-line data entry. Data entry is not done by the same people treating patients (ie doctors) because people treating patients (ie doctors) get paid more for treating patients than for entering patients' data.

Clinical systems employ stateless message protocols.
Dino Send private email
Thursday, September 22, 2005
> Clinical systems employ stateless message protocols.

That doesn't mean the applications are not statefull.
son of parnas
Thursday, September 22, 2005
son of parnas,

Applications are stateful, you're right: the state is the an electronic patient record (and a huge liability)
Dino Send private email
Thursday, September 22, 2005
Thanks for the replies.  Basically I'm trying to figure out what's the best way of modeling real-life for the use of software.  Specifically so when a developer (requirements gatherer, analyst...whatever) is somewhat new to the situation.  I have been working in the financial industry for a while now so I have a pretty good mental model of what a system will require.  If I'm asked to build a system for another domain...I need a way of modeling agents, interactions, exceptions, etc., etc.

I figured a state machine was a good starting point (and the clinic was just an example...a restaurant with servers, waiters, customers is another example).
Falcon Send private email
Saturday, September 24, 2005
"I figured a state machine was a good starting point (and the clinic was just an example...a restaurant with servers, waiters, customers is another example)."

It's not a question of restaurant vs. clinics. State machines are a powerful design tool, but they generally don't scale well for "real-life" situation.
They are good to model extremely simplified "worlds", like document workflow in a digital repository, for example (a document is "new", "modified", "locked"...) or embedded devices /consumer electronics (the DVD is missing, the cable is plugged in, the red button is pressed while the powerup is not completed) but they are not good for real life situations... this could be more a problem of the actual human limitations in dealing with hundreds of different states than a problem with state machines (they work well, *if properly designed* and are probably very efficient)... the point is they are cumbersome to manage (and design/debug) when they get large... something they do as soon as you try to model something even moderately complex.
Paolo Marino Send private email
Saturday, September 24, 2005

I am the author of a mindmapping freeware tool ( and now working on a .Net framework for "knowledge modelling applications", the case described by Falcon could be eventually prototyped on top of that framework, feel free to contact me if u are interested by this possibility

michel Kern

Saturday, September 24, 2005
The "statemachine" thinking is not bad, but you might separate your application(s). Different departments in your 'clinic' have different views on a patient.

The management has states like "new patient -> stays in clinic -> is overdue the normal time for this ICD -> left the clinic -> payed the bills -> case is archived".

The nurse has states for the patient like "prepare meds for today -> apply meds -> clean up the bed -> check blood pressure" (not a very good example, this is more a todo list)

The kitchen facility has states like "normal meals - vegetarian - basic diet"

All these states are statemachines for one facility and an application in your whole app should watch these specific states, not all together.

What do you think?
Saturday, September 24, 2005
From what you've described, I think you want a "Workflow engine".  This allows you to define a state machine like set of states and triggers, for both human and computer tasks, without embedding the logic in your software (In fact, there's a whole syntax for drawing workflows, just like there are state machine diagrams for state engines).

Start with:
Steve Moyer Send private email
Monday, September 26, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz