繪製圖表是系統分析與軟體設計中的基本技能。它能將抽象概念轉化為團隊可理解與批判的視覺結構。然而,兩種方法經常讓實務工作者感到困惑:資料流程圖(DFD)與流程圖。雖然兩者都用來表示流程,但它們的用途不同,使用的符號也不同,且關注系統行為的不同面向。選擇錯誤的工具可能導致溝通誤解、邏輯缺陷或開發週期效率低下。本指南提供兩種方法的清晰且權威的解析。
理解這些圖表之間的細微差異,對參與需求收集、系統架構或流程改善的任何人來說都至關重要。本文探討技術規格、實際應用與關鍵差異,以確保模型的準確性。

流程圖是演算法、工作流程或程序的圖形化表示。它標示出達成特定結果所採取的步驟順序。流程圖的主要重點在於控制流程。它詳細說明了流程從開始到結束的邏輯,包括決策點、迴圈與條件路徑。
流程圖依賴一組標準化的圖形,通常與 ANSI 或 ISO 標準相關。每個圖形都具有特定意義,代表所執行的動作:
邏輯流程由連接這些圖形的箭頭表示。這種視覺層級結構使分析師能夠追蹤程式的執行路徑或業務程序的流程。在記錄系統在特定條件下的行為時尤其有用。
當複雜性在於邏輯與決策時,流程圖非常理想。請考慮以下情境:
流程圖的優勢在於其能夠清楚顯示分支路徑。若使用者輸入無效資料,流程圖會明確引導其進入修正步驟;若資料有效,則會進入處理階段。這種對控制邏輯的關注,正是使其與以資料為中心的模型相區別之處。
資料流程圖(DFD)是一種結構化分析工具,用於表示系統內資訊的流動。與流程圖不同,DFD 不會顯示操作的順序或事件的時間點,而是專注於資料移動。它說明了資料如何在系統的不同部分之間被轉換、儲存與傳輸。
DFD 使用由 Yourdon/DeMarco 或 Gane & Sarson 等方法論所定義的特定符號集。重點在於資料本身,而非控制資料的邏輯。
DFD 中一個關鍵規則是:資料不能在兩個資料儲存之間直接流動,除非中間有處理過程;同樣地,資料也不能直接從外部實體流動到資料儲存,除非中間有處理過程。這確保了所有資料儲存都涉及某種形式的轉換或管理。
DFD 是層級式的。它們被分解為不同層級,以管理複雜性並在需要時提供詳細資訊。
DFD 最適合用於定義系統的功能需求。它們幫助利益相關者理解系統處理哪些資料以及資料如何流動。應用情境包括:
DFD的主要優勢在於其能夠抽象掉時間與邏輯,專注於資訊架構本身。它回答的問題是:「資料會去哪裡?」而不是「系統如何決定要做什麼?」
雖然兩種圖表都使用箭頭和方框,但其背後的哲學理念差異顯著。混淆兩者可能會導致模型無法真實反映系統的本質。
| 特徵 | 流程圖 | DFD |
|---|---|---|
| 重點 | 控制流程(邏輯與順序) | 資料流程(移動與轉換) |
| 符號 | 橢圓、矩形、菱形 | 方塊、圓形、開放式矩形 |
| 箭頭 | 表示步驟的順序 | 表示資料的方向 |
| 時間 | 暗示順序與時間 | 不暗示順序或時間 |
| 決策點 | 中央(菱形) | 無(邏輯隱藏於處理過程中) |
| 資料儲存 | 未明確顯示 | 明確顯示(儲存庫) |
| 最適合用於 | 程式邏輯、工作流程 | 系統架構、需求 |
最重要的區別在於控制的概念。流程圖是一張控制地圖。它告訴你接下來會發生什麼。如果條件 A 成立,就前往步驟 B;否則前往步驟 C。這對於程式設計和操作程序至關重要。
DFD 是一張資料地圖。它告訴你有哪些資料可用,以及資料會流向哪裡。它不關心步驟 B 是否在步驟 C 之前執行。在 DFD 中,流程可以並行、順序或非同步執行。圖表僅顯示流程 1 產生資料 X,而流程 2 消費資料 X。
流程圖通常不包含資料儲存。它專注於動作。如果流程圖提到一個檔案,通常只是次要的輸入/輸出步驟。在 DFD 中,資料儲存是首要的成員。它代表系統的記憶體。早期識別資料儲存對於資料庫設計至關重要。DFD 強迫分析師思考資料的持久性,而流程圖則假設執行是線性的。
繪製圖示很容易;但繪製準確且有用的圖示則是一門學問。在切換這兩種方法論或在缺乏明確策略的情況下繪製時,常會出現幾種常見錯誤。
一個常見的錯誤是將判斷菱形放在 DFD 內部。DFD 不處理邏輯。如果一個流程依賴於某個條件,該條件應在流程附帶的文字中描述,而不是以菱形繪製。這能讓圖示專注於資料。
在 DFD 中,每個資料儲存都必須至少有一個輸入和一個輸出流程(除非是死資料儲存,這相當罕見)。如果資料庫存在,但沒有任何流程寫入或讀取它,則圖示有缺陷。同樣地,在流程圖中,每個判斷菱形都必須至少有兩個輸出路徑。
箭頭和圖形上的標籤必須精確。『資料』不是一個標籤。『客戶訂單細節』才是標籤。『處理資料』太弱。『驗證並儲存訂單』則很強。明確的命名規範可避免開發過程中的誤解。
試圖將太多內容塞入單一圖示會降低可讀性。如果一個流程框包含超過 5 到 7 個子流程,就應該分解為更低層級的 DFD。目標是管理複雜性,而不是隱藏它。
為確保你的圖示能發揮作用,請遵循以下指南。這些實務適用於任何圖示工具。
流程圖與資料流程圖(DFD)都是軟體開發生命週期(SDLC)中不可或缺的部分,但它們出現在不同的階段。
在初期階段,資料流程圖(DFD)通常是主要工具。它有助於定義系統在資訊處理方面必須執行的功能。它能幫助識別所需的輸入與預期的輸出。這有助於技術團隊與業務目標保持一致。
隨著專案進入設計階段,流程圖變得更加相關。資料流程圖中的高階需求會轉化為具體的邏輯流程。開發人員使用流程圖(或偽程式碼)來實現處理資料流程圖中所識別資料的演算法。
這兩種圖表在測試期間都可作為參考依據。測試案例可從流程圖中的路徑推導出來。資料完整性檢查可從資料流程圖中的資料流推導。當有變更需求時,更新這些圖表可確保文件內容保持準確。
對於企業級系統,簡單的圖表可能不夠。存在進階的建模技術,可用來彌補這兩種方法之間的差距。
泳道圖是流程圖的一種變體,增加了責任維度。它顯示每個步驟由誰執行。當多個部門互動時特別有用。它結合了流程圖的邏輯與組織背景。
對於物件狀態至關重要的系統(例如訂單從「已付款」變更為「已出貨」),流程圖可能過於線性。狀態圖顯示由事件觸發的狀態之間的轉移。這與專注於資料流動的資料流程圖,以及專注於程序步驟的流程圖有所不同。
實際上,團隊經常同時使用兩者。資料流程圖定義系統邊界與資料架構,而流程圖則定義特定流程中的邏輯。例如,資料流程圖顯示「訂單處理」是一個流程,而流程圖則詳細說明該「訂單處理」如何驗證信用卡並檢查庫存的內部邏輯。
在資料流程圖與流程圖之間做選擇,並非哪一個更好,而是哪一個適合你試圖回答的特定問題。若需了解資料如何流動,請使用資料流程圖;若需了解決策如何做出,請使用流程圖。
掌握兩者可實現全面的系統建模。這能確保架構穩固(DFD)且邏輯可執行(流程圖)。遵循標準並避免常見陷阱,可建立經得起時間考驗的文件,並促進技術與非技術團隊之間的清晰溝通。
請記住,圖表是活文件。它們應隨著系統的演進而更新。定期審查與更新,可確保視覺呈現始終真實反映實際運作狀況。無論你是繪製簡單的工作流程,還是複雜的企業架構,清晰都是任何圖表工作的最終目標。
從需求開始。定義範圍。選擇符合需求的工具。並精確地進行文件記錄。這種有紀律的方法能帶來更好的系統,並減少誤解。