功能模型核心定位
著重系統內部資料傳遞與處理，定義「輸入經運算轉換為輸出」的映射關係，不考慮執行時序 (時序屬動態模型)。
資料流圖 (DFD) 核心元素
| 符號 | 名稱 | 說明 | 範例 |
|---|
| ▭ | 外部實體 | 系統邊界外的資料來源/目的地 | 客戶、供應商、銀行、監管機構 |
| ○ / ⬟ | 處理序 | 資料轉換邏輯、業務規則執行 | 計算稅額、驗證訂單、生成報表 |
| ━━━━━━ | 資料儲存 | 靜態資料保持、供後續存取 | 客戶主檔、產品目錄、訂單歷史 |
| → | 資料流 | 資料在元素間移動、攜帶資訊 | 訂單明細、付款確認、庫存扣減 |
DFD 分層分解架構
- 第 0 層 (上下文圖)：單一處理序代表整個系統，展示與外部實體的資料流。
- 第 1 層：將系統分解為 3-7 個主要子系統/處理序 (避免過多)。
- 第 2 層...：逐層細化，直到處理序邏輯可用簡單敘述/伪代碼描述 (原子處理序)。
- 每層處理序編號承襲上層 (如 1.0 → 1.1, 1.2, 1.3)。
建立功能模型 5 步驟
- 確定輸入與輸出值：識別外部實體提供/接收的資料項、格式、頻率、品質要求。
- 用 DFD 表示功能依賴性：繪製分層 DFD，確保資料流平衡 (輸入 = 輸出 + 儲存變化)。
- 具體描述每個功能：為每個原子處理序撰寫處理規範 — 演算法、業務規則、前置/後置條件、例外處理、效能指標。
- 確定限制：資料完整性約束 (PK/FK/唯一/檢查)、業務規則 (不可違反不變條件)、技術約束 (延遲/吞吐/可用性)。
- 確定功能優化準則：最小化處理時間、最大化吞吐量、最小化資料冗餘、最小化儲存成本、最大化資料品質。
功能模型與物件模型的關係
| 功能模型元素 | 對應物件模型元素 | 備註 |
|---|
| 處理序 | 類別操作 / 服務方法 | 一個處理序可能對應多個操作 |
| 資料儲存 | 實體類別 / Repository / 資料庫表 | DFD 儲存較抽象，物件模型更細緻 |
| 資料流 | 參數 / 回傳值 / 事件承載 / DTO | 資料流項目 → 類別屬性/建構子參數 |
| 外部實體 | 介面 / Actor / 外部系統整合點 | 介面契約定義資料流格式 |
常見建模錯誤
| 錯誤 | 徵兆 | 修正 |
|---|
| 控制流混入資料流 | DFD 出現「啟動信號」「完成旗標」資料流 | 控制邏輯移至動態模型 (狀態圖/序列圖) |
| 處理序過度細分 | 超過 7 個子處理序、層次超過 5 層 | 合併同質處理序、調整分解粒度 |
| 資料流不平衡 | 子圖輸入/輸出與父圖資料流不匹配 | 嚴格遵守資料流平衡原則 (輸入 = 輸出 + Δ儲存) |
| 忽略資料約束 | DFD 無標註唯一性/參考完整性/值域 | 在資料儲存/資料流旁標註約束或連結資料字典 |
現代替代技術
- 用例圖 + 活動圖 (UML)：更強調使用者目標與業務流程。
- BPMN 2.0：業務流程建模標準，支援執行引擎 (Camunda/Flowable)。
- 事件風暴 (Event Storming)：工作坊快速建立領域事件流、命令、聚合。
- C4 模型：容器/元件/程式碼層級架構視圖，替代傳統 DFD 分層。
