數據流圖（通常簡稱為DFD）是系統分析與設計中的一項關鍵視覺工具。它用於描繪資訊在系統中的流動過程，展示數據如何從輸入流向輸出。與專注於控制邏輯的流程圖不同，DFD專注於數據本身的移動。這一區別對需要理解系統本質而無需陷入執行時間或條件細節的架構師和分析師而言至關重要。
創建DFD需要採用結構化的方法。這不僅僅是畫出形狀，更在於建模流程的邏輯與資料完整性。無論您是設計新的軟體應用程式、審核現有的工作流程，還是繪製業務流程，一個構建良好的圖表都能提供清晰的視覺呈現。它幫助利益相關者理解系統的邊界，並識別資料的來源與儲存位置。
理解核心組件 🧩
在繪製線條與方框之前，必須先理解基本的構建模塊。每個DFD都包含四個主要元素。識別這些組件可確保圖表保持一致且易於閱讀。
- 外部實體： 這些是資料的來源或目的地。它們位於系統邊界之外。實體可以是使用者、另一個系統或組織。在圖表中，通常以方形或圓形表示。
- 處理過程： 這就是動作發生的地方。處理過程將輸入資料轉換為輸出資料。它們代表對資料所執行的工作。一個處理過程必須至少有一個輸入和一個輸出。通常以圓角矩形或圓形繪製。
- 資料儲存： 這些代表資料被儲存以供後續使用的地點。它可以是實體資料庫、檔案櫃，甚至是電子郵件收件匣。它們不會主動啟動動作，僅用來儲存資訊。資料儲存通常以開口矩形或平行線表示。
- 資料流： 這些是連接各組件的箭頭。它們顯示資料移動的方向。每個箭頭都必須標註所傳輸資料的名稱。
需要注意的是，資料不能在沒有處理過程介入的情況下直接從一個實體傳送到另一個實體，也不能在沒有處理過程的情況下從資料儲存傳送到實體。這些規則確保了模型的邏輯完整性。
選擇符號風格 🖊️
繪製DFD主要有兩種主要方法。雖然它們具有相同的邏輯基礎，但視覺表現方式有所不同。選擇合適的一種取決於團隊的偏好或特定行業標準。
| 功能 | Yourdon與DeMarco | Gane與Sarson |
|---|---|---|
| 處理過程 | 圓角圓形 | 圓角矩形 |
| 資料儲存 | 開口矩形 | 側邊較粗的開口矩形 |
| 資料流 | 曲線箭頭 | 曲線箭頭 |
| 外部實體 | 矩形 | 矩形 |
Yourdon 與 DeMarco 風格通常與較舊的系統方法學相關，而 Gane 與 Sarson 則廣泛應用於現代結構化分析。無論選擇何種形狀，一致性至關重要。在單一文件中混合使用不同風格可能會讓讀者感到困惑。
定義系統邊界 🚧
建立圖表的第一步是定義範圍。您必須確定系統內部與外部的內容。這通常透過建立「上下文圖」（也稱為 Level 0 DFD）來完成。
上下文圖將整個系統表示為單一處理程序。它顯示系統與外部實體之間的高階互動。這提供了系統進出資料的鳥瞰視角。繪製此圖時，僅需關注輸入與輸出。目前無需詳細描述內部流程。
例如，考慮一個圖書館系統。系統即為單一圓圈。外部實體可能包括「圖書館員」與「會員」。資料流可能包括「借書請求」進入系統，以及「借閱憑證」離開系統。這種簡化的視圖為後續更詳細的分解奠定了基礎。
分解處理流程 🔄
一旦上下文建立後，系統就需要被分解。此過程稱為「分解」。它涉及將上下文圖中的單一處理程序擴展為多個子處理程序，從而形成 Level 1 DFD。
分解過程需謹慎進行。您不能隨意添加處理程序。每個子處理程序必須處理特定的資料轉換。若資料流進入某子處理程序，則必須產生明確的輸出。若資料被儲存，則必須與資料儲存區相連接。
分解的關鍵步驟
- 識別子處理程序： 觀察主要處理程序。它執行哪些明確的任務？將這些任務拆分為獨立的圓圈或矩形。
- 連結資料儲存區： 確定資訊儲存的位置。若某項任務更新記錄，則繪製資料流至資料儲存區。
- 優化資料流： 確保每一條箭頭都標示清楚。標籤應描述資料內容，而非動作。例如，應使用「客戶訂單」而非「傳送訂單」。
- 檢查一致性： 確保 Level 1 圖表中的資料流與 Level 0 圖表中父處理程序的輸入與輸出相符。
此過程可持續進行。若 Level 1 的處理程序過於複雜，可進一步分解為 Level 2 DFD。這種遞迴式分解使分析師能在不喪失整體脈絡的情況下，專注於特定關注區域。
繪製與平衡的規則 ⚖️
DFD 建構有嚴格的規則。違反這些規則將導致圖表無效。最重要概念是「平衡」。
平衡意指父處理程序的輸入與輸出，必須與其子處理程序的輸入與輸出一致。若 Level 0 的處理程序有一個輸入為「訂單」，則 Level 1 圖表必須顯示相同的「訂單」資料進入某個子處理程序。除非是邏輯細節，否則不允許在較低層級引入高層級未出現的新資料。
額外的繪製規則
- 實體之間不得有資料流： 資料必須經過處理程序。不能直接從一個外部實體傳送到另一個外部實體。
- 資料儲存區之間不得有資料流： 資料儲存區儲存靜態資料。它們之間的移動必須透過處理程序來轉換或移動資料。
- 資料儲存區不得在無處理程序的情況下接收或輸出資料： 儲存區無法自行產生或接收資料。必須由處理程序控制互動。
- 處理程序命名： 使用動詞與名詞命名處理程序。這能明確表達動作，例如「計算稅額」或「更新庫存」。
- 資料流命名： 使用名詞片語命名資料流。這能明確說明內容，例如「發票細節」或「付款確認」。
審查與優化 🧐
圖表草圖完成後，審查階段至關重要。這包括檢查錯誤、遺漏與清晰度問題。利益相關者應審查圖表，以確保其符合他們對系統的心理模型。
在此階段，應尋找懸空的資料流。這些是沒有終點的箭頭。每條資料流都必須連接到處理程序、儲存區或實體。同時檢查線條是否交叉。雖然並非嚴格禁止，但交叉線條可能使圖表難以閱讀。應嘗試規劃線路以避免交叉。
審查的另一個面向是命名規範。確保圖表中同一資料始終使用相同名稱。若某處稱為「客戶編號」，則其他處不得稱為「客戶代碼」。一致性有助於理解。
隨時間維護 🛠️
DFD 不是一次性產物。系統會演進，需求也會改變。隨著系統的變動，圖表必須更新以反映新的現實。過時的圖表比沒有圖表更糟糕，因為它會誤導開發人員和分析師。
為你的圖表建立版本控制系統。當發生重大變更時，更新版本號碼。這有助於追蹤系統設計的歷史。同時也讓新成員能理解系統是如何發展的。
與系統分析整合 📋
DFD 很少單獨使用。它們是更大文件套件的一部分。它們經常與資料字典和流程規格一同出現。資料字典定義了圖表中所見資料元素的屬性。流程規格則詳細說明特定流程泡泡內的邏輯。
透過結合這些文件，你可以建立一份完整的規格說明。這些文件支援開發團隊建構系統。確保最終產品與最初的分析一致。
圖示化實務的結論
建立資料流程圖是一項有紀律的溝通練習。它將抽象的需求轉化為較易理解的視覺格式。透過遵守標準元件、符號風格與平衡規則，確保圖表能有效達成其目的。
請記住，目標是清晰。如果利益相關者觀看圖表後能理解系統，那麼圖表就成功了。如果需要額外解釋，而這些解釋與圖形本身矛盾，則圖表需要修訂。專注於資訊的流動，保持符號的一致性，並確保範圍明確。經過練習，建立準確且實用的資料流程圖，將自然成為系統設計過程的一部分。