應用程式有兩大類：

 

1. 一種是資料處理的程式，我們常常用演算法來描述它，程式對某些輸入資料進行預定的處理，以便得到某些輸出的資料，程式目前的狀態可以用資料目前的狀態來描述，例如：人事薪資系統、倉儲物流系統等等；

    

2. 另外一類是與外界環境互動的系統，例如：作業系統、文書處理系統、飛航管制系統、交通管制系統、遊戲等等，這一類系統一般來說沒有明確的輸入/輸出資料，但是有很多與外界不預期的互動，通常系統回應的方法與系統內部的狀態有密切的關聯，系統內部通常有許多記錄狀態的變數。

針對這兩大類的程式，我們描述它們的方法也不太一樣，對於前者，我們通常用控制流程圖或是資料流程圖來描述，對於後者則常用狀態圖來描述。基本上流程圖中最重要的部份是 "處理 process" 單元，程式由幾個主要的處理單元組合而成，狀態圖中最主要的是程式目前的狀態，每一個狀態總結記錄程式由開始到目前所有接到的輸入。

控制流程圖常常只描述單一的程序 (執行緒)，多個程序的控制流程圖需要使用同步機制來描述，如果流程圖中各個區塊的連結非常複雜的話，有可能式程式不屬於資料處理類的，無法用 "處理單元" 來清楚地描述，需要改用其它的方法來描述。狀態圖基本上並沒有限制只能描述單一的程序 (執行緒)，狀態圖上任一時間點系統只能在某一狀態下，而任一時間點只會有單一的事件發生 (假設時間的精確度足夠的話，任何兩件事一定可以分辨出先後的順序)。狀態圖上的動作基本上是由事件來驅動的，和事件驅動的物件導向式程式模型相當契合。

 

一個狀態圖是否可以用流程圖來取代呢?

以下面的這組狀態圖及流程圖為例：

 

狀態圖

流程圖

控制流程圖一般描述單一的處理器 (行程) 之處理過程，上面流程圖中任意時間點都只執行單一一個區塊的內容，如果有不同的處理器共同參與的話，也一定有先後的順序，某一區塊 (例如 a1) 也有可能讓多個處理器一起共同執行以加快處理的速度。流程圖中條件測試必須依序執行，例如： e1, e2, e5, 如果都不成功的話，會不斷地重覆測試，此時 e1, e2, e5 的條件有可能因為外界環境改變或是其它程序干涉而改變。在狀態圖中系統所有的處理器一併考量在內，任何時間點上系統必然處於三個狀態之一，假設在 state 1，此時不管哪一個處理器使得 e1, e2 或是 e5 發生，則系統會讓相對應的 a1, a2 或是 a5 執行完畢 (不論是用哪些個處理器來完成)，然後系統狀態進入 state 2。

在這個範例上狀態圖明顯在架構上比流程圖要簡單，包容的模型也比較豐富，需做的假設比較少。另外，狀態圖比較重視事件/動作的完成，比較不在意是哪一個程序完成的。流程圖則很在意動作是如何完成的。在狀態圖上如果某一個狀態下少考慮了哪一個輸入事件的話，可以很快地檢查出來，可是在流程圖上就無法分辨了。狀態圖上沒有事件發生時，系統就暫停下來等待 (沒有做什麼有意義的事情)，流程圖上則變成一個所謂的 busy loop。狀態圖比較適合物件導向的程式，流程圖則比較適合描述程序導向或是資料處理的程式。

狀態圖範例:

 

TCP 連線狀態圖 (See Steven's book)

 

Delete Document 物件運作狀態圖 (see Kerr's book)

 

 

繪製狀態圖常用元件