Visual Paradigm教程：數據流程圖示例-食品訂購系統

Visual Paradigm是包含設計共享、線框圖和數據庫設計新特性的企業項目設計工具。Visual Paradigm公司在其核心產品Visual Paradigm for UML更新到v11.1的時候，把三個原始的系列產品（Agilian、Visual Paradigm for UML和Logizian）融合在一起，將最初為不同建模功能服務的多個獨立產品整合成的一個產品，其名字被命名為Visual Paradigm——與公司的名字相同。現在你只需要這樣單獨的一款模型軟件 Visual Paradigm就可以完成用UML設計軟件，用BPMN去執行業務流程分析，用ERD企業設計數據庫的任務。

Visual Paradigm現已更新至最新版本16.0，新版本引入了大型Scrum畫布和幾十種新的圖案，同時還增強了在線圖表功能和支持從Customer Journey Map打開完整圖表編輯器的功能。新版本，新功能，趕快下載體驗吧！（Visual Paradigm現已加入在線訂購，現在搶購立享優惠！）

點擊下載Visual Paradigm最新版

數據流圖（DFD）提供系統內信息流（即數據）的直觀表示。通過繪制數據流圖，您可以告知參與系統流程的人員提供的信息，交付給完成流程所需的信息以及需要存儲和訪問的信息。本文通過使用食品訂購系統作為示例來描述和解釋數據流程圖（DFD）。

食品訂購系統示例

上下文DFD

上下文關系圖是僅顯示頂級的數據流圖，也稱為級別0.在此級別，只有一個可見的流程節點表示完整系統與外部實體交互方式的功能。Context Diagram的一些好處是：

1. 顯示系統邊界的概述

2. 使用簡單的符號無需技術知識即可理解

3. 簡單的繪制，修改和詳細說明作為其有限的表示法

下圖顯示了為食品訂購系統繪制的上下文數據流圖。它包含一個表示要建模的系統的過程（形狀），在本例中是“ 食品訂購系統 ”。它還顯示將與系統交互的參與者，稱為外部實體。在此示例中，供應商，廚房，經理和客戶是將與系統交互的實體。在進程和外部實體之間，存在指示實體和系統之間信息交換的存在的數據流（連接器）。

上下文DFD是數據流模型的入口。它包含一個且僅包含一個進程，并且不顯示任何數據存儲。

1級DFD

下圖顯示了1級DFD，它是上下文DFD中顯示的食品訂購系統流程的分解（即分解）。閱讀圖表，然后我們將介紹基于該圖表的一些關鍵概念。

食品訂單系統數據流程圖示例包含三個過程，四個外部實體和兩個數據存儲。

根據該圖表，我們知道客戶可以下訂單。在點菜過程接收訂單，將其轉發給廚房，將其存儲在訂單數據存儲和存儲更新庫存信息的庫存數據存儲。該過程還提供一個法案給客戶。

經理可以通過生成報告流程接收報告，該流程分別將庫存詳細信息和訂單作為庫存和訂單數據存儲的輸入。

經理還可以通過提供庫存訂單來啟動訂單庫存流程。該流程將庫存訂單轉發給供應商，并將更新的庫存明細存儲在庫存數據存儲中。

數據流圖提示和注意事項

提示

1. 流程標簽應該是動詞短語; 數據存儲由名詞表示

2. 數據存儲必須至少與進程相關聯

3. 外部實體必須至少與進程相關聯

4. 不要讓它太復雜; 通常5-7個普通人可以管理流程

5. DFD是非確定性的 - 編號不一定表示序列，它在與用戶討論時識別過程很有用

6. 數據存儲不應連接到外部實體，否則，這意味著您要讓外部實體直接訪問您的數據文件

7. 不經過一個過程，兩個外部實體之間不應存在數據流

8. 具有輸入但沒有輸出的過程被認為是黑洞過程

注意事項

不要混淆數據流和流程

當看到從數據存儲連接到進程的連接器時，某些設計人員可能會感到不舒服，而不會看到圖表上以某種方式顯示數據請求的步驟。其中一些將嘗試通過在進程和數據存儲之間添加連接器來表示請求，將其標記為“請求”或“請求某事”，這是錯誤的。

請記住，數據流圖是為表示信息交換而設計的。數據流圖中的連接器用于表示數據，而不是用于表示流程，步驟或其他任何內容。當我們標記以數據存儲“請求”結束的數據流時，這實際上意味著我們將請求作為數據傳遞到數據存儲中。雖然這可能是實現級別的情況，因為一些DBMS確實支持使用函數，這些函數將一些值作為參數并返回結果，但在數據流圖中，我們傾向于將數據存儲視為唯一的數據存儲庫。沒有任何處理能力。如果要對系統流程或流程流建模，請使用UML活動圖或BPMN業務流程圖代替。如果要對數據存儲的內部結構建模，請使用實體關系圖。

=====================================================

更多Visual Paradigm相關資源，請點擊此處進行查看~

想要購買Visual Paradigm正版授權的朋友可以。