TCA seems to be the perfect fit for this and we should be able to declare a state chart and generate the reducers. We can also generate testing plans based on the shortest paths from the test model's initial state to every other reachable state.
Put simply, a statechart is a beefed up state machine. The beefing up solves a lot of the problems that state machines have, especially state explosion that happens as state machines grow. One of the goals of this site is to help explain what statecharts are and how they are useful.
It would be also possible to display visually the state chart while using the app or the simulator (by connecting to external display).
Since the behaviour of a component is extracted into the statechart, it is relatively easy to make rather big changes to the behaviour of the component, compared to a component where the behaviour is embedded alongside the business logic.
Ian Horrocks, describes maintainability too:
It is difficult to measure maintainability, but it is worth making the following points. Changes to statechart modules were much quicker and easier to make than changes to other modules. The maintainability of statechart-constructed modules remained constant. There was no deterioration in the quality of the code, despite several significant changes to the designs. Three modules that were constructed using a bottom-up approach were rewritten using the statechart approach because the required user interface was too complicated to develop. No statechart module needed to be rewritten.
Ian Horrocks, Constructing the User Interface with Statecharts, page 200
Here are some references: