实际开发过程中，是利用QM工具构架状态图，并生成活动对象源码，在这里我们通过逆向的角度，已经有了ship活动对象源码的情况下，来分析一下他来自于QM的哪个部分，最后我们自建一个qm的工程一步一步添加代码，生成整个工程。
这完整的QM工程和由QM工程所生成的源码文件对比如下：
活动对象的底层原型就是一个状态机：QActive 就是 QHsm~！
对于状态机由两部分组成：内部成员和状态图。
内部成员构成类比于对象的属性：
状态图主要描述状态的迁移以及对不同状态对于相同事件，
做出不同的反应，核心在于状态的分析：
有了状态的分析，接下来看一下那些触发转换的事件，初始转换已经在上图中标出，这里 不再重复，所有带箭头的折线代表着转换，而每个转换皆有事件触发：
事件的作用一部分是用来触发状态转换，另一部分用于状态内部处理，并不触发状态转换：
借助QM构建工具，让ship状态机的流程变得更加的清晰，其实大部分的代码都是由QM工具帮我们生成的，这并不带代表着QM能够自动生成所有的代码细节，而是帮我们搭好了状态机的框架，利用框架进行代码定位更加清晰。
基于QM从零开始构建ship活动对象：
创建一个.C文件，输入独特的命令行：$declare${AOs::Ship}
点击执行生成代码：
打开你QM的工程目录，然后对比一下QM工程中状态机的样子，一个是图形化样子，一个是完全可以执行的代码。
接着输入命令展开状态机定义$define${AOs::Ship}：
此外状态机还需要一个给外部框架调用运行的指针，他是一个QActive类型的通用指针，需要单独定义及变换。
要启动一个状态机之前，除了拥有了其通用活动对象指针以外，还需要一个构造函数：
真正要让这个状态机跑起来，就需要在main函数中，调用构造函数对其进行构造，并调用框架提供的START函数，让他真正的运行起来：
到这里关于QM与活动对象Ship之间的爱恨纠葛就结束了，一个应用需要多个活动对象协调运转，后面不会展开这么细致的去分析QM与活动对象， 而是站在QM的角度来看待整个应用，他或许是一扇新的窗，希望会有阳光。