UML帶有數據流程圖的客戶服務系統案例研究

Visual Paradigm是包含設計共享、線框圖和數據庫設計新特性的企業項目設計工具。如今你只須要這樣單獨的一款模型軟件 Visual Paradigm就能夠完成用UML設計軟件，用BPMN去執行業務流程分析，用ERD企業設計數據庫的任務。Visual Paradigm年終鉅惠來襲，Visual Paradigm Modeler 訂閱1年只需666元，如今搶購立享優惠！

慧都網免費點擊下載Visual Paradigm最新試用版

數據流圖（DFD）提供了系統內信息（即數據）流的直觀表示。經過建立數據流程圖，您能夠告訴參與系統流程的人員所提供並傳遞給其的信息，完成流程所需的信息以及須要存儲和訪問的信息。數據流程圖在軟件工程中被普遍使用。您能夠在建模信息系統中使用DFD。本文以客戶服務系統爲例介紹和解釋數據流程圖（DFD）。

CS系統示例

數據流程圖是圖的層次結構，包括：

1. 上下文圖（概念上爲零級）
2. 1級DFD
3. 以及可能的2級DFD和進一步的功能分解，具體取決於系統的複雜性

   上下文DFD

   下圖顯示了爲鐵路公司的客戶服務系統繪製的上下文數據流程圖。它包含一個表示要建模的系統的過程（形狀），在本例中爲「 CS System 」。它還顯示了將與系統交互的參與者，稱爲外部實體。在此示例中，CS Assistant和Passenger是將與系統交互的兩個實體。在流程與外部實體之間，存在數據流（鏈接器），這些數據流指示實體與系統之間存在信息交換。
   
   上下文DFD是數據流模型的入口。它僅包含一個進程，而且不顯示任何數據存儲。

   1級DFD

下圖顯示了1級DFD，它是上下文DFD中顯示的CS系統過程的分解（即分解）。通讀該圖，而後咱們將基於此圖介紹一些關鍵概念。

CS系統數據流程圖示例包含四個流程，兩個外部實體和四個數據存儲。儘管沒有設計準則能夠控制形狀在數據流程圖中的位置，可是咱們傾向於將過程放在中間，而將數據存儲區和外部實體放在側面，以便於理解。

根據該圖，咱們知道乘客能夠從「查詢運輸詳細信息」流程中接收運輸詳細信息，而且詳細信息由數據存儲「運輸詳細信息」和「鐵路實時統計」提供。雖然存儲在「運輸詳細信息」中的數據是永久性數據（用標籤「 D」表示），可是「鐵路實時統計」中存儲的數據是短暫的瞬態數據（用標籤「 T」表示）。標註形狀用於列出乘客能夠查詢的詳細信息的種類。
CS Assistant能夠啓動「購買記念品」流程，這將致使將訂單詳細信息存儲在「訂單」數據存儲區中。儘管客戶是購買記念品的真實人，但CS助手能夠訪問存儲訂單明細的系統。所以，咱們使數據從CS助手流向購買記念品流程。

CS Assistant還能夠經過提供訂單明細來啓動「購買憑單」流程，該詳細信息將再次存儲在「訂單」數據存儲區中。數據流圖是一個高度抽象的高級圖。此處繪製的數據存儲Order不必定表示真實的訂單數據庫或數據庫中的訂單表。訂單詳細信息的物理存儲方式將在之後實現系統時肯定。

最後，CS Assistant能夠經過提供事件和項目詳細信息來啓動「報告丟失」過程，而且該信息將存儲在「丟失的項目」數據庫中。

數據流程圖提示和注意事項

用D，M和T聲明數據類型

數據流程圖中繪製的每一個數據存儲都以字母爲前綴，默認狀況下爲「 D」。該字母表示數據存儲區保存的數據類型。字母「 D」用於表示持久的計算機化數據，這多是典型信息系統中最多見的數據類型。除了計算機化數據外，數據還能夠暫時保留一小段時間。咱們稱這種數據爲暫態數據，用字母「 T」表示。有時，無需使用計算機便可存儲數據。咱們稱這種數據爲手動數據，用字母「 M」表示。最後，若是數據是在不使用計算機的狀況下存儲的，而且也保留了很短的時間，則稱爲手動瞬態數據，並由T（M）表示。

注意細節級別

在此數據流程圖示例中，標記數據時，屢次使用「詳細信息」一詞。咱們有「運輸詳細信息」和「訂單詳細信息」。若是咱們將其明確寫爲「路線信息，火車時間和延誤」，「記念品名稱，數量和數量」以及「機票類型和數量」怎麼辦？它是否正確？好吧，這個問題沒有肯定的答案，可是在作出決定時嘗試問本身一個問題。爲何要繪製DFD？

在大多數狀況下，數據流程圖是在系統開發的早期階段繪製的，其中許多細節尚待確認。諸如「詳細信息」，「信息」，「憑證」之類的通用術語的使用無疑爲討論留下了空間。可是，使用通用術語可能會缺少細節，從而使設計失去其用處。所以，這實際上取決於您的設計目的。

不要透支

在數據流程圖中，咱們專一於系統與外部各方之間的交互，而不是接口之間的內部通訊。所以，接口與所使用的數據存儲之間的數據流被認爲是超出範圍的，所以不該在圖中顯示。

不要混淆數據流和流程流

一些設計人員在遇到從數據存儲鏈接到流程的鏈接器時可能會感到不舒服，而沒有在圖表上顯示指定數據請求的步驟。一些設計人員將嘗試將請求附加到流程和數據存儲之間的鏈接器，將其標記爲「請求」或「對某物的請求」，這確定是沒必要要的。

請記住，數據流程圖是爲表示信息交換而設計的。數據流程圖中的鏈接器用於表示數據，而不用於表示過程流，步驟或其餘任何內容。當咱們將以數據存儲結尾的數據流標記爲「請求」時，從字面上看，這意味着咱們正在將請求做爲數據傳遞到數據存儲中。儘管在實現級別多是這種狀況，由於某些DBMS確實支持使用函數，這些函數會吸取一些值做爲參數並返回結果，可是，在數據流程圖中，咱們傾向於將數據存儲視爲惟一的數據持有人沒有任何處理能力。若是要對系統流或流程進行建模，則可使用「活動圖」或「 BPMN業務流程圖」代替。若是要對數據存儲的內部結構建模，可使用Entity Relationship Diagram。

想要購買Visual Paradigm正版受權請點擊【商城購買】，想了解更多產品信息請點擊【諮詢在線客服】

本文章轉載自【慧都科技】evget歡迎任何形式的轉載，但請務必註明出處、不得修改原文相關連接，尊重他人勞動成果