StateWORKS
Advantages for Software Designers
StateWORKS allows you to develop a complete application, without writing one line of code. You have the chance to work as engineer, not as a coder. All you have to do is to design the complete specification of the problem. When you are done, your application is finished, because the specification is the executable application. No need for coding.
StateWORKS does provide a structure which makes it easier to tackle a complex project, and it allows each component to be developed and optimised before the system is tested in its entirety. Because those elements which express the behaviour are expressed in a formal finite-state-machine format, which needs no manual coding to implement, there will be fewer problems in the final stages. StateWORKS could be categorised as a "Domain-Specific Language" where the domain is the behaviour.
The principle is to generate models, but this is not like the high-level decomposition techniques of UML - StateWORKS models are genuine implementations for your project, expressing all the details which would otherwise be in code. Many experts agree that state machines are under-utilised today - look at some references if you don't believe it - and with StateWORKS you can apply this powerful technique to real-world, complex systems, as it provides a method for dealing with large numbers of inter-linked state machines in an efficient and controllable way. So you can tackle those "impossible" projects with confidence, and get really good results.
A further advantage is that the StateWORKS finite state machine model is very simple, and that it can be used as a basis for discussions between programmers and customers. Most software projects can not be 100% fully defined at the start, and later discussions are needed to fix various details of the implementation. Using StateWORKS technology this can be done effectively at a quite early stage, and this avoids panic fixes at the end of the project, and wasted time in the earlier stages.
StateWORKS helps you to work in the same way as other engineering designers, who expect that their first prototypes will be very close to functional. They can not afford a hundred design and implementation iterations, and you should not want that either, even though it seemed easy to work like that when you first started programming. Get it right in the design phase, by modelling and simulation, and then implement - to a large degree automatically - when you are happy it's going to work. This is the only way to produce a reliable product. Avoid writing complex code that is hard to read and understand later.
For examples and explanations of the method, look at some case studies.