My first idea was just to repeat this example. Before I started I made a short analysis of the topic “calculator” discovering some interesting points. Using calculators I imagined that something like a standard user interface existed. I have been sometimes confused when getting into my hands a new calculator whose behavior is different to other ones. Anyway, I never worried much about this as my interest is limited to very simple operations. If my calculations are a bit longer or more complex I use spreadsheets.

Let’s then define the calculator to be designed. The simplest calculator possesses the keys:

• to define the operands: digits (0..9), number sign (±) and decimal point (.)

• to define the operations: add (+), subtract (-), multiply (*), divide (/), equals (=)

It has a display to show the operand typed in and the calculation result.

The few calculators I had at hand are similar but the use of the keys is not standardized:

• the role of keys C and CE are interchanged; sometimes they get other names

• the equals key (=) allows sometimes the calculation to be continued

• the continuation of calculation after termination may be done using operation keys +-*/

The calculation scheme of Samek’s example adheres to the standard one: an actuation of an operation key (+-*/) is unique and defines the next operation, the following actuation of operation keys are ignored and the calculator awaits the operand. The limitation has been introduced to show that in such a case it is possible to use the key “-” in a double role: as an operation key (subtract) and as a sign of the operand. The other simplification is the priority of operations: they are performed in the sequence in which they are entered, let’s call it the “arithmetic for dummies”. It means that typing “1+2*3=” you get 9 instead of the expected 7. Maybe for people who terminated their education in the first class of the grammar school such calculations make sense but most of us respect the usual priority of arithmetic operations and such calculator would be rather useless for them. Imagine you want to calculate your shopping expenses: a piece of butter, 4 bottles of beer, 3 bars of chocolate, etc; no chances to do it with such a calculator (unless it has an add-to-memory feature of course). You find this kind of arithmetic in “simple” calculators. A curiosity of the Windows calculator is that in the Standard mode uses the “arithmetic for dummies” and if you switch to the Scientific mode it uses the arithmetic priority rules. Strange, the use of normal arithmetic is considered as a scientific approach! This limitation in the Samek example is obvious: to make the example as simple as possible, otherwise it will be too difficult. This is a artificial example, used to explain how to use statecharts in UML design. Obviously, UML statecharts does not work for any more practical problem.

As we prefer to work with examples taken from practice I had to decide which calculator from the few ones on my table and screen should be emulated. Eventually, I decided to design the calculator similar to one found on any computer running Windows.

Playing a little bit with this calculator I have found it has rather strange behavior in some situations. It is fairly easy to get the calculator to produce random results without any indication that the only way out is to reset it using the key “C”. For instance, trying “2/0+” you get expected “Cannot divide by 0″ but continuing with keys “CE” and “=” you get 10 (!). Maybe it is the code number of the software bug! Typing “2/0”= you get the same expected “Cannot divide by 0″ but continuing with keys “CE” and any new operand the calculator is in a loop generating “Cannot divide by 0″ which is in a way better. Of course the only solution is again the reset with the key “C”. Another example: “5+9/=” produces 10 which corresponds to “5+=” the pretended algorithm of using equals key “=”. But typing “5+9/CE=” produces an error message “Cannot divide by 0” (i.e. the clear key introduces 0 as an operand!). And now try “5+9/0=CE” and you get 100!

The calculator has another problems with unexpected sequences of operation keys. For instance, if you type “2+7*=” you get 4 (in Scientific mode). The Windows calculator manifests also a specific behavior after terminating the calculation with the equals key “=”. Repeating the key “=” performs the last operation using the result and the last operand; effectively it is the cash register function which is done normally using the key “+”. But if you change the operation and continue with the key “=” it continues using in the first step the last result as both operands. No idea what is this function for. I could not find any explanation of the described (faulty?) behavior in the voluminous Help which describes many obvious topics but does not explain how the calculator is to behave in the above described situations. In this situation the calculator ignores also entered numbers without informing the user about it. So if you type for instance”1+2=” you get 3. Entering then “4=” you get 5 which is OK in relation to the cash registration function but is confusing for the user who entered 4 having something else in mind. Investigating more carefully the behavior after entering the key “=” you will find also an algorithm that explains the strange result of previously shown operation “2+7*=”. This algorithm says: forget the last operator and operand and perform the cashier function. This might explain the behavior but what is this functionality for? Of course, the results in examples discussed in this section are different for Scientific and Standard modes. A possible use for this feature is to calculate compound interest: try 1.06 * = = = = = ; each = shows the effect of an extra 6% compound interest.

