Silver Bullet

The Silver Bullet at last?

“Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any — no inventions that will do for software productivity, reliability and simplicity what electronics, transistors and large-scale integration did for computer hardware.”
— Frederick P. Brooks, Jr.

Frederick P. Brooks, Jr. wrote that in his classic article: “No Silver Bullet: Essence and Accidents of Software Engineering” published in the April, 1987 edition of IEEE “Computer”. 20 years later, we can finally see that he was too pessimistic. But it took us a lot of hard work over that time to fully develop the StateWORKS concept!

StateWORKS™
- bringing engineering design discipline to software development.

A real, hype-free, time-tested and mature product which you can use now, to gain huge benefits in developing your products. Design ultra-reliable and predictable software, reduce maintenance, simplify reuse of your software in new projects, etc.

Finally, the answer to the big question - how can high-quality software for large projects (such as embedded or telecommunication applications) be produced reliably and on time? Such software systems are “reactive”.

The software must work well the first time it is installed, unlike desktop applications: it cannot rely on thousands of users finding bugs. The answer is to use just two development steps:

1. specify it
2. run it

This is what StateWORKS does. Using proven and theoretically sound finite state machine concepts, the implementer fully specifies the behavior, in detail but at a high level, without assuming that it will be coded. He creates a model of unlimited complexity for the whole system, but using small state machines; each with a well-defined task; each easily designed and understood. The development system (IDE) provides various features for testing at the design stage. Then the model is simply loaded into the system and run. It may take a few hours of tuning, but nothing like the weeks of “testing” that are common in these areas. And, of course, we believe that software cannot wear out in use, so why should it require a huge “maintenance” effort?

Our basic rule is - never write complex code. Don’t try to automate it, either, but avoid the problem altogether.

StateWORKS provides a method for handling complexity: very complex projects can be made simple to deal with, using our unique tools for handling “Systems of State Machines”.

And the Gun?

Of course, the bullet needs a gun to be effective! So a StateWORKS project will probably need some code somewhere.

StateWORKS enforces a strict separation between data handling and control flow. But the control flow, through the “actions” of the various finite state machines, is responsible for the data handling routines, which have to be written with normal tools such as C++ development systems. The same applies to input/output functions, for which we provide a very comprehensive class library.

The essential point is that very complex projects fail because it is impossible for the designers to handle behavior in all possible situations - not just the “sunny day” scenario represented by common “use cases”, but situations with multiple failures. Large systems can never be fully tested to ensure coverage of all possibilities.

The “skeleton” that StateWORKS provides for a project deals with behavior - where systems can often fail due to unexpected inputs - and also with the monitoring of all data handling routines. These can always be made reliable by careful development and testing, in the classical way. Behavior cannot!

StateWORKS removes risk! Hit the target the first time, every time!

Four essential features of StateWORKS

1. StateWORKS is a method for creating high-quality software through models. Software behavior is expressed as finite state machines: never very complicated individually, but many of them working together to make a system. A strict separation strategy is used between control flow and data handling, with the control flow fully supervising the data flow.
2. The StateWORKS design process is in fact a tool for exploring requirements and expressing them in such fine detail that software can be generated without further human coding. Our multimode editors permit full complexity to be easily managed.
3. StateWORKS can deal effectively with very large and very complex systems by using large numbers of state machines in a well-managed hierarchical structure: 50 or more state machines in a single processor are not uncommon. In this way, complexity is managed, and almost all bugs are eliminated in the design process: not left to a “testing and commissioning” phase or for “maintenance”.
4. StateWORKS has been around for several years, has been applied to a wide variety of projects, and is very reliable.

StateWORKS uniquely brings, to software engineering design, practices as sound as those used to engineer hardware, bridges or airplanes, creating a true “Software Engineering” method for the first time.

How to Obtain StateWORKS

To learn about StateWORKS features in detail, there are two ways: read our book or study our website. A development system with limited power: StateWORKS Studio LE, can be downloaded for free from our website and can be used for one month only. Purchasing the book entitles the user to remove the time limit. This version can be used to study all the examples discussed in the book or on the website, but designing with it is limited to single finite state machines. Since programming a single finite state machine is very easy, using hand-coding or tools from various vendors, the LE version is mainly useful as a teaching tool to show how to apply our concepts.

The huge power of the StateWORKS approach is only apparent for large-scale real-life projects, typically employing 10 to 100 finite state machines in a system. For these, we can provide either the Basic system, which is limited to designs having up to 300 objects, or the Pro version, which has no such limit. We can also arrange training courses and seminars.

Six excellent reasons why not to use UML

1. StateWORKS is used to fully generate applications, and has to include detail which UML can not express. (This is also why we don’t generate XMI files: we do generate XML files of designs and our format is published, and expresses aspects of detail which XMI can not handle.)
2. UML has fundamental limitations which restrict it to top-level overviews of projects:
   it is O.K. for the systems analysts, but not for generating final software: despite claims made by some sponsors.
   In contrast, the StateWORKS design process is one of designing the final product, rather than just describing roughly how it should work. In fact the process brings all the problems to light, rather than leaving them to be resolved later when coding.
3. The finite state machine concept of UML is fundamentally flawed, and drives towards excessive and unmanageable complexity. StateWORKS encourages design with small modules, each simple enough to understand, and linked together hierarchically to make the entire system. The top levels of the hierarchy are clear enough that they can be used to discuss the project with management or customers.
4. UML does not offer solutions for communication between tasks in a multitasking system.
5. UML can be used to specify subsystems, but cannot specify the detailed behavior (i.e., control flow) of entire software systems. Even less can it be used to automate the later stages of detailed software production, such as coding.
6. UML is overly complex, especially in its use of many different but confusing graphical symbols and its multiple ways of expressing the same idea, while StateWORKS is solidly based on simple and elegant finite state machine concepts well-known for over 50 years, and has a shallow “learning curve”!