實際開發過程中，是利用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的角度來看待整個應用，他或許是一扇新的窗，希望會有陽光。