Why StateWORKS?

I’ve heard all this before!

Other companies have made all kinds of promises, from automatic code generation to general-purpose modeling languages to almost magical solutions.

StateWORKS is neither a code generator nor an interpreter; it is a proven, complete solution for engineering applications based on the well-known, mathematically sound concept of state machines. At StateWORKS, we can show that most software fails because writing code is intrinsically error-prone, so we do not generate code at all. StateWORKS generates applications in the form of files that work in conjunction with our libraries.

StateWORKS is also an excellent high-level modeling language that allows engineers to specify a software project in much finer detail and more efficiently than other modeling languages. Indeed, StateWORKS allows one to fully specify software behavior, thus producing executable specifications. Code generation would be an unnecessary step that introduces inefficiencies.

What’s wrong with writing code?

StateWORKS imposes a strict separation between data handling and control flow. In any project implemented with StateWORKS, some coding is required for the data-handling routines; these can be made reliable through careful, classical code writing and testing. The level of complexity here is fairly low, so there are minimal risks. For input-output functions, StateWORKS provides a full class library.

On the other hand, coding the control flow—even for relatively simple applications—is extremely complex and intrinsically error-prone. It is not possible, when coding a complex system, to account for its behavior in all possible situations, for example when multiple errors or unexpected inputs cause the system to enter an unknown state. StateWORKS excels at providing the architectural backbone for fully specifying the behavior of a system, thus making such unknown states impossible. Because they cannot occur, it is not necessary to test for them.

But everyone is talking about UML…

UML cannot be used to generate applications; at best, it can be used for a top-level overview of a project. It is suitable for system analysts, not for engineering an application. The StateWORKS engineering process focuses on designing the final product rather than merely describing roughly how it should work. In fact, the process brings problems to light early, rather than leaving them to be resolved later during coding.

Yet UML is complex and difficult to learn, with confusing symbols, unmanageably large charts, and multiple ways of expressing the same thing. In contrast, StateWORKS is an elegant approach to software design, capable of going into much finer detail than UML. With StateWORKS, no chart is larger than an A4 sheet of paper, the symbols are easily understood, and the learning curve is gentle.