- - - - - - -
- - - - - - - - - - - -
Other material for programmers
Introduction to using state diagrams
A replacement for flowcharts?
This is intended to give you a quick introduction to state driven, or event driven, programming. You may say "I can write what you've proposed, but without all the "complications" in your solution." If you do, you're missing the point. Your simple answer to the simple problem will probably be fine... but will the techniques you've used scale to more complex situations?
Long ago, programs ran like trains on rails. You started at A, went to B, then C, D, E, etc...
Yes... branches and loops were permitted. Inside the machine, there were even some interrupt driven things going on. And then we moved forward into the brave new world of event driven, multi-tasking operating systems, like Windows and Linux...
This moving forward brought with it difficulties for people who were using flowcharts for keeping track of what programs were doing... a pity. But it does make it easier to write more user-friendly applications.
I will illustrate some of the ideas behind state, or event driven programming with a simple burglar alarm system.
Hardware: Assume that you are working with a computer connected to a toggle switch, a bell, and an intruder detector. The toggle switch is for setting the alarm system to "armed" or "safe", i.e. "ignore inputs from intruder detector".
Software: Assume that your software offers the following...
- BellOn: Procedure to start bell ringing.
- BellOff: Procedure to turn bell off.
- boIntruder: A function that returns true or false, depending on whether the intruder detector "sees" an intruder or not.
- boArmed: A function that returns true if the toggle switch is set to the "armed" setting, false if it is set to the "safe" position.
(You will, of course, probably provide those facilities with sub-routines written by yourself for your target hardware.)
The first step for the designer of this application would be to generate the following diagram of the states which might exist, and the potential inter-state transition paths....
Each blue box represents a state that the system may be in at one time or another. For each state, you should have a clear idea of what the user is going to be seeing on the screen, and what the condition (state) will be of the bell, the switch, etc. You also need to know if the program is doing anything while it is in each state. For example, when in the "Waiting" state, the program will be checking boIntruder. (That is, in the simple implementation of this system the program will be checking boIntruder. Later in this essay, you will make further discoveries!)
The arrows show permitted state transitions. Note that you don't need to be able to get to any state from any state.
Programming the system can be broken down into procedures with names like....
You'll need a global variable, which I'll call CurrentState.
- .... etc.
Every so often, you'll need to make a number of tests. There are different ways to accomplish the "every so often". In Delphi, the timer component's event is a good way to do this.
Those tests will be things like....
if (CurrentState=stateWaiting) and
(boArmed) then ChangeStateFrmWaitingToWatching
Within ChangeStateFrmWaitingToWatching, you would have things like CurrentState:=stateWatching and something to put a message on the screen announcing that the alarm system is armed.
So far, so simple.... things are being done in a pretty uncomplicated, unclever way. Enter the exciting world of "events". (Yes, I know, we used one earlier, if you look closely. I was hoping you wouldn't notice. We used it crudely, anyway.)
Events can arise from all sorts of sources. Many are built in, and you can add others. The weird, wonderful thing about events is that they can be given "handlers", little bits of code that executes when the event occurs. Anything else that was going on at the time is suspended for a moment. (Which is why you really, really don't want something like "repeat... until 4=5" anywhere in your event handler. You wouldn't write what I've given as the example... but it is easy to write an equivalent!)
Not only do Windows and Linux systems come with built in events, with built in event handlers, but you can modify those event handlers (quite easy) or create potential new events (not so easy- and beyond the scope of this essay.)
Whenever you move the mouse, an event "is triggered" (i.e., everything else is momentarily interrupted, and Things Happen... the "things" provided for in the MouseMoved event handler.)
If you'll forgive a slightly strained example, I can show you something quite easily. Let's pretend that instead of hooking up a PIR to your system, and making a boIntruder function to tell you what the PIR "sees", you go a cruder route: When you are away from home, you somehow Rube Goldberg together some device that arrange for any intruder to accidentally move the computer's mouse. If you'll allow me that strange scenario, the boIntruder function can be dispensed with. Furthermore, (and this is where things become cool), the state change shown by the arrow on the state diagram called "Begin Ringing" will be effected just by adding the following to the system's MouseMoved event handler!....
if CurrentState=stateWatching then ChangeStateFromWatchingToRinging
I'm sorry if you don't feel a Eureka moment as you read that. It really is quite cool, but it sometimes takes a while to absorb the ideas and implications. For now: Do try to get the idea of state diagram based programming into your head....
Good Things will come of it!
In this essay, we have been looking at a system with external elements, because I think it helps you grasp the ideas of different states, the transition triggers, etc, more easily. But even something like a standard word-processor has "states", e.g. the print preview state, the Save-File-Dialog-Is-Open state, etc, etc.
Once you start thinking of your applications as being "machines" with different states, and rules about what each state consists of, and when and how you change states, I think you'll find it begins to be easier to stay on top of the development process.
I hope that leaves you feeling that state diagrams are a tool that might be useful?
This search merely looks for the words you enter. It won't answer "Where can I download InpOut32?"
Click here if you're feeling kind! (Promotes my site via "Top100Borland")
Ad from page's editor: Yes.. I do enjoy compiling these things for you. I hope they are helpful. However... this doesn't pay my bills!!! Sheepdog Software (tm) is supposed to help do that, so if you found this stuff useful, (and you run a Windows or MS-DOS PC) please visit my freeware and shareware page, download something, and circulate it for me? Links on your page to this page would also be appreciated!
Click here to visit editor's freeware, shareware page.
Link to Tutorials main page
How to email or write this page's editor, Tom Boyd
Page WILL BE tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
If this page causes a script to run, why? Because of things like Google panels, and the code for the search button. Why do I mention scripts? Be sure you know all you need to about spyware.
....... P a g e . . . E n d s .....