第五章 結構化分析與設計： 流程塑模 (中) 一、結構化分析與設計之流程塑模工具 二、資料流程圖之建構 三、資料流程圖轉結構圖與模組設計 第五章 結構化分析與設計： 流程塑模 (中) 一、結構化分析與設計之流程塑模工具 事件與事件列、資料流程圖、資料字典、結構圖與HIPO圖、處理規格描述 二、資料流程圖之建構 建構策略、 修正之由中間往外策略步驟、評估 三、資料流程圖轉結構圖與模組設計

二、資料流程圖之建構  DFD之建構策略 修正之由中間往外策略步驟 DFD之評估 由上往下分割 由中間往外 找出初步資料流程圖元素 向上整合以建立資料流程圖 向下分解以建立低層資料流程圖 DFD之評估 正確性、有用性測試

2.1 DFD之建構策略 以DFD塑模企業流程是結構化分析與設計之重點工作，也是系統模組化之重要步驟。 常用的資料流程圖建構方式有兩種： 由上往下分割(Top-down Partitioning) 由中間往外(Middle-Out)

2.1.1 由上往下分割策略 建立步驟： (1) 建構環境背景圖。 (2) 由環境背景圖向下階層化，以分割出 系統主要功能並圖示之，亦即第零階之 資料流程圖。 (3) 對第零階資料流程圖中的每一個處理，再進行向下階層化，以產生更低階之資料流程圖。如此重覆進行，直到資料流程圖中所有處理不需再向下階層化為止。

由上往下分割策略之問題 第零階DFD不易產生 工作的分割可能不是最佳的系統分割 不易從環境圖直接分出系統的主要功能 對一個大系統而言，常是為了平均分配各分析師的工作量所做之安排 若於舊系統上建立新系統，則舊系統的主要功能分割方式可能變成新系統的主要功能分割方式

2.1.2 由中間往外策略 Yourdon (1988) 基於由上往下分割方式可能遭遇的問題，因此建議採用由中間往外的方式建構DFD，步驟為： Step1: 建立環境圖 因環境圖已於需求分析階段建立，因此在系統分析階段可直接應用或進行修正即可 Step2: 建立事件列 可由環境圖中之外部實體逐一檢討其與系統之互動關係，以建立事件列，並以文句之方式命名。

Step3: 建立初步的DFD 利用事件分割(Event partitioning)方法 (1) 每個事件均對應一個小的DFD 為每個事件繪製一個圓圈來表示事件回應之處理 為處理取一名稱，以描述「系統對此事件發生所採的動作與回應」 為處理加上所需的輸入、輸出資料流、資料貯存及外部實體 確認小資料流程圖與環境圖間的一致性 (2) 連接每個事件所對應的DFD 資料流程圖可以透過共同的檔案或資料庫，彼此連結成一個完整的初步資料流程圖

Step4: 對初步DFD進行向上及向下階層化，直到獲得完整的資料流程圖為止 因為每個事件對應一個處理(Process)，若事件列中有50個事件，那麼初步DFD中亦將有50個處理，因此需進行向上階層化，以降低初步DFD的處理個數。 部份處理若太複雜，則必需向下階層化。

2.2 修正之由中間往外策略步驟 2.2.1 需進行小幅修正之原因： 目前應用系統多以資料庫為中心，亦即大部分之處理所需之資料輸入與輸出都直接經由資料庫，而非處理間之直接傳遞。 用流程圖、處理描述、藍圖、資料詞彙可表達出使用者之巨觀需求，故可利用這些工具取代環境圖與事件列。 DFD之階層數最多不要超過四層，因層級愈多表示系統縱深愈長，將愈不易維護。

修正之由中間往外策略步驟 步驟一：找出初步DFD元素 步驟二：向上整合以建立DFD 步驟三：向下分解以建立低層DFD

結構化 企業流程 塑模個案 chap 7.1導論

夢幻系統個案之導論 以夢幻公司之MIS(簡稱夢幻系統)為例： 經營汽機車零件買賣之貿易公司 該公司擁有工廠，自行生產部份之零件 系統之範圍包括銷售、生產管理與採購 銷售包括訂單、送貨、銷退、請款與登帳等作業 生產管理包括領料、退料、繳庫與盤點等　作業 採購包括訂貨、進貨與退貨等作業

結構化 企業流程 塑模個案 chap 7.2需求分析

夢幻系統個案之需求分析 對使用者需求訪談之結果如下： (1) 業務部負責接訂貨單，接到客戶訂貨通知時需先進行訂貨資料登錄，並做成品庫存檢核，若成品庫存充足，則直接進行送貨處理；若成品庫存不足，則送生產需求通知給生產部以便進行產品之生產計畫。 (2) 業務部亦負責送貨與進行送貨資料處理，如計算金額、送成品，並產出送貨單給客戶確認

