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 magic 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 never 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 any other modeling language. Indeed, StateWORKS allows one to specify software behavior completely, thus producing executable specifications. Code generation would be an unnecessary step introducing inefficiencies.
What’s wrong with writing code?
StateWORKS imposes a strict partition 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 by careful classical code writing and testing, the level of complexity here is fairly low, so there are no risks. For input-output functions, StateWORKS comes with 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 cope with 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 completely 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 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.
Yet UML is complex and very hard to learn, with its confusing symbols, its unmanageable large charts and multiple ways of expressing the same thing. Whereas 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 easy.