Boost状态图与Samek的“量子状态图”的比较

虽然在不同的细节层次上,我对它们都很了解。但我们可以从我遇到的差异开始,也许还有更多的差异。

范围

首先,Quantum平台为UML状态机提供了一个完整的执行框架,而Boost::StateChart只帮助状态机实现。因此,boost::statechart提供了与Quantum平台(QEP)的事件处理器相同的机制。

UML一致性

这两种方法都设计为符合UML。然而,量子平台执行转换操作 之前 各自状态的退出操作。这与UML相矛盾,但实际上这很少是一个问题(如果开发人员知道)。

状态图是根据UML 1.4设计的,但据我所知,它的执行 语义 在UML2.0中没有以不兼容的方式进行更改(如果我错了,请纠正我),所以这也不应该是一个问题。

支持的UML功能

这两种实现都不支持完整的UML状态机功能集。例如,在QP中不直接支持并行状态(aka和states)。它们必须由用户手动实现。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的实时功能(请参阅常见问题解答)。

我知道有这么多不同之处,告诉我如果你找到更多,我会感兴趣的!

我也与他们合作过,让我详细阐述一下Thedmi的伟大答案:

跟踪能力: qp还实现了一种称为qspy的强大跟踪功能,它支持具有过滤功能的非常精细的粒度跟踪。有了提振,你必须自己滚动,而且永远不会超过某个特定的粒度。

现代C++风格与编译时错误检查: 虽然BoostMSM和状态图会在你搞乱的情况下给出可怕的、非常长的错误消息(就像模板genius编写的所有代码一样,我羡慕),但这远远优于运行时错误检测。qp使用q_assert()和类似的宏来进行一些错误检查,但一般来说,您必须更仔细地观察qp,而代码则不太耐用。 我还发现在QP中广泛使用预处理器需要一些适应。有可能使用预处理器而不是模板、虚拟函数等,因为QPS在嵌入式系统中使用,其中C++编译器通常更差,硬件也不那么虚拟功能友好,但有时我希望Samek先生能制作C、C++和现代C++版本;预处理器。

可扩展性: BoostMSM不适用于任何超过20个状态的情况,状态图对状态几乎没有限制,但是状态可以进行的转换量受mpl::vector/list约束的限制。QP可以扩展到一个疯狂的程度,实际上可以无限的状态和转换。还应该注意的是,QP状态机可以分布在许多文件上,依赖性很少。

模型驱动开发: 由于QP具有极高的可扩展性和灵活性,因此它更适合于模型驱动的开发,请参阅本文进行详细的比较: http://security.hsr.ch/mse/projects/2011_Code_Generator_for_UML_State_Machines.pdf

嵌入式设计: QP是我心目中任何嵌入式设计的唯一解决方案。它的文档记录到了最基本的部分,所以它很容易移植,端口存在于许多常见的处理器中,除了状态机的功能之外,它还带来了很多东西。我特别喜欢原始线程安全队列和内存管理。我从来没有见过我喜欢的嵌入式内核,直到我在qp中尝试过rtc内核(尽管应该注意,我还没有在生产代码中使用过它)。

我不熟悉BoostStatecharts,但我觉得Samek错了,他将转换操作与状态上下文关联起来。状态之间应该发生转换操作。

要理解我不喜欢这种风格的原因,需要举个例子:

如果一个状态有两个不同的过渡,怎么办?然后事件是不同的,但源状态是相同的。

在Samek的形式主义中,转换操作与状态上下文相关联,因此您必须在两个转换上都有相同的操作。这样,Samek不允许您表达一个纯粹的Mealy模型。

虽然我没有提供增强状态图的比较,但我已经为您提供了一些关于如何批评状态图实现的细节:通过分析组成实现的各个组件之间的耦合。