(3) 業務部收到客戶欲退回已銷售之成品通知(銷退單)，需記錄客戶編號及銷退成品數量、單價，並計算銷退單銷退總金額等 (4) 業務部向客戶請款： a. 每月請款一次，請款日期為每月25日。 b. 針對各客戶之本期送貨資料計算出本期應收帳款 c. 合計上期未收款項及本期應收帳款列印請款單，請客戶付款。 (5) 業務部收到客戶之付款單, 登錄客戶編號及付款資料。

流程圖 1 從上述描述及訪談得知，前兩項作業可連續發生，也就是客戶訂貨，若有足夠庫存，則可馬上送貨，其餘三項作業均各自獨立。 前兩項作業中 參與之外部實體：客戶、業務部與生產部 有訂貨與送貨兩個基本作業處理、一個庫存檢核控制 產出三張表單： 訂單、送貨單與生產需求 前兩項作業之流程圖可表示如圖7-1

圖7-1 訂單送貨流程圖

處理描述 1-1 以圖7-1之訂單處理為例 資料來源為客戶之訂單 產出為生產部之生產需求或通知出貨 結果摘述如下表：

藍圖 1-1 以圖7-1之訂單處理之訂單藍圖為例 以該公司目前之訂單報表為基礎，再進一步對訂單上之每一欄位進行編號

資料詞彙 1-1 以圖7-1之訂單處理之訂單藍圖為例 經由訪談整理，其訂單藍圖之資料詞彙如下：

夢幻系統個案之其他作業 流程圖2、3與4之分析步驟與原則均與流程圖1相同，請參考課本內容。 P.206~p.210

2.2.2 修正之由中間往外策略步驟 Step 1: 找出初步資料流程圖元素 從需求分析之結果(流程圖、處理描述、藍圖與資料詞彙)，找出初步DFD之： (1) 外部實體 (2) 處理 (3) 資料貯存 (4) 資料流

實例：夢幻系統個案 (1)找出外部實體 外部實體可由所有流程圖中之外部實體得到 亦即找出在電腦化時，與系統有互動關係之外部實體 夢幻系統個案中之客戶、業務部、生產部 、倉庫、廠房、主管等

實例：夢幻系統個案 (2)找出處理 初步DFD之處理可由所有流程圖上之處理得到 夢幻系統個案中之訂單處理、送貨處理、 銷退處理、請款處理、登帳處理等

(3)找出資料貯存 可由需求分析中之藍圖(包括輸入與輸出格式)中進行尋找 檢查每個藍圖中的每個項目或欄位，以訂出屬性，再將描述相同物件或概念之屬性整合成一實體類型 一般來說，一個原始藍圖至少可產生一個資料貯存，但經常是可以產生多個。

實例：夢幻系統個案 假設訂單是一個原始表單 客戶名稱、客戶電話、客戶地址 →描述「客戶」之實體 →so可整合成客戶之資料貯存 產品編號、規格、價格 →整合成產品之資料貯存 其他的部份如訂單編號、訂購日期等 →可整合成訂單之資料貯存 夢幻系統共有18個資料貯存(D1~D18) 見p.212

(4)找出資料流 實例：夢幻系統個案 找出外部實體、處理與資料貯存後，便可逐一檢查每一處理所需之資料來自何方及輸出到何處 方法：畫一矩陣，最左欄為處理，最上列為資料貯存與外部實體，逐一檢查每一處理所需之輸入來自何方、每一輸出之去向 實例：夢幻系統個案 註： ↓表示由資料檔(或實體)至系統；表示由系統至資料檔(或實體)

實例：夢幻系統個案 訂單與送貨處理之初步資料流程圖 DFD可透過共同的檔案或資料庫，彼此連結成一個完整的初步DFD 1.1 D1 客戶基本資料 生產部 訂單處理 D2 訂單資料 D3 產品資料 客戶 1.2 D4 生產需求資料 送貨處理 業務部 D5 送貨單資料

修正之由中間往外策略步驟 (續) Step 2: 向上整合以建立資料流程圖 若處理的數目很少且單純，可直接畫出最終的資料流程圖 大部份的情況(如處理的數目很多)，需將處理分群，以向上整合成較高層次之處理，且需對每一新產生之處理命名 可依管理功能、組織設計之部門別或　系統功能等，將相關的處理分群 Ex: 管理功能可能包括銷售管理、生產管理、財務管理等

處理之向上整合 環 境 圖 之 系 統 向上整合後之處理 Step 1之處理與分群 P 1 P 2 GP 1 P 3 P 4 P 5 GP 6 P 7 GP 3 P 8 P 9 GP 4 P 10

對上層DFD而言，其處理及資料流是下層DFD之處理及其資料流之匯總，且外部實體與資料貯存均不變 Ex: 訂單處理與送貨可整合成銷售管理，而其資料為兩者資料流之聯集 整合

