Software Complexity

“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.”

F. Brooks wrote that in his classic article “No Silver Bullet ↗”.

We may not have found the silver bullet for solving complex problems, but our concept brings software development closer to the productivity and reliability of computer hardware.

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 reliable and predictable software, reduce maintenance, simplify reuse of your software in new projects, etc.

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:
Specify it → 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”.

Separation of behavior and data handling

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!

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.

Learn and Explore StateWORKS

To learn about StateWORKS features in detail, you can study our book or explore the website. The development system can be downloaded for free and used to study all the provided examples.

Since programming a single finite state machine is very easy, using hand-coding or tools from various vendors, we encourage trying such simple designs with our software to illustrate how our concepts are applied.

The full power of the StateWORKS approach is only apparent in large-scale real-life projects, typically employing 10 to 100 finite state machines within a system.

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 many decades, and has a shallow “learning curve”!