The calculator seems also to have difficulties with operation on and presentation of floating point numbers. By typing the sequence “9- sqrt =” you get 6 (as expected). By repeating the Equal sign you expect to get values decreasing by 3. It works but the 0 value is not correctly displayed. Namely the results are: 3, -3,46391…e-37, -3, -6, etc. I have not investigated this problem further as the numerical computation is not my favorite topic but it is a rather strange effect.

To get a more complete picture I have taken another calculator that I have in my drawer and repeated the same exercises getting different results but also partly erroneous!

I have to admit that after that experience I was a bit shocked. I have been convinced that a calculator is a mature product delivering correct results, not only for operations like 2+2. Obviously the software in these tested examples fails in “unexpected” situations. It is more or less a known problem in software implemented according to “use cases”, where the adequacy of the set of “cases” is left to the good will, time and ability of programmers.

After that introductory work I decided to take the problem seriously and design it with StateWORKS. I have been convinced that it is possible to get a calculator which behaves as required in all situations. I will present it in few steps. You find the discussion in the Case study section in a document “Calculator”.

]]> http://www.stateworks.net/2009/08/calculator/feed/ 0 http://www.stateworks.net/2009/03/introducing-questions/ http://www.stateworks.net/2009/03/introducing-questions/#comments Thu, 19 Mar 2009 11:16:27 +0000 Ferdinand Wagner http://stateworksnet.cmarc.net/2009/03/introducing-questions/ In the category “Questions” you can ask any question about Virtual Finite State Machines or about how to use StateWORKS development tools. Simply post a comment to this entry.

Unfortunately, the state machine concept in software has been firstly used for theoretical purposes in the mathematical foundation of computer science where obviously only the event driven parser model is useful. This model assumes that a state machine is triggered by an event to do something and possibly change a state. This model applied to application software where a control systems are modeled is totally useless: in our book (Wagner F. et al.: Modeling Software with Finite State Machines) we discussed in details the limitations of that model, especially the problem of state number explosion.
A recent email has provoked us to show the solution of a traffic light controller in the Solution page on our web site. This email shows again the damage that is produced by tools which use the UML syntax for specifying state machines. The base is a statecharts idea that assumes the above mentioned parser model.
I do not want to repeat here any extracts from the book or numerous technical notes and case studies available on our web site. I would limit my comments only to two topics that are the essence of all the misunderstandings that surround the state machine concept.
1. An event is a signal that triggers the state machine to work: to do something and change a state (I do not want to go now into the different models with input action, entry actions, etc. as these are secondary issues). The conditions that determine what to do and whether to change a state is not the event itself but the value of one or more state machine inputs (see for instance Chapter 7 in the book). In the Traffic Light example the transition condition from the state Hgreen_FRed to the state HYellow_FRed is Vehicle_DETECTED & Ti_Green_OVER, i.e. the transition condition is an AND operation of two input values: Vehicle_DETECTED and Ti_Green_OVER. If you try to do it using only the event as a condition you end up in a lunatic world with a state machine inside a state, flags in a state machine, inventing “guards” on transitions, concurrencies, and so on.
2. There is very rarely a need for concurrent state machines. First of all a system of concurrent state machines makes sense only if you have a true multiprocessor system and you are able to partition the (multiple) state machine execution onto several processors. Secondly, you need to have a reason to do it. In reality you normally need three levels of parallelism: the system of state machines, the input handling system and the output handling system. The input handling system processes the inputs, makes them available to the state machines and generates events to trigger state machines if any input changes. The output handling system performs action as ordered by state machines. If those two time-consuming tasks run concurrently to the system of state machines this system is just a decision machine, to order the output handling system what to do on the basis of the actual input conditions and a state, and is very fast in operation. In such a model it is difficult to discover any motive for requiring concurrency of state machines.
Any comments will be appreciated.