實例：夢幻系統個案 與銷售管理相關之作業 包含訂單、送貨、銷退、請款、登帳五個處理 處理、資料貯存與資料流向

實例：夢幻系統個案 銷售管理子系統第一階DFD

實例：夢幻系統個案 第一階至第零階的處理與資料流整合

實例：夢幻系統個案 第零階 DFD 部分範例 客 戶 1.0 銷售管理 業 務 部 D5 稅率資料 D1 客戶基本資料 D2 訂單資料 D3 客 戶 D5 稅率資料 D1 客戶基本資料 D2 訂單資料 D3 送貨單資料 D4 銷退單資料 D6 請款單資料 D7 付款單資料 D8 成品資料 業 務 部 銷售管理 1.0

實例：夢幻系統個案 1.0 銷售管理 2.0 生產管理 3.0 採購管理 4.0 基礎項目管理與 5.0 綜合報表管理 向上整合：依管理功能之原則將處理分成五群 1.0 銷售管理 1.1 訂單處理 1.2 送貨處理 1.3 銷退處理 1.4 請款處理 1.5 登帳處理 2.0 生產管理 2.1 領料處理 2.2 退料處理 2.3 繳庫處理 2.4 盤點處理 1.5 登帳處理 3.0 採購管理 3.1 訂貨 3.2 進貨 3.3 退貨 4.0 基礎項目管理與 4.1 基本資料處理 5.0 綜合報表管理 5.1 主管報表處理

實例：夢幻系統個案 完整之第零階DFD範例 客 戶 生 產 部 1.0 銷售管理 倉 庫 業 務 部 2.0 生產管理 廠 商 3.0 請款單資料 客 戶 D7 付款單資料 D8 成品資料 D1 客戶基本資料 D2 訂單資料 D3 送貨單資料 D4 銷退單資料 D5 稅率資料 業 務 部 採購管理 3.0 廠 商 業務部 D10 廠商基本資料 D11 訂貨單資料 D13 退貨單資料 基礎項目 管理 4.0 綜合 報表管理 5.0 主 管 D9 原物料資料 D14 生產計畫資料 D15 領料單資料 D16 退料單資料 生產管理 2.0 生 產 部 D17 繳庫單資料 D18 盤點單資料 倉 庫 原料物資料 D12 進貨單資料

修正之由中間往外策略步驟 (續) Step 3: 向下分解以建立低層DFD 若Step 1產生之處理已很單純，則可不必再向下分解。 某些情況下，例如一個處理包含太多的工作或操作，可能需將處理向下分解成多個較單純之低層處理。 向下分解之原則，可依內聚力或程式碼之多寡來判定，例如不要超過200行，或是已符合功能內聚力。

處理之向下分解 P 51 52 53 54 55 P5 Step 1之 處理與分群 向下分解 後之處理 .

實例：夢幻系統個案 送貨處理為步驟一產生之處理，從巨觀的角度來看，送貨處理僅做一件訂單相關之事情，已符合所謂的功能內聚力，可不必再分解 以銷售管理子系統之送貨處理為例 送貨處理為步驟一產生之處理，從巨觀的角度來看，送貨處理僅做一件訂單相關之事情，已符合所謂的功能內聚力，可不必再分解 但若該處理中還包括新增、修改、刪除、查詢與列印等操作處理，則建議將送貨處理再依操作，向下分解至第二階。

實例：夢幻系統個案 銷售管理子系統第二階DFD (1.2送貨處理) 1.2.1 新增送貨單 1.2.2 修改送貨單 業 務 部 1.2.3 訂單資料 D1 客戶基本資料 D5 稅率資料 D3 送貨單資料 業 務 部 客 戶 新增送貨單 1.2.1 修改送貨單 1.2.2 刪除送貨單 1.2.3 列印送貨單 1.2.5 查詢送貨單 1.2.4 D8 成品資料

某些較複雜之第二階處理而言，其程式碼數量可能過大，若再加入偵錯或例外狀況處理則將更大，因此可考慮將該之分解成更細之處理。 實例：夢幻系統個案 第三階 DFD 某些較複雜之第二階處理而言，其程式碼數量可能過大，若再加入偵錯或例外狀況處理則將更大，因此可考慮將該之分解成更細之處理。 以新增送貨單為例，可再分解成六個子處理

實例：夢幻系統個案 銷售管理子系統第三階DFD (1.2.1新增送貨單) 業 務 部 稅率處理 1.2.1.2 送貨金額 處理 稅率資料 送貨金額 處理 1.2.1.4 送貨單資料 偵錯處理 1.2.1.5 儲存處理 1.2.1.6 送貨單基本 資料處理 1.2.1.1 送貨單成品 明細處理 1.2.1.3 D2 訂單資料 D1 客戶基本資料 D3 D8 成品資料 確認後的送貨資料