假設一家工廠的采購部每天需要一張訂貨報表,報表按零件編號排序,表中列出所有需要再次訂貨的零件。對于每個需要再次訂貨的零件應該列出下述的數據:零件編號,零件名稱,訂貨數量,目前價格,主要供應者,次要供應者。零件入庫或出庫稱為事務,通過放在倉庫中的CRT終端把事務報告給訂貨系統。當某種零件的庫存數量少于庫存量臨界值時就應該再次訂貨。
數據流圖有4種成分:
1、源點和終點
2、處理
3、數據存儲
4、數據流
因此,第一步可以從問題描述中提取數據流圖的4種成分:
①首先考慮數據的源點和終點,從上面對系統的描述可以知道“采購部每天需要一張訂貨報表”,“通過放在倉庫中的CRT終端把事務報告給訂貨系統”,所以采購員是數據終點,而倉庫管理員是數據源點。
②接下來考慮處理,再次一次閱讀問題描述,“采購部需要報表”,顯然他們還沒有這種報表,因此必須有一個產生報表的處理。事務的后果是改變零件庫存量,然而任何改變數據的操作都是處理,因此對事物進行的加工是另一個處理。
③最后,考慮數據流和數據存儲:系統把訂單報表送給采購部,因此訂貨報表是一個數據流;事務需要從倉庫送到系統中,顯然事務是另一個數據流。產生報表和處理事務這兩個在時間上明顯不匹配———每當有一個事務發生時立即處理它,然而每天只產生一次訂貨報表。因此,用來產生訂貨報表的數據必須存放一段時間,也就是應該有應該數據存儲
組成數據流圖的元素可以從描述問題的信息中提取出來
源點/終點 | 處理 |
采購員 倉庫管理員 | 產生報表 處理事務 |
數據流 | 數據存儲 |
訂貨報表 ??? 零件編號 ??? 零件名稱 ??? 訂貨數量 ??? 目前價格 ??? 主要供應者 ??? 次要供應者 事務 ??? 零件編號 ??? 事務類型 ??? 數量 | 訂貨信息 庫存清單 ???? 零件編號 ???? 庫存量 ???? 庫存量臨界值 ? |
? | ? |
一旦把數據流圖的4種成分都分離出來以后,就可以畫數據流圖了,但是,怎樣開始畫呢?
注意:數據流圖是系統的邏輯模型,然而任何計算機系統實質上都是信息處理系統,也就是說計算機系統本質上都是把輸入數據變換成輸出數據。因此,任何系統的基本模型都是由若干數據源點/終點以及一個處理組成,這個處理就代表了系統對數據加工變換的基本功能。
?從基本系統模型這樣非常高的層次開始畫數據流圖是一個好辦法。在這個高層次的數據流圖上是否列出了所有給定的數據終點/源點一目了然,因此它是很有價值的通信工具。
然而,訂貨系統的基本系統模型圖畢竟太抽象,從這張圖對訂貨系統所能代表的信息非常有限。下一步應該把基本系統模型細化,描繪系統的主要功能。從信息表中可得,“產生報表”和“處理事務”是系統必須完成的兩個主要功能,它們將代替訂貨系統的基本系統模型圖中的訂貨系統,此外,細化后的數據流圖還增加了兩個數據存儲:處理事務需要“庫存清單“數據;產生報表和處理事務在不同時間進行,因此需要存儲”訂單信息“。除了訂貨系統的基本系統模型圖中列出的兩數據流之外,還有另外兩個數據流,它們與數據存儲相同。這是因為從應該數據存儲中取出來的或放進去的數據通常和原來數據相同,也就是說,數據存儲和數據流只不過是同樣的數據的兩種不同的形式。
訂貨系統的功能級數據流圖
接下來應該對功能級數據圖中描述的系統主要功能進一步細化。考慮通過系統的邏輯數據流:當發送一個事務時必須首先接收它;隨后按照事務的內部修改庫存清單;最后如果更新后的庫存量少于庫存量臨界值時,則應該再次訂貨,也就是要處理訂貨信息。因此,把“處理事務”這個功能分解為下述3個步驟,這在邏輯上是合理的:“接受事務”,"更新庫存清單","處理事務"。
為什么不進一步分解“產生報表”這個功能呢?訂貨報表中需要的數據在存儲的訂貨信息中全部都有,產生報表只不過是按一定順序排列這些信息,再按一定格式打印出來。然而這些考慮純屬具體實現的細節,不應該在數據流圖中表現。同樣道理。對“接收事務”或“更新庫存清單”等功能也沒有必要進一步細化。總之,當進一步分解將涉及如何具體實現一個功能時就不應該再分解了。
當對數據流圖分層細化時必須保持信息連續性,也就是說,當把一個處理分解為一系列處理時,分解前和分解后的輸入輸出數據流必須相同。
此外還要注意圖中處理編號的方法。處理1.1,1.2和1.3是更高層次的數據流圖中處理1的組成元素。如果處理2被進一步分解,它的組成元素的編號將是2.1,2.2,……;如果把處理1.1進一步分解,則將得到編號為1.1.1,1.1.2,……的處理。