I've had heavy exposure to Miro Samek's "Quantum Hierarchical State Machine," but I'd like to know how it compares to Boost StateCharts - as told by someone who has worked with both. Any takers?
A:
I am unfamiliar with Boost StateCharts, but something I feel Samek gets wrong is that he associates transition actions with state context. Transition actions should occur between states.
To understand this bug, requires an example:
What if a state has two different transitions out? Then the events are different but the source state would be the same.
In Samek's formalism, transition actions are associated with a state context, so you have to have the same action on both transitions. In this way, Samek does not allow you to express a pure Mealy model.
While I have not provided a comparison to Boost StateCharts, I have provided you with some details on how to critique StateCharts implementations: by analyzing coupling among the various components that make up the implementation.
This answer is incorrect. My implementation technique supports both actions on transitions (Mealy automata) and entry/exit actions associated with states (Moore automata). For example, the Dr. Dobbs article "UML at $10.99" (http://www.drdobbs.com/embedded-systems/188101799) shows a pedestrian crossing state machine that uses both actions on internal transitions and entry/exit actions.--Miro Samek
Miro
2010-08-25 22:22:42
@user429921: There certainly is no bug in Samek's approach. It is true that Samek's transition actions "physically" execute while still in the departing state. However, "logically," it is a non-sequitor to deduce non-compliance with Mealy (partly because Samek does not allow two events to be handled concurrently in one state machine, rather he follows a RTC model).
Brent Arias
2010-08-25 23:40:06
@Mystagogue: It is true that you need some logical rule for ensuring coherence. I should NOT have used the word "bug" to describe Samek's system (apologies). Rather, I should have said "To understand [WHY I DON'T LIKE THIS STYLE], requires an example". The upshot of Samek decision for transition actions executing "physically" while still in the departing state is that they are conceptually coupled to the source state. Do you think there is a better way to analyze library design? Basics include feature parity, performance, documentation, defect track record.
2010-08-26 00:24:06
Why executing transition actions in the source state context is bad? Why executing transition actions in the least-common-ancestor of source and target LCA(source, target) is a better alternative? Actually, I was trying to get this explained for years.
Miro
2010-08-26 11:20:07
@user429921: I suggest it is only "conceptually coupled" if you don't make a distinction between logical and physical. If you think and code as if they are not coupled, no latent behaviorial anomolies will emerge. This is why, I propose, the physical representation is moot.
Brent Arias
2010-08-26 17:45:43
A:
I know them both, although at different detail levels. But we can start with the differences I've came across, maybe there are more :-) .
Scope
First, the Quantum Platform provides a complete execution framework for UML state machines, whereas boost::statechart only helps the state machine implementations. As such, boost::statechart provides the same mechanism as the event processor of the Quantum Platform (QEP).
UML Conformance
Both approaches are designed to be UML conform. However, the Quantum Platform executes transition actions before exit actions of the respective state. This contradicts the UML, but in practice this is seldom a problem (if the developer is aware of it).
Boost::statechart is designed according to UML 1.4, but as far as I know the execution semantics did not change in UML 2.0 in an incompatible way (please correct me if I'm wrong), so this shouldn't be a problem either.
Supported UML features
Both implementations do not support the full UML state machine feature set. For example, history states and parallel states (aka AND states) are not supported directly in QP. They have to be implemented manually by the user. Boost::statechart does not support internal transitions, because they were introduced in UML 2.0.
I think the exact features that each technique supports are easy to figure out in the documentation, so I don't list them here.
As a fact, both support the most important statechart features.
Other differences
Another difference is that QP is suitable for embedded applications, whereas boost::statechart maybe is, maybe not. The FAQ says "it depends" (see http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/faq.html#EmbeddedApplications), but to me this is already a big warning sign.
Also, you have to take special measurements to get boost::statechart real-time capable (see FAQ).
So much to the differences that I know, tell me if you find more, I'd be interested!
Daniel M.
2010-09-28 21:10:09
Does boost::statechart support hierarchical states, or only flat state charts?
Brent Arias
2010-09-28 21:51:23
Yes it does. See http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/index.html#Overview for a feature list. By the way, you may want to take a look at boost::MSM (meta state machine), which is new in Boost 1.44. It seems to have a better SM definition syntax, but I don't really know it.
Daniel M.
2010-09-30 16:02:52