狀態圖與流程圖

應用程式有兩大類：

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)

繪製狀態圖常用元件

回 視窗系統程式設計課程 首頁

製作日期: 11/13/2001 by 丁培毅 (Pei-yih Ting)
E-mail: pyting@cs.ntou.edu.tw TEL: 02 24622192x6615
海洋大學 理工學院 資訊科學系