Comparison of Boost StateCharts vs Samek "Quantum Statecharts"

Question

I had a strong impact on Miro Sameka's “Quantum Hierarchical State Machine”, but I would like to know how it compares with Boost StateCharts - as someone who worked with both told. Any members?

Answer 1

I know both of them, albeit at different levels of detail. But we can start with the differences I came across, perhaps more of them :-).

Scale

First, the Quantum platform provides a complete working environment for UML state machines, while boost :: statechart only helps in the implementation of the state machine. Thus, boost :: statechart provides the same mechanism as the Quantum Platform Event Processor (QEP).

UML Compliance

Both approaches are designed to conform to UML. However, the Quantum platform performs transition actions before the exit actions of the corresponding state. This is contrary to UML, but in practice this is rarely a problem (if the developer knows this).

Boost :: statechart is designed in accordance with UML 1.4, but as far as I know, the execution semantics have not changed in UML 2.0 in an incompatible way (please correct me if I am wrong), so this should not be a problem.

Supported UML Features

Both implementations do not support the full set of UML state machine functions. For example, parallel states (aka AND) are not supported directly in QP. They must be done manually by the user. Boost :: statechart does not support internal transitions, as they were introduced in UML 2.0.

I think the exact features supported by each technique are easy to find in the documentation, so I don't list them here.

In fact, both support the most important statechart functions.

Other differences

Another difference is that QP is suitable for embedded applications, while boost :: statechart may not be possible. The FAQ says “it depends” (see http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/faq.html#EmbeddedApplications ), but for me this is already a big warning sign.

In addition, you must perform special measurements to get boost :: statechart in real time (see frequently asked questions).

So many differences that I know, tell me, if you find more, I would be interested!

Answer 2

I also worked with both, let me elaborate on the big Dmi answer:

Trace capabilities: QP also implements the powerful QSpy trace function, which provides very fine granular traces with filter capabilities. With amplification, you must collapse your own, and you never go beyond a certain granularity.

Modern C ++ style and compile-time checking: Although Boost MSM and Statecharts give horrible and extremely long error messages if you mess up (like all the code written by the template geniuses that I envy), this is much better than detecting errors in lead time. QP uses Q_ASSERT () and similar macros to check for some errors, but overall you need to look more at QP and the code is less robust. I also find that the widespread use of the preprocessor in QP is a bit getting used to. You may need to use a preprocessor rather than templates, virtual functions, etc. Due to the use of QP in embedded systems, where C ++ compilers are often worse and hardware less functional, but sometimes I want Mr. Samek to make C, C ++ and Modern C ++ version;) There is a rumor, I'm not the only one who hates the preprocessor.

Scalability: Boost MSM is not suitable for anything above 20 states, Statecharts practically does not limit the state, but the number of transitions that a state can have is limited by the limitations of mpl :: vector / list. QP scales to an insane degree, almost unlimited states and transitions are possible. It should also be noted that QP state machines can be distributed across many files with several dependencies.

Model development: due to its extreme scalability and flexibility, QP is much better suited for Model Driven Development, see this article for a long comparison: http://security.hsr.ch/mse/projects/2011_Code_Generator_for_UML_State_Machines.pdf

Embedded Designs: QP is the only solution for any embedded design. It is documented to the bone, so its portable portal ports exist for many many common processors, and it brings many things, besides it, beyond the functions of a state machine. I especially like secure flow queues and memory management. I never saw the embedded kernel that I liked until I tried RTC Kernel in QP (although it should be noted that I have not used it in production code yet).

Answer 3

I am not familiar with Boost StateCharts, but what I feel is that Samek is wrong is that it associates transient actions with a state context. Transition actions must occur between states.

To understand why I do not like this style, an example is required:

What if the state has two different transitions? Then the events are different, but the initial state will be the same.

In Samek formalism, transition actions are associated with a state context, so you must have the same action for both transitions. Thus, Samek does not allow you to express a pure Mile model.

Until I presented a comparison with Boost StateCharts, I provided you with some information on how to criticize StateCharts implementations: by analyzing the relationship between the various components that make up the implementation.