在建模複雜系統時，清晰性是首要目標。資料流程圖（DFD）是一種基礎工具，用於視覺化資訊如何在系統中流動。在此架構中，有兩個符號佔據主導地位：流程 以及 資料儲存。儘管它們經常互動，但這兩者代表了關於轉換與持久性截然不同的概念。理解這項區別對於準確的系統分析與設計至關重要。
本指南探討這些元素的功能角色、視覺呈現與邏輯含義。透過區分動作與儲存，分析人員可以建立清晰傳達系統行為的圖表，避免歧義。
🔄 定義流程
流程代表一項工作單元或轉換。這是資料改變形式、被計算或被過濾的地方。將流程視為一個黑箱。你知道什麼進來、什麼出去，但內部機制是由轉換邏輯本身定義，而非由資訊的儲存方式決定。
🔹 核心特性
- 轉換：主要功能是修改資料。輸入資料進入，套用規則或邏輯，輸出資料離開。
- 時間性質：流程僅在觸發時才會活躍。它們在執行之間不會保留資料。
- 方向性：資料流入並流出流程。在DFD架構中，沒有輸入或輸出的流程在邏輯上是無效的。
- 動詞命名： 流程通常以動詞或動詞片語標示（例如，計算稅額, 驗證使用者, 產生報表).
🔹 黑箱概念
在高階建模中，流程是一個黑箱。重點在於什麼發生在資料上的事情，而非如何技術上如何發生。例如，名為「處理訂單」的流程會接收訂單細節並建立交易記錄。它不會說明計算是在記憶體中、磁碟上，還是透過遠端API進行。這種抽象讓利害關係人能專注於商業邏輯，而非技術實作。
然而，隨著圖表分解到較低層級，內部邏輯會變得更詳細。即便如此，流程仍是一個主動的轉換引擎。它消耗輸入、執行工作並產生輸出。它不會作為資訊的暫存容器。
🗄️ 定義資料儲存
資料儲存體代表一個資訊存放的儲藏庫。與處理程序不同，資料儲存體不會轉換資料。它只是等待。它會以持久狀態保存資料，直到有處理程序取得資料，或有處理程序將資料存入其中。
🔹 核心特性
- 持久性： 資料即使在沒有任何處理程序運作時仍會保留在儲存體中。這與記憶體緩衝區或暫時變數的關鍵差異。
- 被動性： 資料儲存體不會主動啟動動作。它們需要由處理程序來讀取或寫入。
- 名詞命名： 儲存體通常以名詞命名（例如，客戶資料庫, 訂單檔案, 庫存日誌).
- 開放式： 資料流可以進入和離開儲存體。然而，儲存體無法直接連接到另一個儲存體。資料必須透過處理程序才能在不同儲存庫之間移動。
🔹 儲存庫概念
想像一個圖書館。書籍就是資料。書架就是資料儲存體。圖書館員就是處理程序。圖書館員並不會創造書籍；他們負責整理書籍。書架本身不會移動書籍；它們只是將書籍固定在原位。當讀者請求一本書時，圖書館員會將其取出（讀取操作）。當一本新書到達時，圖書館員會將其放置在書架上（寫入操作）。
在系統架構中，資料儲存體可能代表資料庫表格、平面檔案、佇列或雲端儲存桶。DFD 符號抽象了技術細節。無論是 SQL 表格還是簡單的文字檔案，其邏輯角色都相同：它是一個資訊存放的位置。
⚡ 互動與資料流
處理程序與資料儲存體之間的關係受到嚴格的資料流規則所規範。DFD 中的箭頭代表資料的移動。這些箭頭決定了資訊傳輸的方向。
🔹 讀寫循環
當處理程序需要資訊時，會從資料儲存體畫出一個箭頭指向處理程序。這表示讀取操作。處理程序會提取資料，用於其轉換邏輯。相反地，當處理程序產生新資訊時，會從處理程序畫出一個箭頭指向資料儲存體。這表示寫入操作。資料現在已被儲存，以供未來使用。
關鍵的是，資料流無法直接連接兩個資料儲存體。資訊無法在未經處理的情況下從一個儲存庫遷移至另一個儲存庫。此規則強調了資料移動總是伴隨著某種層級的邏輯或控制，即使該邏輯僅為簡單的複製操作。
🔹 外部實體
外部實體（來源或接收端）與處理程序互動，而非直接與資料儲存體互動。外部實體可能是一個人類使用者、第三方 API 或另一個系統。它們會將資料傳送給處理程序，或從處理程序接收資料。處理程序隨後決定是否將該資料儲存在儲存庫中，或予以丟棄。
📋 比較表格
為了總結結構上的差異，請考慮以下屬性的分解。
| 屬性 | 處理程序 | 資料儲存體 |
|---|---|---|
| 功能 | 轉換 / 行動 | 儲存 / 記憶體 |
| 語法 | 動詞（例如：更新） | 名詞（例如：使用者表格） |
| 活動 | 主動（觸發時執行） | 被動（等待存取時才運作） |
| 資料保留 | 暫時（執行期間） | 持久（長期） |
| 連接性 | 連接至實體、儲存空間及其他流程 | 僅連接至流程 |
| 符號形狀 | 圓角矩形或圓形 | 開放矩形或平行線 |
🧩 命名慣例
命名的一致性可避免在審查與實作階段產生混淆。當同一個詞被用於儲存與動作時，常會產生歧義。
🔹 流程命名
名稱應描述對資料所執行的動作。避免使用「做它」或「處理」等通用名稱。應使用具體的描述詞。例如，「驗證登入憑證」比「檢查登入」更佳。這種清晰性可幫助開發人員立即理解預期的輸入與輸出需求。
🔹 資料儲存命名
名稱應反映內部所儲存的內容。使用複數名詞或明確的識別符。例如「Orders」暗示一組訂單記錄的集合；「Order」可能暗示單一交易實例。雖然語境很重要，但複數名詞通常表示包含多筆記錄的儲存庫。
命名資料儲存時，應考慮範圍。稱為「Database」的儲存空間過於模糊。應使用「客戶資料庫」或「交易記錄」等更具體的名稱，以提供必要的語境。這種細緻程度有助於後續將圖示對應至實際的儲存結構。
🧪 分解與層級
DFD 是層級式的。高階圖示（上下文圖）將系統視為單一流程。隨著你將其分解為較低層級，流程與儲存之間的區別變得更加重要。
🔹 第 0 層與第 1 層
在上下文圖中，整個系統被視為一個流程。在第 0 層，此流程被分解為主要的子流程。在此引入資料儲存，以顯示主要資料元件的位置。在第 1 層及更下層，流程會進一步細化。
在分解過程中，確保資料儲存不會無謂地重複。若某個儲存在第 0 層存在，通常應延續至第 1 層，除非特定子流程需要暫時快取（這將是另一個不同的儲存）。各層之間的一致性可確保可追蹤性。
🔹 平衡
分解過程中的關鍵規則是「平衡」。父流程的輸入與輸出必須與下層圖示中子流程的輸入與輸出相符。資料儲存也必須對齊。若某個儲存在父圖中出現，子圖必須正確反映該資料流。若流程被拆分，資料流向該儲存的流動必須在拆分後仍保持完整。
⚠️ 應避免的邏輯錯誤
某些結構性錯誤可能會使圖表無效。及早識別這些錯誤，可在開發階段節省時間。
- 幽靈資料流： 一個流程若沒有資料流入卻有資料流出，這是不可能的。流程無法從無中生有地產生輸出。每一項輸出都必須來自輸入資料或儲存的資料。
- 直接儲存連接： 如前所述，儲存區不能直接連接到另一個儲存區。資料必須經過流程傳遞。這確保所有資料移動都是有意識且經過處理的。
- 孤立的流程： 一個沒有任何資料流入或流出的流程是孤立的。它不與系統互動，在資料流程圖中也沒有任何作用。
- 混淆實體與儲存區： 外部實體位於系統邊界之外。資料儲存區位於系統內部。不要將外部實體的符號放置在系統邊界內，彷彿它是一個資料庫。
🛠️ 實作上的影響
流程與儲存區之間的區別會影響系統的建構方式。流程對應到函數、方法或微服務。資料儲存區對應到資料表、檔案或物件儲存。
🔹 資料庫設計
在設計資料庫時，資料流程圖中的資料儲存區會成為資料結構的藍圖。資料流箭頭中的屬性定義了欄位。儲存區之間的關係（由流程中介）定義了外鍵或交易連結。
🔹 工作流程自動化
對於工作流程引擎而言，流程代表管道中的各個步驟。資料儲存區代表工作流程的狀態。流程可能更新儲存區中的狀態，以標示某項任務已完成。理解儲存區的被動性，可確保工作流程引擎在繼續前等待正確的狀態。
🔍 視覺表示標準
不同的方法論使用稍有不同的符號，但邏輯保持一致。
- DeMarco 與 Yourdon： 流程使用圓角矩形，資料儲存區使用開口矩形。
- Gane 與 Sarson： 流程使用圓角矩形，資料儲存區使用平行線。
無論選擇哪種符號表示法，語意意義都相同。流程是動作者；儲存區是持有者。在專案文件中保持一致性，比遵守特定標準更重要，只要團隊理解所選的規範即可。
🎯 角色總結
建立穩健的系統模型，需要在角色分配上保持紀律。流程是行動者，執行工作。資料儲存區是舞台，用來存放道具。沒有行動者，舞台就是空的；沒有舞台，行動者無處安放其成果。
透過維持轉換與儲存之間的明確區分，分析師能創造出不僅視覺上吸引人，而且邏輯上正確的圖表。這些圖表成為商業利益相關者與技術團隊之間的契約。它們定義了責任範圍與價值流動。
審查資料流程圖時，針對每個符號問兩個問題：「這是在執行工作嗎？」（流程）或「這是在儲存資訊嗎？」（儲存區）。如果答案不清晰，應重新調整標籤或連接方式。清晰度是系統建模的最終目標。
遵循這些原則，可確保所產生的架構具備可維護性、可擴展性與可理解性。區別看似簡單，但對系統完整性影響深遠。