前面，我們耗費了大量的篇幅來討論用例分析及用例圖。用例圖，無疑是功能分析、角色分析，以及流程分析的利器，它將我們要開發的系統，清晰而詳盡地描述出來。但是，正如任何事物都有兩面性，用例圖也不例外，也有自己不利的一面。在我看來，這集中體現在兩個方面：只見樹木不見森林、不生動形象。
什么叫“只見樹木不見森林”呢？就是說，用例說明中對業務流程的描述，過早地將系統的整體流程，分散到了各個用例中了，丟失了對業務流程的整體描述。不生動形象，則是說用例說明中對流程的描述都是用枯燥無味的文字來表述的，缺乏生動形象的圖形表示。針對這些不足，UML的另外兩種視圖，可以有效地彌補用例圖的缺陷。它們就是行動圖與狀態圖。
行動圖（Active Diagram），比較類似于我們過去繪制的流程圖，是UML中描述流程與分支的視圖。在行動圖中，往往是從一個實心圓的起始節點開始的。最頻繁使用的則是活動節點了，它表示的是業務流程中的一項活動。活動節點可以表述為一個活動短語（如下訂單），可以表述為一個表達式（如len=a.length+x），還可以表述為一個消息（如send(msg)）。同時，將各個活動節點連接起來的一個個實線箭頭，表明了各種活動之間的流轉順序。
在各種業務流程中，毫無疑問會有許多的分支。在行動圖中，分支用一個菱形來表示。一個指向菱形的箭頭，表示流程進入分支，另外兩個或多個從菱形伸出的箭頭，則表示不同條件下的分支流。而菱形本身，則表示為一個條件判斷語句。
另外，業務中的各個流程還會分岔與匯合的情況。分岔，表示在某個時間點上，同時開始兩個業務流程，這兩個業務流程是同步進行的。分岔用一個入箭頭，一根橫杠，與兩個出箭頭表示。匯合，則表示，只有在兩個流程都完成的情況下，才會進入下一流程，否則只能等待。
匯合則用兩個入箭頭，一根橫杠，與一個出箭頭表示。
最后，用一個或多個帶環的實心圓，表示的是活動圖的終止節點，代表了業務流程的終結。以上這些元素，就組成了一個基本的活動圖。然而，基本的活動圖還不能完整的反映我們的業務流程，因此我們還需要在基本活動圖的基礎上增加元素。現在我們來看看泳道與業務對象流。
如圖就是一個帶泳道的活動圖，圖中每個泳道代表一個參與者的業務操作，而整個圖形表述了多個參與者間的協作過程。起初我比較愛繪制這樣的活動圖，但后來常常感到繪制泳道是一件比較繁瑣的事情。既然如此，我們就改改吧。
這張圖才是我最愛使用的行動圖。圖中，將參與者由繁瑣的泳道改為了用例圖中的小人。同時，在這張圖中還增加了對象流與對象。圖中，自動考核結果、申辯申請單、調整后考核結果，都是數據對象，是該流程中相關環節操作的結果。從活動節點指向對象的虛線箭頭，則表示了一個對象流，如“申辯申請”活動指向“申辯申請單”的虛線箭頭，表示了申辯申請活動的最終結果是產生申辯申請單；從“調整后考核結果”指向“過錯追究”的虛線箭頭，表示過錯追究活動讀取了調整后考核結果。
當然，活動圖還有其它的元素，但我個人認為其實并不實用，使用以上元素就足以表述我們的業務流程了。活動圖打破了子系統與子系統的壁壘、用例與用例的壁壘，使我們能夠從整體上了解整個系統的流程，因此常常使用在對整個系統的概述、對整個子系統的概述，以及對整個功能模塊的概述中。同時，與其它視圖一樣，活動圖也應當有它的文字說明，以便對圖中的每個活動節點、分支進行描述。但對于一些流程相對簡單，甚至沒有什么流程的查詢報表類功能模塊，繪制它們的活動圖則顯得有些牽強附會，因此我們要靈活掌握。
除了活動圖，我們似乎對需求的描述還缺少點兒什么，那就是對關鍵對象中流程中狀態變化的描述，在這種情況下，我們的狀態圖就上場了。
在使用狀態圖時，一個非常關鍵的概念就是，一定是對某個關鍵對象的狀態變化的描述，而這些狀態變化一定是在某個業務流程的大背景下進行的。下圖是一個疑點數據整個生命周期的狀態變化圖。圖中，與行動圖一樣，一個實心圓點代表的是流程的開始，圓邊的方框代表的是對象生命周期中的各個狀態，狀態節點間的實線箭頭代表的是狀態的切換，箭頭的文字描述是觸發狀態切換的事件。與行動圖一樣，狀態圖可以有分支、分岔、匯合，并最后以一個或多個帶環的實心圓結束，代表對象生命周期的終結。
在需求分析中，狀態圖并不是必須的，它僅僅出現在你認為需要對某個對象的狀態進行說明的時候。
我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會
（續）
什么叫“只見樹木不見森林”呢？就是說，用例說明中對業務流程的描述，過早地將系統的整體流程，分散到了各個用例中了，丟失了對業務流程的整體描述。不生動形象，則是說用例說明中對流程的描述都是用枯燥無味的文字來表述的，缺乏生動形象的圖形表示。針對這些不足，UML的另外兩種視圖，可以有效地彌補用例圖的缺陷。它們就是行動圖與狀態圖。
行動圖（Active Diagram），比較類似于我們過去繪制的流程圖，是UML中描述流程與分支的視圖。在行動圖中，往往是從一個實心圓的起始節點開始的。最頻繁使用的則是活動節點了，它表示的是業務流程中的一項活動。活動節點可以表述為一個活動短語（如下訂單），可以表述為一個表達式（如len=a.length+x），還可以表述為一個消息（如send(msg)）。同時，將各個活動節點連接起來的一個個實線箭頭，表明了各種活動之間的流轉順序。
在各種業務流程中，毫無疑問會有許多的分支。在行動圖中，分支用一個菱形來表示。一個指向菱形的箭頭，表示流程進入分支，另外兩個或多個從菱形伸出的箭頭，則表示不同條件下的分支流。而菱形本身，則表示為一個條件判斷語句。
另外，業務中的各個流程還會分岔與匯合的情況。分岔，表示在某個時間點上，同時開始兩個業務流程，這兩個業務流程是同步進行的。分岔用一個入箭頭，一根橫杠，與兩個出箭頭表示。匯合，則表示，只有在兩個流程都完成的情況下，才會進入下一流程，否則只能等待。
匯合則用兩個入箭頭，一根橫杠，與一個出箭頭表示。
最后，用一個或多個帶環的實心圓，表示的是活動圖的終止節點，代表了業務流程的終結。以上這些元素，就組成了一個基本的活動圖。然而，基本的活動圖還不能完整的反映我們的業務流程，因此我們還需要在基本活動圖的基礎上增加元素。現在我們來看看泳道與業務對象流。
如圖就是一個帶泳道的活動圖，圖中每個泳道代表一個參與者的業務操作，而整個圖形表述了多個參與者間的協作過程。起初我比較愛繪制這樣的活動圖，但后來常常感到繪制泳道是一件比較繁瑣的事情。既然如此，我們就改改吧。
這張圖才是我最愛使用的行動圖。圖中，將參與者由繁瑣的泳道改為了用例圖中的小人。同時，在這張圖中還增加了對象流與對象。圖中，自動考核結果、申辯申請單、調整后考核結果，都是數據對象，是該流程中相關環節操作的結果。從活動節點指向對象的虛線箭頭，則表示了一個對象流，如“申辯申請”活動指向“申辯申請單”的虛線箭頭，表示了申辯申請活動的最終結果是產生申辯申請單；從“調整后考核結果”指向“過錯追究”的虛線箭頭，表示過錯追究活動讀取了調整后考核結果。
當然，活動圖還有其它的元素，但我個人認為其實并不實用，使用以上元素就足以表述我們的業務流程了。活動圖打破了子系統與子系統的壁壘、用例與用例的壁壘，使我們能夠從整體上了解整個系統的流程，因此常常使用在對整個系統的概述、對整個子系統的概述，以及對整個功能模塊的概述中。同時，與其它視圖一樣，活動圖也應當有它的文字說明，以便對圖中的每個活動節點、分支進行描述。但對于一些流程相對簡單，甚至沒有什么流程的查詢報表類功能模塊，繪制它們的活動圖則顯得有些牽強附會，因此我們要靈活掌握。
除了活動圖，我們似乎對需求的描述還缺少點兒什么，那就是對關鍵對象中流程中狀態變化的描述，在這種情況下，我們的狀態圖就上場了。
在使用狀態圖時，一個非常關鍵的概念就是，一定是對某個關鍵對象的狀態變化的描述，而這些狀態變化一定是在某個業務流程的大背景下進行的。下圖是一個疑點數據整個生命周期的狀態變化圖。圖中，與行動圖一樣，一個實心圓點代表的是流程的開始，圓邊的方框代表的是對象生命周期中的各個狀態，狀態節點間的實線箭頭代表的是狀態的切換，箭頭的文字描述是觸發狀態切換的事件。與行動圖一樣，狀態圖可以有分支、分岔、匯合，并最后以一個或多個帶環的實心圓結束，代表對象生命周期的終結。
在需求分析中，狀態圖并不是必須的，它僅僅出現在你認為需要對某個對象的狀態進行說明的時候。
我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會
（續）
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
