Boost-(MSM)元状态机文档翻译-前言

元状态机(MSMV2.10)

前言：

MSM是一个允许用户创建高性能状态机的库，出于这点考虑，通常就会有两个问题，接下来请允许我深入回答这两个问题。

1 我们什么时候需要使用状态机？

你经常遇到一个问题，没有留意定义了一个很不正式的状态机，比如在类中定义了一个布尔型变量，来表示该类的任务完成了。可是后来这个布尔型变量其实需要第三个值，于是需要把布尔型变成整型，过了几周可能需要第二个属性，过了会又需要第三个，等等，于是你的代码可能写成以下的样子：

void incoming_data(data)

{

if (data == packet_3 && flag1 == work_done && flag2 > step3)...

}

如果对象本身某些进度已经被完成，这个看起来像是事件处理过程中（内部包含数据）（但是有点丑陋）

这可以看作是协议定义但也是状态机最常见的用法。另外一种使用场景就是用户接口UI，比如用户交互性过程定义，例如一旦按钮被激活，某个功能变的有效。

如果你对此感兴趣，会发现很多使用的场景。实际上，可执行UML,一个安全的模块驱动型开发方法（http://en.wikipedia.org/wiki/Executable_UML）利用状态机定义其所有的动态行为。在执行UML世界里，类图，状态图以及动作语言是完全需要你掌握的。

2 关于其他的类似库，怎么样？

正确，有很多状态机的库，如果你没有用过他们，可能你会少学这方面的一些东西。那我们为什么应该使用MSM呢？我们可以选择别的，在选择一个状态机库时，很不幸的是你经常遇到以下这些问题和障碍？

速度：你可能经常听人抱怨，状态机速度太慢了。可能因此而放弃这些库而自己去实现不是很完善的库（我是说有些开发人员，而不是说你的库不好），MSM没有这些问题，MSM的高效让很多开发人员注意。
简单易用：设计良好的参数，如果你使用别的库，也可能正常的使用，很多状态机库需要你这样定义状态：
state s1 = new State; // a state
state s2 = new State; // another state
event e = new Event; // event
s1->addTransition(e,s2); // transition s1 -> s2你的状态转换越多，代码可读性越差，很久以前，还没有Jave等语言的时候，很多电子系统采用状态机构建，该状态机采用简单的表来记录状态变换，那时你可以很容易看清整个状态机结构，能迅速发现你忘记的状态。由于OO技术的出席，这种简易的应用消失了。但是MSM却让你回到状态表的时代，最大的减少额外的复杂度。
定义方法：MSM提供了很多前向声明的方法，并且一直在努力提高状态机定义的技术，比如你可以按照eUML的形式定义状态：state1 == state2 + event [condition] / action
很简单，这不是语法糖，如此格式化，易读的结构有助于和该构建软件领域的专家交流，如果他们能够理解你的结构，可以使你减少很多bug。
模块驱动开发：模块驱动开发中最常见的问题是双向过程（从代码到模块和从模块到代码），道理很简单，如果你都很难理解你的建构，那么你的模块解析工具就会更难，MSM的语法有助于双向工具的解析。
特性：很多开发人员花费20%多的是时间定义UML标准，不幸的是，他们可能无法节省这20%的时间，因为很多UML的标准还没有实现，而MSM有很多标准，并且很多标准还在开发中。