理解資訊如何在系統中流動，對於建立穩健的軟體與高效的業務流程至關重要。資料流程圖（DFD）提供了這種流動的視覺化表示。它們描繪了資料從外部來源到內部流程的流動路徑，顯示資料儲存的位置以及如何被轉換。然而，僅繪製單一圖表很少能捕捉現代系統的複雜性。這正是第0、1、2級DFD層級結構變得至關重要的原因。
在適當的時機選擇合適的細節層級，可避免在需求收集與系統設計過程中產生混淆。本指南探討每一級別的具體應用、組成部分與規則。我們將分析何時應停止對流程進行進一步分解，以及如何在文件中保持一致性。
🔍 什麼是資料流程圖？
資料流程圖是一種以圖形方式呈現資料在資訊系統中流動的表示法。與專注於控制流程與邏輯判斷的流程圖不同，DFD專注於資料的移動。它幫助利害關係人視覺化輸入如何轉換為輸出。
- 流程： 一種轉換資料的動作。
- 資料儲存： 資料暫時存放以供後續使用的位置。
- 外部實體： 系統邊界以外的來源或目的地。
- 資料流： 這些元件之間資料的移動。
透過將系統分解為特定層級，分析師可以管理複雜性。您無需在第一張圖表中顯示每一筆交易的詳細資訊。相反地，您應從較廣泛的層面開始，並根據需要逐步細化。
🌍 第0級：情境圖 🌍
第0級DFD通常稱為情境圖。它將整個系統表示為單一流程。這種高階視圖確立了系統與其環境之間的界線。
🎯 何時使用第0級
- 需求收集： 在早期使用，以與利害關係人確認範圍。
- 專案啟動： 為新成員提供快速的整體概覽。
- 系統邊界定義： 清楚地定義系統內部與外部的內容。
⚙️ 關鍵組成部分
- 一個流程節點： 整個系統由一個圓形或圓角矩形表示。通常會以系統名稱標示（例如：「訂單處理系統」）。
- 外部實體： 這些是與您的系統互動的人、組織或其他系統。範例包括「客戶」、「付款網關」或「倉儲管理系統」。
- 注意：如果內部部門屬於同一系統範圍，則不應將其列為外部實體。
- 資料流： 箭頭顯示實體與中央流程之間的輸入和輸出。
📝 範例情境
考慮一個圖書館管理系統。Level 0 圖表會顯示中央的「圖書館系統」流程。外部實體包括「圖書館員」、「會員」和「書籍供應商」。資料流包括來自供應商的「新書請求」以及來自會員的「圖書借閱」。
此層級回答的問題是：「這個系統是什麼，誰在與它互動？」
🔄 Level 1：高階流程地圖 🔄
Level 1 DFD 將 Level 0 中的單一流程擴展為主要的子流程。它揭示了系統的內部運作機制，而不陷入細節之中。這通常是高階架構討論中最重要的一張圖表。
🎯 何時使用 Level 1
- 系統設計階段： 開發人員需要了解主要模組。
- 功能規劃： 產品經理利用此圖來識別不同的功能區域。
- 接口定義： 協助識別資料進入和離開系統的位置，以定義 API。
⚙️ 關鍵組件
- 主要流程： 將單一的 Level 0 流程分解為 5 到 9 個不同的流程。如果數量更多，則考慮進一步分組。
- 資料儲存： Level 1 是通常引入資料儲存（資料庫、檔案、表格）的地方。這顯示了資訊持久化的位置。
- 一致性： Level 0 中進入或離開系統的每一筆資料流都必須出現在 Level 1 中。這稱為平衡.
📝 範例情境
繼續以圖書館系統為例，Level 1 圖表將「圖書館系統」拆分為「註冊會員」、「借閱圖書」、「處理罰款」和「管理庫存」。資料儲存可能包括「會員資料庫」和「圖書目錄」。Level 0 中的「圖書借閱」流程在 Level 1 中拆分為與「會員資料庫」和「圖書目錄」互動的流程。
此層級回答的問題是：「主要功能是什麼，資料儲存在哪裡？」
🔬 Level 2：詳細流程檢視 🔬
Level 2 DFD 深入探討 Level 1 中識別出的特定流程。單一的 Level 1 流程可能過於複雜，無法完全理解，因此需要進一步分解。並非每個流程都需要 Level 2 圖表；只有那些需要詳細規格說明的流程才需要。
🎯 何時使用 Level 2
- 詳細規格： 在為開發人員撰寫技術需求時使用。
- 複雜邏輯： 涉及多個決策點或計算的流程。
- 舊系統現代化： 將現有的複雜工作流程映射到新系統。
⚙️ 關鍵組件
- 子流程： 第一級流程的分解。例如，“借書”會分解為“驗證會員資格”、“更新庫存”和“生成收據”。
- 限制子流程數量，以避免混亂。
- 輸入/輸出細節： 明確顯示這些子流程之間傳遞的資料元素。
- 控制邏輯： 雖然資料流程圖不會像程式碼一樣顯示邏輯，但第二級通常會暗示決策點（例如，“若會員有效，則繼續”）。
📝 範例情境
在圖書館範例中，第一級的「處理罰款」流程被進一步分解。可能顯示「計算逾期天數」、「套用費率」和「更新帳戶餘額」。此層級確保罰款計算邏輯清晰且符合業務規則。
此層級回答的問題是：「這個特定功能究竟是如何運作的？」
📊 資料流程圖層級比較
| 功能 | 第0層（上下文） | 第一層（高階） | 第二層（詳細） |
|---|---|---|---|
| 範圍 | 整個系統 | 主要子系統 | 特定流程 |
| 流程數量 | 1 | 5到9個 | 變數（深入探討） |
| 資料儲存 | 無 | 主要儲存 | 詳細儲存 |
| 受眾 | 利害關係人、高階主管 | 架構師、經理 | 開發人員、分析師 |
| 時機 | 需求階段 | 設計階段 | 實作階段 |
| 重點 | 邊界 | 功能 | 邏輯與資料 |
🛠️ DFD 建模的最佳實務
建立精確的圖表需要紀律。遵守特定規則可確保您的文件在專案生命週期中始終具有實用價值。
1. 維持平衡
當您將 Level 0 的流程分解至 Level 1 時，輸入與輸出必須相符。若 Level 0 显示「使用者登入請求」進入系統，Level 1 必須顯示相同資料進入「驗證流程」。若資料無故消失或憑空出現，則圖表無效。
2. 命名慣例
- 流程： 使用動詞-名詞結構（例如「驗證訂單」，而非「訂單驗證」）。這強調動作性。
- 資料流： 使用名詞片語（例如「客戶資料」、「發票」）。
- 實體： 使用單數名詞（例如「客戶」，而非「客戶們」）。
3. 避免資料亂線
不要過度繪製相互交叉的資料流。若圖表變成一片線條網狀，表示可能過於複雜。建議將 Level 1 的流程拆分為獨立的圖表。
4. 無交叉通訊
外部實體不應直接相互通訊。所有通訊必須經過系統流程。如果「倉庫」將資料傳送給「計費系統」，則必須經過「訂單處理」流程。
5. 限制資料儲存
過多的資料儲存會讓讀者感到混淆。僅包含當前細節層級所必需的儲存位置。如果某個儲存僅在第2層使用，可能不需要出現在第1層。
🚫 應避免的常見錯誤
即使是經驗豐富的分析師也會犯錯。及早識別這些錯誤，可節省審查過程中的時間。
- 黑洞： 一個沒有輸出的流程。這表示資料正在消失，而在一個正常運作的系統中，這在邏輯上是不可能的。
- 奇蹟： 一個沒有輸入的流程。資料無法從無中產生。
- 灰洞： 一個具有輸入但產生的輸出與根據輸入所預期的結果不同的流程。這通常表示缺少邏輯。
- 過早過於詳細： 在第1層尚未獲得批准前就繪製第2層圖表，會導致重做。應遵循層級結構。
- 忽略資料儲存： 忽略資料儲存位置，會讓系統看起來是暫時性的且不可靠。
📋 實施策略
應如何為新專案建立這些圖表？請遵循此結構化的工作流程。
第一階段：範圍定義
從第0層圖表開始。識別系統名稱及所有外部實體。目前無需擔心內部流程。取得專案贊助者的同意，確認系統邊界。
第二階段：功能分解
建立第1層圖表。識別主要流程。確保所有資料儲存都已定義。確認第0層的資料流在此處存在。這正是系統架構成形之處。
第三階段：詳細邏輯
從第1層中選擇需要釐清的複雜流程。為這些特定區域建立第2層圖表。可用於開發人員交接及單元測試規格。
第四階段：維護
DFD並非靜態的。當系統變更時，應更新圖表。一份過時的DFD甚至比沒有DFD更糟糕。建立規則：每次發行週期都必須更新圖表。
🤝 與其他技術的整合
DFD並非孤立存在。當與其他建模方法結合時，效果最佳。
- 實體-關係圖（ERD）： DFD顯示資料流動；ERD顯示結構。使用ERD來定義DFD中所顯示的資料儲存。
- 使用案例圖： 使用案例圖專注於使用者互動。資料流程圖專注於資料。它們在需求文件中相互補充。
- 順序圖： 順序圖顯示時間順序。資料流程圖顯示結構。使用順序圖來釐清第二層流程中資料流的時間關係。
📝 使用總結
選擇正確的資料流程圖層級取決於目標讀者與文件的目的。
- 使用第0層 用來定義邊界與範圍。
- 使用第1層 用來定義架構與主要功能。
- 使用第2層 用來定義邏輯與實作細節。
透過嚴格遵守分解與平衡的規則，您將建立系統開發的清晰路徑圖。這種清晰性可減少商業利益相關者與技術團隊之間的誤解。請記住，目標不僅是繪製圖表，更要確保對資料如何支援業務有共識。
花時間確保層級結構正確。一組結構良好的資料流程圖，將在任何軟體專案的開發與維護階段帶來回報。