StateWORKS: Frequently Asked Questions

  1. Where do you produce code?
  2. What if we do not have a precise, written specification?
  3. What are the most appropriate sorts of projects for StateWORKS?
  4. How is StateWORKS Software Tested?
  5. StateWORKS needs to be learnt, so would one really save on time?
  6. There must be some problems, surely?
  7. Have you found a "silver bullet" solving all software problems?
  8. You seem to be able to do just about anything with StateWORKS! Can it be true?


Q1. Where do you produce code?

A. StateWORKS does not produce code for state machines in the common sense of this word, as there is no need for it. StateWORKS generates specification 'code' as data files which can be directly (and very efficiently) processed by the executor without any additional 'manual' handling.

A project is built by means of the StateWORKS Library (RTDB Class Library) in any of several possible C++ development systems. In this way the software for the rest of the system: input/output handlers, user interfaces, communications links etc. is added to the project.

The specification for systems of state machines of any degree of complexity is introduced into the run-time system as a C++ file. This specification, as designed and tested in the StateWORKS Studio development environment, is always complete, i.e. it is a part of the final executable application. During system testing and validation, if the effects of changes in the state machines need to be tried efficiently, an alternative approach is to reload the specification file from disc on each restart: this avoids repeating the build process for each small change, such as a revised timer setting.

Q2. What if we do not have a precise, written specification?

A. This is a common situation in real life. One of the really powerful and useful features of the StateWORKS development process is that the system designer is forced to make a totally complete specification: there is no coding process where details can be fixed later. In fact the designer will not first make a complete specification and then apply StateWORKS: he will use the StateWORKS I.D.E. as an interactive tool, whereby all the areas of missing information are shown up, and must be fixed, usually in close interaction with the customer. Some projects, done in this way, were claimed to have been impossible to complete without using this powerful tool!

Q3. What are the most appropriate sorts of projects for StateWORKS?

A. A very wide variety. Industrial processes are a prime category, particularly when a series of complex operations must be applied to a number of batches, as in semiconductor production. Embedded systems in instruments and measuring equipment are another examples.

Another area of application is in communications, networks and telephony, where the numerous and often complex protocols are usually specified in terms of finite state machines.

Software for safety-critical systems such as in transportation could advantageously use StateWORKS. There are a number of methods of checking the validity of formal specifications, as expressed as Petri nets, state machines or otherwise, and such specifications can be easily coded into the StateWORKS format.

Unlike some software tools which have been well publicised, StateWORKS is very well suited to the largest and most complex systems. One of the first, and highly successful, projects using this technology was implemented on ten D.E.C. VAXeln computers, networked, as a system of 400 finite state machines as early as 1990. StateWORKS in its present form can be used to automate complete production lines of any size.

Q4. How is StateWORKS Software Tested?

A. The StateWORKS Studio development environment provides a simple tool "SWLab" which will exercise the specification. With this, one uses a Monitor such as "SWMon" to observe items of interest, and to stimulate the system with artificial inputs. A second monitor "SWQuickPro" is available, which is able to record test sequences, and save them for re-use later, to be run automatically. It can also process lists of such recorded tests, and this is useful when making changes to a project, to confirm the absence of unwanted side effects.

Q5. StateWORKS needs to be learnt, so would one really save on time?

A. Yes, there is a new process to learn. Many of its basic elements ought to mastered, in any case, by a software designer. A couple of weeks study would be enough to understand StateWORKS well enough to apply it.

Then, productivity rises by at least 30%, and in some cases by a factor of up to 3, depending on the project and the quantity of conventional coding needed for the various algorithmic functions which are not governing the program structure.

After that, you will see the benefits of a real engineering approach when the new system is first installed and tested on the target embedded-system hardware. The usual bug-hunting phase is very drastically reduced. And, of course, as the program structure is accurately documented in the state diagrams etc. rather than in C++ coding, "maintenance" as it is called, is almost eliminated, and various changes can be implemented, to meet new requirements, in a straight-forward way.

After doing a couple of projects, you will discover that a software project can be planned and managed in a similar way to other engineering projects. It still takes a lot of work to implement it, but need not depend on one or two "gurus" who can churn out good code at high speed. Furthermore, the end user can be brought into the process, and can be consulted about the finer details. Using SASD (Structured Analysis, Structured Design), for example, the end user and managers tend to be presented with a very simple top-level model, but all the details are hidden from them, until the beta-test stage.

Q6. There must be some problems, surely?

A. Yes, but they are not technical, bur rather cultural. Programmers actually enjoy the intellectual effort of trying to understand the problems of a very complex program, making patches and gradually eliminating the more obvious bugs. They will dislike having to "fill out forms" instead. Today's software industry places far too much emphasis on coding as a valuable and skilled activity, and insufficient emphasis on analysis of system requirements, followed by synthesis of a suitable model in an abstract (i.e. not coded and not even assuming a coding method) form, which is then validated and simulated.

This erroneous approach is propagated by much information-technology education, where a real education in basic concepts is replaced by a form of training in the more fashionable tools of the day. Convincing potential users can, of course be hard. They will have been exposed to so many wonderful new tools, that have never fulfilled their early promise that they will not want to look into StateWORKS. They will imagine that their own project will not be a suitable one, or that StateWORKS could only be introduced in completely new projects, rather than to develop parts of existing systems. They will claim that StateWORKS is nothing new: we already have SDL, or UML for example. All these claims have been proven false, for example at the Lucent (Bell Labs.) development centre of the 5ESS telephony switching systems, where an early version, called VFSM, was introduced some years ago.

Q7. Have you found a "silver bullet" solving all software problems?

A. Not at all. We cannot simplify difficult problems. If the control problem is complex the corresponding state machines or a system of state machines will be complex. But the StateWORKS solution will be better than any coded version: you will do it with less effort, it will be better documented and you achieve your goal without exceeding the planned timetable and financial resources.

Q8. You seem to be able to do just about anything with StateWORKS! Can it be true ?

A. Just try it out, on a small project or a big one, and you will be pleasantly surprised.


[CHA1] M. R. Chapman, "In Search of Stupidity: Over 20 years of high-tech marketing disasters", Apress 2003, ISBN 1-59059-104-6