In most cases the individual programmers can not be blamed for the misery. The results of their work depend on the environment, in which unrealistic goals and deadlines are set. Also on the platform (e.g. operating system) used and on the development system which are often imposed by ignorant managers.
Nevertheless, we must admit that we are responsible for the idea that software is a kind of artistic activity that does not require engineering discipline. We are responsible for sabotaging any attempts to use specifications seriously (do you know those UML or other standardized requirements documents prepared because “those of the top” want it, but never used in the generation of the software in detail?). We reject requirements for making documentation that could be useful to our successors (and even to ourselves some years later). We are responsible for using for any new task a tool (language, method) we happen to have learned, ignoring the very important paradigm that “every task requires the proper tool”. There is a long list of our sins that culminates “in code we trust”, meaning that only the final source code can represent the real documentation. But source code is usually unreadable, in that a clear overview of behavior in all circumstances is only visible with great difficulty.
Do we see a way out of this misery? Your opinion will be appreciated by other programmers.

As the i/o interface requires a very high reliability the implementation of tcpip used for an io interface is a true challenge. Our solution with Request and Events channels fulfills the i/o requirements. That goal has been achieved by careful design taking into account several possible distortion of the tcpip link.

Before I answer your questions I would like to make a general comment. There are two aspects of any method that uses a state machine concept. The first one is the specification, the second its implementation. Most methods are just limited to the specification. In that case the implementation is left to the user that interprets it on his own and completes the missing issues in the specification. After a while the specification looses its meaning and only the implementation (that is the code) counts. This rule is true not only for a state machine specification but defines a relation between any specification and implementation. We want to do it better in StateWORKS and provide a run-time system that executes the specification. The obvious consequences of our approach are:
- The specification must be complete as there is no chance to complete it in the code.
- While specifying we have to keep in mind the execution model.
The last problem should not be underestimated as you will see later when I answer your question.
Q1) The execution sequence of input actions in the current state is not ordered per 4th point in box at top of page 187. Fine. From page 199 : “ …. actions may change other control variables and in turn corresponding virtual inputs: all of them are treated 1-by-1 in the emerging sequence until all events are fully processed.” Does this imply that input actions in the present state may be executed iteratively? [Yes - order of consequent and causative input actions in StateA ST immaterial!] If an input action that was not due initially then becomes due after a subsequent due action is performed will it get executed? [Yes] The flowchart on page 186 implies not, I think.
A1. The first part of the book is about specification of a state machine and a system of state machines. We have tried to keep it implementation independent and therefore we have limited our consideration of the execution path to the flow chart represented on p.186. We need the flowcharts to explain the basic idea of multiple state transitions after a single events. Note that other implementations are imaginable and also available in StateWORKS (we can discuss it sometime later). The executor as implemented in RTDB has a queue (which is not shown on the flow chart) where events wait to be served. If the executor terminates serving of a given state machines (i.e. there are no transitions due) it returns on the flow chart to the point “wait for VI change”. The real executor checks whether the queue is empty and if not it takes the event from the queue and continues. In reality it is still more complex but I try in this moment just to explain the mechanism.
Q2. With multiple state transitions after a single VI event, the input actions of the intermediate states are ignored per 2nd point in box at top of page 187. Ok but what about those of the final state? [Also ignored.] If these simply do not get executed I have concerns that the vfsm will be left sitting in the final state when it may have already due input actions that would cause actions resulting in changed outputs or even further state changes. [True] Assuming such due input actions remained so, they’d then get executed when the next (unrelated?) VI event occurred – yes? [Yes – toggling the increment Cnt1 DI causes StateB to then trigger input actioned DO-HIGH showing Cnt2 over!] Possible alternative ………determining no immediate state transition is due defines the “final” state and then if the VI has changed since starting execution of the original current state this should be a “new” VI event causing any due input actions of the “final” (for now) state?
A2. Yes, by multiple transitions only the input actions in the starting state are performed. We are not able to distinguish between intermediate states and a final one. In event driven systems there is always a chance of “missing” trigger. We have to think about it while specifying the system. We should not overuse the input actions. The best state machines are of type Moore where the only actions are the entry actions. We pay for the simplicity with more states but avoid problems with input actions. Do not forget we are not building a hardware system where number of state does cost. In software minimizing the number of state is a rather irrelevant criteria; we should speak about optimizing the number of state, i. e. to have as many states as we need to make an understandable state machine.
Q3. Something that came up in my test : An entry action does ResetStart on a counter that was over. There is a transition action with condition same counter over – it gets triggered?
A3. If the counter is reset the control value OVER is replaced by RESET. Thus, any condition containing the RESET value could be triggered (but not the condition with OVER which is not present any more). This effect has come up because of the generation I have explained in my direct email to you discussing the details of your state transition diagram.
Q4. Lastly a probably silly question but just to make sure I’m not missing something ……. Is it true that there is no way to cause an external source input (DI, DAT, PAR, NI) to change other than to have the controlled system or the “user” do it or for an OFUN to do it (DAT I’d assume)? Don’t see a way to connect a controlled system input to one of it’s outputs in swLab or SwMon?
A4. There are 3 types of objects in the specification system (and consequently in RTDB): input, output and input/output type. An input type as for instance DI can be used as a condition to control a transition or an input action. An output type as for instance DO can be used to define an action to be performed. The input/output as for instance XDA can be used (with some restrictions) for both purposes.
Other issues seen in your first example:
- The use of Input actions should be limited to actions that can be repeated without any side effects. For instance setting a Do output several times does not do any harm. But incrementing a counter on a static control value (like Di) will in general result in erroneous behavior: if the Di value (which triggers the counter) stays HIGH any event triggers the execution of Input actions, i.e. the counter will increment. Any event causes execution of the state machine as shown in the flow chart.
- Due to multi state transition mechanism a not “consumed” transition condition may cause an unintended transition while returning to the initial state. This results in an infinite loop that is detected and terminated by the Executor but it is of course an erroneous, not intended behavior.

/We should not forget that we attack in the book the main streams: UML, Agile, Statecharts and in general the chaotic “traditional” on the one hand C-based and on the other Microsoft MFC and similar tools, generating software that tends to be easily corrupted. That means we attack the true programmers’ world. It is surprising that the first negative remarks are after nearly two years. Note an interesting point: the reviewers admit that we really know the state machine topic but we do not know other things that we comment and criticize: unfortunately, they do not dare to mention one single topic that we do not know. They estimate it would be too dangerous to name something directly, so it is better just to express some general doubts about our competence outside the state machine topic. But the authors of the book have, in aggregate, many years of experience, often inside large companies, of software development in general and of the various techniques and tools criticized in Part 1 of the book in particular./
My friends have encouraged me to put my opinion in the blog. I will appreciate your opinion. Is the picture of the software development world presented in the book correct? If not, what are the basic weaknesses of our discussion?

The concept of a state machine is old; its definition belongs to the basics of Automata Theory. In principle it seems to be a simple definition and requires understanding of the “state” concept. In spite of its simplicity the concept has been deformed, corrupted, misunderstood and up now the well known misunderstandings about a state machine result in a relatively modest use of the state machine idea in the specification and design of software. In our publications we try to indicate that a state machine is so well defined (see for instance the book or the technical note and the the already mentioned document about Moore and Mealy models) that it does not require re-definitions or (mis-)interpretations, especially that:
- a flow chart is not a state machine
- a Petri net is not a state machine
- a statechart is not a state machine
- there is no need to define an incomplete state machine under a new name (see for instance the technical note)
- it is possible to create a complex control system modeled by a system of state machines
to name only some topics discussed in our documents.
We are convinced that the concept of a finite state machine is one of the strongest ideas in the world of modelling control tasks in general and specifically in the design of a software control flow. A typical implementation of software control flow using the if-then-else and switch like mechanisms supported by numerous flags is a primitive style of development difficult to understand and accept in the 21 century.

Mealy and Moore models are the basic models of state machines. A state machine which uses only Entry Actions, so that its output depends on the state, is called a Moore model. A state machine which uses only Input Actions, so that the output depends on the state and also on inputs, is called a Mealy model. The models selected will influence a design but there are no general indications as to which model is better. Choice of a model depends on the application, execution means (for instance, hardware systems are usually best realized as Moore models) and personal preferences of a designer or programmer. In practice, mixed models are often used with several action types.