StateWORKS
Modeling Software with Finite State Machines: A Practical Approach
The Preface
The book discusses a topic that is among the central questions of software development. Therefore, we must position ourselves in that area to justify our right to express our opinion on that topic. Saying "we" implies at least one person in the co-author group. We have worked for several years in software development using various languages and development environments. We did this in large, medium, and small companies, as well as individually. We took part in projects in different positions as programmers, project leaders, managers, consultants. We know software from the university perspective as a scientific and teaching subject. Hence, we have experienced software from several perspectives. We regularly read books and journals ranging from IEEE journals to very simple marketing-controlled papers. This experience allows us to have a well-established opinion, which is independent of any pressure of specific professional circumstances. For instance, I have a rather bad opinion about BASIC but some co-authors did a good job with Visual Basic and see it in a better light than I; thus, we managed to find a compromise view about that issue.
The book is organized in three parts. Two parts represent a specific view on software development encouraging the use of state machines in software design and implementation. The Vfsm method and the State- WORKS tools, which are based on that method, are not simply concepts. They have been tried over several years in many projects, proving their sense and usefulness. The reader may agree with it or not, but the discussion can be led only on technical basis.
The first part may be the most controversial because it represents our view about software, which is per se a complex issue of not only technical character. Therefore, I explain in the first sentences of the Introduction our background. We try also to limit our opinion to technical matters.
The Vfsm concept discussed in the book is application oriented in comparison to the code-oriented approach that is typical for nearly all software development methods. There have been always trials to replace a classical software development by approaches that are more appropriate for inexperienced or occasional programmers. Interpretations of BASIC programs, PLC programming, and the Smalltalk development environment are all examples of software developments that do not require typical compilation, linking, and code debugging. Those approaches can be called "doing by trial" and are relatively safe as each written line can be tested immediately — at least for its syntactical correctness. This creates an illusion about the ease of programming. Of course, producing syntactically correct code lines easily does not mean that we are writing anything sensible. The known approaches of that kind do not provide any methods that would allow large software projects to be developed successfully.
The essential concept of StateWORKS is to use a ready-made program for realization of the most fragile part of software: the behavior. The work of the developer is then concentrated on a specification of the behavior. The input/output interface as well as any user interface must be programmed conventionally. The point is that in replacing coding of an application’s behavior by a specification we simplify the entire software development as the ready-made execution part is a frame that determines much of the software design. Effectively, many decisions about the software design are automatically made, as enforced by the execution program.
To create such a development and execution environment, several problems had to be solved. Behavior is the most complex part of software and therefore the source of most obscure errors. To replace coding based on continuous testing of conditions (if-then-else and case statements) we needed a new method and also an environment that allows for its implementation. The method used by StateWORKS is well known: modeling with state machines. To be successful, the method has also had to solve the problems of designing systems of state machines. The virtual environment is the base of a development and execution environment. The intimate meaning of those few sentences above are discussed in the book.
We must stress that the method proposed is not merely another way of programming finite state machines, embedded in other software, for certain applications — or parts of applications — which very obviously could use them. We are proposing a major re-think about the way to design software, in which most of the usual “control-flow” coding is avoided, and the state machine concept is pushed much farther than before, so as to take a predominant part in the design process.
We have written this book about a topic that has occupied us for several years. All co-authors contributed, although in different ways. F. Wagner who invented the Vfsm concept wrote most of the text in the book. R. Schmuki’s achievement has been in the design and implementation of the RTDB, which is the heart of the StateWORKS runtime system. P. Wolstenholme’s deep understanding of control system problems was a constant inspiration to improve the tools and the text. T. Wagner introduced some fresh air in the established environment forcing us to re-think several “obvious” concepts, which led to several improvements of the tools and text.
The book uses “we” instead of an impersonal form. In rare cases, “I” is used to express my personal view: though it is my (F. Wagner’s) view, the co-authors obviously support it or at least have not protested too strongly.
F. Wagner