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 that you can use now to gain significant 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. They create 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. Do not try to automate it either—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. However, the control flow, through the “actions” of the various finite state machines, is responsible for invoking the data-handling routines, which must be written with standard 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 designers to handle behavior in all possible situations—not just the “sunny day” scenario represented by common “use cases”, but also situations involving 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 through 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 form 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 allow full complexity to be managed easily.
3. StateWORKS can deal effectively with very large and 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 controlled, and almost all bugs are eliminated during 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 highly 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 becomes 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 must include detail that UML cannot express. (This is also why we do not generate XMI files: we do generate XML files of designs, and our format is published and expresses aspects of detail that XMI cannot handle.)
2. UML has fundamental limitations that restrict it to top-level overviews of projects:
   it is OK for systems analysts, but not for generating final software, despite claims made by some sponsors.
   In contrast, the StateWORKS design process focuses on designing the final product, rather than just describing roughly how it should work. In fact, the process brings all problems to light instead of leaving them to be resolved later during coding.
3. The finite state machine concept in UML is fundamentally flawed and leads to excessive and unmanageable complexity. StateWORKS encourages design with small modules, each simple enough to understand, and linked together hierarchically to form the entire system. The top levels of the hierarchy are clear enough to be used for discussion 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 later stages of software production, such as coding.
6. UML is overly complex, especially in its use of many different and sometimes confusing graphical symbols and its multiple ways of expressing the same idea, while StateWORKS is based on simple and elegant finite state machine concepts that have been well known for many decades and has a shallow learning curve.