Boost 状态图与 Samek 的“量子状态图”的比较
我经常接触 Miro Samek 的“量子分层状态机”，但我想知道它与 Boost StateCharts 相比如何——正如使用过这两种机器的人所说的那样。有接受者吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我了解他们两个，尽管细节程度不同。但我们可以从我遇到的差异开始，也许还有更多:-)。
范围
首先，Quantum Platform 为 UML 状态机提供了完整的执行框架，而 boost::statechart 仅帮助状态机实现。因此，boost::statechart 提供了与 Quantum Platform (QEP) 事件处理器相同的机制。
UML 一致性
这两种方法都被设计为符合 UML。但是，量子平台在相应状态的退出操作之前执行转换操作。这与 UML 相矛盾，但实际上这很少会成为问题（如果开发人员意识到这一点）。
Boost::statechart是根据UML 1.4设计的，但据我所知，执行语义在UML 2.0中并没有以不兼容的方式改变（如果我错了，请纠正我），所以这个也不应该是一个问题。
支持的 UML 功能
这两种实现都不支持完整的 UML 状态机功能集。例如，QP 中不直接支持并行状态（又名 AND 状态）。它们必须由用户手动实施。 Boost::statechart 不支持内部转换，因为它们是在 UML 2.0 中引入的。
我认为每种技术支持的确切功能很容易在文档中弄清楚，因此我不会在这里列出它们。
事实上，两者都支持最重要的状态图功能。
其他差异
另一个差异是 QP 适合嵌入式应用程序，而 boost::statechart 可能适合，也可能不适合。常见问题解答说“这取决于”（请参阅http： //www.boost.org/doc/libs/1_44_0/libs/statechart/doc/faq.html#EmbeddedApplications），但对我来说这已经是一个很大的警告信号。
此外，您必须进行特殊测量才能获得 boost::statechart 实时功能（请参阅常见问题解答）。
我知道的差异就这么多，如果你发现更多，请告诉我，我会很感兴趣！
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, 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!
我也曾与两者合作过，让我详细阐述一下 Dmi 的精彩答案：
跟踪功能：
QP 还实现了名为 QSpy 的强大跟踪功能，它可以通过过滤功能实现非常精细的粒度跟踪。对于 boost，你必须自己动手，而且永远不会超出一定的粒度。
现代 C++ 风格和编译时错误检查：
虽然如果你搞砸了，Boost MSM 和 Statecharts 会给出可怕且极长的错误消息（就像我羡慕的模板天才编写的所有代码一样），但这比运行时错误检测要好得多。 QP 使用 Q_ASSERT() 和类似的宏来进行一些错误检查，但一般来说，您必须更加注意使用 QP，并且代码的耐用性较差。
我还发现 QP 中预处理器的广泛使用需要一些时间来适应。可能有必要使用预处理器而不是模板、虚拟函数等。因为 QP 在嵌入式系统中使用，其中 C++ 编译器通常更糟糕，并且硬件对虚拟函数不太友好，但有时我希望 Samek 先生能够制作一个 C， C++ 和现代 C++ 版本；）有传言说我不是唯一一个讨厌预处理器的人。
可扩展性：
Boost MSM 不适用于 20 个以上的状态，Statecharts 对状态几乎没有限制，但状态可以具有的转换数量受到 mpl::vector/list 约束的限制。 QP 的可扩展性达到了疯狂的程度，几乎可以实现无限的状态和转换。还应该注意的是，QP 状态机可以分布在许多具有很少依赖性的文件上。
模型驱动开发：
由于其极高的可扩展性和灵活性，QP 更适合模型驱动开发，请参阅本文进行详细比较：http://security.hsr.ch/mse/projects/2011_Code_Generator_for_UML_State_Machines.pdf
嵌入式设计：
在我看来，QP 是任何类型嵌入式设计的唯一解决方案。它的记录很简单，因此很容易移植，许多常见处理器都存在端口，并且它带来了很多超出状态机功能的东西。我特别喜欢原始线程安全队列和内存管理。在我尝试 QP 中的 RTC 内核之前，我从未见过我喜欢的嵌入式内核（尽管应该注意的是我还没有在生产代码中使用它）。
I have also worked with both, let me elaborate on theDmi's great answer:
Trace capability:
QP also implements a powerful trace capability called QSpy which enables very fine granularity traces with filter capabilities. With boost you have to roll your own and you never get beyond a certain granularity.
Modern C++ Style and Compile time error checking:
While Boost MSM and Statecharts give horrid and extremely long error messages if you mess up (as does all code written by template geniuses I envy), this is far better than runtime error detection. QP uses Q_ASSERT() and similar macros to do some error checking but in general you have to watch yourself more with QP and code is less durable.
I also find the extensive use of the preprocessor in QP takes a bit of getting used to. It may be warranted to use the preprocessor rather than templates, virtual functions etc. because of QPs use in embedded systems where the C++ compilers are often worse and the hardware is less virtual function friendly but sometimes I wish Mr. Samek would make a C, a C++ and a Modern C++ version ;) Rumor has it I'm not the only one who hates the preprocessor.
Scalability:
Boost MSM is not good for anything above 20 states, Statecharts has pretty much no limit on states but the amount of transitions a state can have is limited by the mpl::vector/list constraints. QP is scalable to an insane degree, virtually unlimited states and transitions are possible. It should also be noted that QP state machines can be spread over many many files with few dependencies.
Model driven development:
because of its extreme scalability and flexibility QP is much better suited for Model Driven Development, see this article for a lengthy comparison: http://security.hsr.ch/mse/projects/2011_Code_Generator_for_UML_State_Machines.pdf
Embedded designs:
QP is the only solution for any kind of embedded design in my mind. Its documented down to the bare bones so its easily portable, ports exist for many many common processors and it brings a lot of stuff with it beyond the state machine functionality. I particularly like the raw thread safe queues and memory management. I have never seen an embedded kernel I liked until I tried the RTC Kernel in QP (although it should be noted I have not used it in production code yet).
我不熟悉 Boost StateCharts，但我觉得 Samek 的错误在于他将转换操作与状态上下文相关联。过渡行动应该在各州之间进行。
要理解为什么我不喜欢这种风格，需要一个例子：
如果一个状态有两个不同的转换怎么办？那么事件会不同，但源状态将是相同的。
在 Samek 的形式主义中，转换操作与状态上下文相关联，因此您必须对两个转换执行相同的操作。这样一来，Samek 就不允许你表达一个纯粹的 Mealy 模型。
虽然我没有提供与 Boost StateCharts 的比较，但我已经为您提供了一些有关如何批评 StateCharts 实现的详细信息：通过分析构成实现的各个组件之间的耦合。
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 why I don't like this style 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.