活動圖用來描述事件流(這兒我開始避免用流程圖這一詞，以免混同意傳統的流程圖術語)，狀態圖是描述某個<

狀態圖是用來描述一個用例的執行過程中所經過的狀態。至於這些狀態是內部狀態還是與外部相關，並不重要。所以，跟流程圖有很大的相似性。因為在UML裡面好象是沒有流程圖這種東西的，當我希望表達一個操作流程的時候，最合適的工具就是狀態圖了，本來活動圖也是可以扮演這個角色，而且更加適合。但是實際上活動圖也是一種特殊的狀態圖，所以我就乾脆大膽的用狀態圖來表示了。：）
而且，在系統的需求階段，有哪些物件以及哪些子系統都是不明確的，甚至於操作流程也是不明確的，在這種情況下運用活動圖就需要引進很多人為的假設因素。
當然，狀態圖顧名思意，就是要表達用例執行過程中的每一個穩定狀態，而不是表示一個行為。但我以為，在需求階段，可以把這個原則作為一條參考即可。因為需求階段我們的目標是準確的用客戶的語言來描述系統，而不必很深入的去研究某個用例中到底哪裡是一個穩定狀態。過早的深入細節會使我們失去對巨集觀的控制。
但是如果到了分析階段、乃至設計階段，不去分析穩定狀態就完全不行了，所以如果在分析、設計階段應用狀態圖、活動圖，就必須遵循表達穩定狀態的原則。但是我個人覺得，如果是到了分析階段、設計階段，狀態圖、活動圖這些東西所能包含的資訊也許就過於有限，反而必須要大量的使用互動圖、時序圖了。