ST 12 A Neat Diagram Yields a Neat Design

We are continuing our journey on this garden model train named Hierarki to explore model-based software design. In this post, we illustrate some cool features of statecharts with GpioIn, a state-based driver for external interrupt pins. The two push buttons shown are represented by two concurrent instances of GpioIn serving as their “agents” in the software model.

Thanks to the hierarchical nature of statecharts, as we add substates to the Active state, existing behaviors continue to work. The PIN_INACTIVE event continues to bring it from the Active state to the Inactive state (while allowing customization for substates). The entry action of the Active state continues to send the GPIO_IN_ACTIVE_IND event to its client. This addresses the age-old problem that adding new code breaks existing code!

Hierarchy allows for factorization of common behaviors. The HOLD_TIMER event transitioning from the Active state to the Held state is an example. It takes care of both the HoldWait and the Held state, with the former entering the Held state for the first time and the latter re-entering it at each timeout. This is useful for detecting when a button is continuously held, during which a GPIO_IN_HOLD_IND event is periodically sent to the client upon each entry to the Held state. The entry action of the Active state guarantees the m_holdCount data member is initialized before the initial hold is detected.

The graphical nature of statecharts allows us to visualize the complexity of a design. Very often when striving for neatness or reduction in a diagram we’d come up with an equally neat and elegant software design.