Interoperability. State machines are typically just an abstraction for describing the logic of a system targeted at some problem domain(s) other than FSM construction. We'd like to be able to use libraries built for those domains in the implementation of our FSMs, so we want to be sure we can comfortably interoperate with other DSELs.

Declarativeness. State machine authors should have the experience of describing the structure of FSMs rather than implementing their logic. Ideally, building a new state machine should involve little more than transcribing its STT into a C++ program. As framework providers, we should be able to seamlessly change the implementation of a state machine's logic without affecting the author's description.

Expressiveness. It should be easy both to represent and to recognize the domain abstraction in a program. In our case, an STT in code should look very much as it does when we design a state machine on paper.

Efficiency. A simple FSM like our CD player should ideally compile down to extremely tight code that can be optimized into something appropriate even for a tiny embedded system. Perhaps more importantly, concerns about the efficiency of our framework should never give programmers an excuse for using ad hoc logic where the sound abstraction of a finite state machine might otherwise apply.

Static Type Safety. It's important to catch as many problems as possible at compile time. A typical weakness of many traditional FSM designs [LaFre00] is that they do most of their checking at runtime. In particular, there should be no need for unsafe downcasts to access the different datatypes contained by various events.

Maintainability. Simple changes to the state machine design should result in only simple changes to its implementation. This may seem like an obvious goal, but it's nontrivial to attainexperts have tried and failed to achieve it. For example, when using the State design pattern [Mart98], a single change such as adding a transition can lead to refactoring multiple classes.

Scalability. FSMs can grow to be far more complex than our simple example above, incorporating such features as per-state entry and exit actions, conditional transition guards, default and triggerless transitions and even sub-states. If the framework doesn't support these features today, it should be reasonably extensible to do so tomorrow.