第5章 結構化分析與設計－流程塑模

本章大綱 學習目標 5.1 導論 5.2 結構化分析與設計評估準則 5.3 資料流程圖 5.4 資料流程圖的評估 5.5 資料流程圖轉結構圖與模組設計 5.6 結論

學習目標 詳讀本章，你至少能瞭解： 系統分析與設計之評估準則。 資料流程圖建構策略與指南。 如何描述處理規格。 如何將資料流程圖轉成結構圖模組設計。

5.1 導論 結構化分析與設計技術之重要工作，包括流程塑模、資料塑模、使用者介面塑模、軟硬體環境設計及開發工具選擇等。 流程塑模主要是以資料流程圖作為塑模之工具，將企業流程分解成具層級結構之模組，但良好的模組分割與結構須考慮內聚力與耦合力。 本章將先介紹結構化分析與設計之評估準則，再介紹資料流程圖之塑模概念、建構策略與步驟，進而介紹模組設計。

5.2 結構化分析與設計評估準則 良好的結構化系統設計有三個特徵： 模組間有很好的分割 階層式的系統架構 獨立的模組功能 要達到良好的系統設計與提升模組的品質，需考慮： 模組間的耦合力，是指一個系統內部各模組之間的相關程度。 模組的內聚力，是指一個模組內部所做事情之相關程度。 其他的考慮因素，如功能分割等。

5.2.1 內聚力(1/8) 內聚力(Cohesion) 常被用來評估一個模組內部所處理事情的相關程度。 模組的內聚力是衡量模組完成一件單一且定義清楚之工作的程度。 功能內聚力(Functional Cohesion) 順序內聚力(Sequential Cohesion) 溝通內聚力(Communication Cohesion) 暫時內聚力(Temporal Cohesion) 程序內聚力(Procedural Cohesion) 邏輯內聚力(Logical Cohesion) 偶發內聚力(Coincidental Cohesion)

5.2.1 內聚力(2/8) 功能內聚力 指的是當一個模組只做一件事情，即具有唯一功能，是功能型的內聚力。

5.2.1 內聚力(3/8) 順序內聚力 是指模組內具有多個功能或處理多件事情，且一項功能的輸出立即成為下一個功能的輸入，也就是共用相同的資料。 將計算所得結果顯 讀取某數值ｘ 計算ｘ平方

5.2.1 內聚力(4/8) 溝通內聚力 是指模組內具有多個功能或處理多件事情，且這些功能使用相同的資料（輸入），但它們的執行順序沒有相關性。

5.2.1 內聚力(5/8) 暫時內聚力 模組內具有多個功能或處理多件事情，但是這些功能僅僅在時序上有所關聯，也就是必須在同一時間內執行完成。

5.2.1 內聚力(6/8) 程序內聚力 是指模組內具有多個功能或處理多件事情，這些功能必須按照一定的順序來執行，但不共用資料，這些功能群集在一個模組內僅為了確保它們的執行順序。

5.2.1 內聚力(7/8) 邏輯內聚力 是指模組內具有多個邏輯上相關聯的功能。

5.2.1 內聚力(8/8) 偶發內聚力 若一個模組內部需要執行好幾件工作，且每一件工作都不相干，則該模組具有偶發內聚力。 在設計時，偶發內聚力應盡量避免。

圖5-8 判定模組內聚力之決策樹

表5-1 內聚力之評比因素與結果 內聚力種類 耦合力情形 模組撰寫 難易 與其他程式之共用性 維護性 瞭解性 功能型 小 易 佳 順序型 中等 溝通型 程序型 變動 暫時型 大 很差 邏輯型 很大 很難 差 偶發型 難

5.2.2 耦合力(1/13) 耦合力是一種衡量模組間相互關聯強度的方法。 當解決了一模組內的錯誤狀況，而在其他的模組內引起了新的錯誤，這種現象稱為連鎖反應(Ripple Effect)。 解決連鎖反應之可行方法是盡量使一個模組不與其他模組糾結在一起，即讓每個模組盡量的獨立，換言之，就是盡量降低模組間的耦合力，進而可提升模組之再利用。

5.2.2 耦合力(2/13) 耦合力可分為五類： 資料耦合力(Data Coupling) 資料結構耦合力(Stamp Coupling) 控制耦合力(Control Coupling) 共同耦合力(Common Coupling) 內容耦合力(Content Coupling)

5.2.2 耦合力(3/13) 資料耦合力 是指若模組間傳遞之參數為一些簡單型別的資料，則稱此模組間具有資料耦合力。 在處理資料耦合力時須注意，不要讓資料旅行太遠，亦即不要讓資料經過很多不必要的模組，以減少錯誤的機會。

5.2.2 耦合力(4/13) 資料結構耦合力 是指模組間以資料結構(Data Structure)型別作為程式的介面，但並非每個模組均用到該資料結構之所有欄位。 例如有「產生汽車租金帳單」、「計算基本汽車租金」與「計算油費」三個模組；及一個「租車」資料結構（如下圖）。若這三個模組間是以 「租車」資料結構作為程式的介面（如圖 5-11），則這些模組間具有資料結構耦合力。 租車 牌照號碼 會員證號碼 使用汽油量 汽車型式 已開公里數 租借天數 用於計算油費 用於計算基本汽車租金

圖5-11 資料結構耦合力

5.2.2 耦合力(5/13) 資料結構耦合力可能產生以下的問題： 雖然每一個模組可能只用到局部的欄位，但只要資料結構內任一個欄位被修改，則所有的相關模組均會受影響。 每一個模組使用了比實際需要更多的記憶體空間。 解決資料結構耦合力的方法是將所要用到的欄位傳遞過去，而不必傳整個資料結構，則資料結構耦合力就可改變成資料耦合力。

5.2.2 耦合力(6/13) 控制耦合力 指的是當一模組傳遞旗標去控制另一個模組內的作業（內部邏輯）時，則稱這兩模組之間具有控制耦合力。 例如有兩個模組：報表列印選擇與產生庫存報表或異動報表，前一個模組傳送旗標來控制下一個模組做輸入或輸出之動作(如圖 5-12)，則這兩模組間具有控制耦合力。

圖5-12 控制耦合力

5.2.2 耦合力(7/13) 控制耦合力必須先知道被呼叫模組內部之運作情形，因此設計時的困難度較高，且一模組改變旗標，會影響另一模組之運作。 控制耦合力之缺點： 如果被呼叫的模組被拆成兩個或兩個以上的模組時，會因資料的糾結或須瞭解呼叫模組之內部運作等問題而不易達到目的。 撰寫呼叫模組時，如不瞭解被呼叫的模組，便不易著手撰寫程式，同時會增加程式測試的成本。

5.2.2 耦合力(8/13) 共同耦合力 兩模組使用相同的資料區且都可讀寫資料區內之資料，則這兩模組具有共同耦合力。 例如有兩個模組：更新物料主檔與更新庫存主檔，均可讀寫零件表之資料，則這兩模組間具有共同耦合力（如圖 5-13）。

5.2.2 耦合力(9/13) 共同耦合力盡量少用，主要原因為： 如果共用資料產生錯誤，則所有涉及之模組均會受影響。 使用共同資料區的模組名稱均模稜兩可，不易定義，經常會造成困擾。 共用資料區內資料時常會被濫用，使模組的邏輯變得複雜而不易瞭解。 一個使用很多共用資料區的模組，在維護上相當困難。 模組變動時，不知哪些資料會被牽動。

5.2.2 耦合力(10/13) 內容耦合力 是一個模組使用另一個模組內之部分程式碼或改變其他模組內的局部變數。 內容耦合力具有下列特徵： 一個模組以多個進入點(Multi-Entry)的方式進入另一模組（如下圖）。 一個模組參考或改變其他模組的內部資料。 一個模組改變其他模組內部的執行過程。

5.2.2 耦合力(11/13) 一般來說，耦合力愈弱愈好。 模組間的耦合力有時可能不只是單純的一種情形，可能存在兩種以上的耦合力，此時這兩模組間的關係以較強的耦合力為準，例如兩個模組具有資料結構耦合力和共同耦合力的關係，則我們應以共同耦合力為準。

表5-2 耦合力之評比因素與結果 耦合力種類 連鎖反應狀況 修改難度 理解性 與其他程式之共用性 資料型 變動 易 佳 低 資料結構型 中等 控制型 難 差 高 共同型 很差 很高 內容型 很難

5.2.2 耦合力(12/13) 一般而言，可以接受的內聚力包含功能內聚力、順序內聚力與溝通內聚力， 而在耦合力部分則是資料耦合力與資料結構耦合力。 雖然這些內聚力與耦合力是可以接受，但就系統設計而言，良好的設計希望達到模組內的內聚力為功能內聚力，即一個模組只處理單一個功能；模組間的耦合力為資料耦合力，即模組間的溝通只使用簡單型別參數來溝通。

5.2.2 耦合力(13/13) 一個良好的設計除了耦合力與內聚力的分析外，尚有一些值得注意的事，包括： 模組功能的劃分。因模組太大而須減少功能的重複、為了管理需求、為了發展可重複使用的模組或發展易撰寫的模組時，都是模組功能劃分的適當時機。 模組除了有正規之處理外，亦須考量錯誤與輔助訊息及例外狀況之處理。

5.3 資料流程圖 資料流程圖提供一種簡易的、圖形化的方式，以表達系統之作業處理與資料流間之關係。 典型的系統通常需要數層的資料流程圖，最高層稱為第零階，接下來依序為第一階、第二階到第“N”階，其中第零階表示系統的概觀，而其每個處理可再被分解，以表示系統下之子系統。

表5-3 資料流程圖之表示符號

5.3.1 資料流程圖之元件 外部實體(Entity) 是指環境中與系統有交換訊息或互動關係的人或物（例如組織、物件或相關系統等） 資料流(Data Flows) 是資料項目的集合，用來表示處理所需要的輸出和輸入。 處理(Process) 即為一個最小單位的活動。 資料儲存(Data Store) 為儲存在資料庫內的資料檔案。

5.3.2 資料流程圖之建構策略與步驟 一般來說，常用的資料流程圖建構方式有兩種： 由上往下分割 由中間往外建構

由上往下分割(1/2) 以由上往下分割之方式建立資料流程圖之步驟為： 由需求分析階段所得之環境圖向下階層化，以分割出系統主要功能並圖示之，這就是第零階之資料流程圖。 對第零階資料流程圖中的每一個處理，再進行向下階層化，以產生更低階之資料流程圖。 如此重複進行，直到資料流程圖中所有處理不需再向下階層化為止。

由上往下分割(2/2) 應用由上往下分割之方式建構資料流程圖可能會碰到以下的問題： 第零階之資料流程圖不容易產生，因為系統分析師不容易從環境圖直接分出系統的主要功能。 對於一個大型系統而言，假如系統分析師有三位，為了平均分配工作量，系統常被分割成三個主要功能，但這種分割方式可能不是最佳的安排。 倘若於舊系統上建立新系統，則舊系統的主要功能分割方式可能繼續成為新系統的主要功能分割方式，同樣地，這亦可能不是最佳的分割方式。

由中間往外建構(1/4) Yourdon(1988; 1989)基於由上往下分割方式可能遭遇的問題，建議採用由中間往外(Middle-Out)的方式建構資料流程圖，其建構步驟為： 建立事件列。 建立初步的資料流程圖，也就是將前述的事件列利用事件分割(Event Partitioning)方法，以獲得初步資料流程圖。 將初步資料流程圖不斷地向上及向下階層化，直到獲得完整的資料流程圖為止。

由中間往外建構(2/4) 建立事件列 事件列是由一群事件所組成。一般而言，任何事件的發生都會伴隨某一種刺激(Stimuli)到達系統，而此類刺激通常由外界實體所發出。 事件列之建立，可由需求分析階段之使用者與企業需求取得，或由環境圖中之外部實體逐一檢討其與系統之互動關係，並以文句之方式呈現。

由中間往外建構(3/4) 建立初步的資料流程圖 利用事件分割的方法從事件列中建立初步資料流程圖(First-Cut DFD)，其執行步驟如下： 確定系統對每個事件所做的回應。 連接每個事件所對應的資料流程圖並建立初步資料流程圖。

由中間往外建構(4/4) 對初步資料流程圖進行向上及向下階層化，直到獲得完整的資料流程圖為止 因為每個事件對應一個處理，若事件列中有五十個事件，那麼初步資料流程圖中亦將有五十個處理，因此必須進行向上階層化，以降低初步資料流程圖的處理個數，但亦額外增加上層(Upper-Level)資料流程圖。 另外，初步流程圖中，部分處理可能需要進行向下階層化，如將上一階圖中的各個作業分解成更細部之步驟，或是定義出較詳細之資料流，因此也會增加額外的下層(Lower-Level)資料流程圖。

資料流程圖建構指南(1/9) 以由中間往外之策略建立資料流程圖時，亦可做如下之修正： 由於資料庫之普遍應用，目前應用系統之設計大多以資料庫為中心，也就是說，大部分之處理所需之資料輸入與輸出都直接經由資料庫，而非處理間之直接傳遞。 第3章建議用流程圖配合處理描述、藍圖與資料詞彙，以表達使用者之巨觀需求，其中作業處理指的是企業流程中最基本的活動單元，且每個作業處理皆有明確的輸入與輸出。 因此，可將此作業處裡視為資料流程圖之處理，然後再往下分解出下階之處理及往上整合成上階之處理。

資料流程圖建構指南(2/9) 資料流程圖之階層數最多不要超過四層，也就是至多到第三階之資料流程圖，因為層級愈多，表示以後系統結構之縱深愈長，系統也愈不易維護。 修正後之由中間往外策略的實施程序，是找出初步資料流程圖之四元素後 若處理太多，則需向上整合出更高階之處理，並畫出高階之資料流程圖； 若處理太複雜，則需向下分解成多個較單純之低階處理，並畫出低階之資料流程圖，詳細的步驟如下：

資料流程圖建構指南(3/9) 步驟一：找出初步DFD元素 首先，從需求分析之結果（流程圖及其處理描述、藍圖與資料辭彙），找出初步資料流程圖之： (1) 外部實體 (2) 處理 (3) 資料儲存 (4) 資料流等

資料流程圖建構指南(4/9) (1) 找出外部實體 (1) 找出外部實體 資料流程圖之外部實體可由流程圖之外部實體得到，也就是判斷外部實體在電腦化時是否與系統有互動關係。若有，則是資料流程圖之外部實體，否則不是，因為並非流程圖中所有部分都要電腦化。 (2) 找出處理 初步資料流程圖（例如第一階資料流程圖）之處理可由所有流程圖上之作業處理得到，每個處理皆有其輸入與輸出格式(Input and Output Form)、所涉及之主要與次要外部實體等。

資料流程圖建構指南(5/9) (3) 找出資料儲存 資料流程圖之資料儲存，可由需求分析中之藍圖尋找。 一般來說，一個原始藍圖至少可產生一個資料儲存，但經常可以產生好幾個，可依處理該藍圖之工作量來考量，工作量應盡可能的最小化，以利後續分析與設計的進行。 (4) 找出資料流 找出外部實體、處理與資料儲存後，便可進行資料流之檢查與確認工作。 其中，每一處理之主要行為者其資料流均為雙向。

資料流程圖建構指南(6/9) 以夢幻系統之訂單送貨流程圖為例，可整理出客戶、業務部與生產部三個外部實體，訂單與送貨兩個處理及客戶基本資料、訂單資料、成品資料、送貨單資料、稅率資料五個資料儲存。 對訂單處理而言，它由客戶傳送資料所引發，主要行為者為業務部，業務部從客戶所下訂單中擷取資料，並由成品資料儲存檢查成品庫存是否足夠，經處理後將結果存於訂單資料儲存，再傳送一份給業務部，最後進入送貨處理（參表5-5）。

表5-5 資料流表達範例

資料流程圖建構指南(7/9) 步驟二：向上整合以建立高階DFD 若處理的數目很少且很單純，可不需向上整合而直接畫出最終之資料流程圖，但在大部分的情況（例如處理的數目較多）可能需將處理分群，以向上整合成較高層次之處理，亦可能需將較複雜之處理分解成多個較低階之單純處理。 不論向上整合或向下分解，均需對每一新產生之處理命名。

資料流程圖建構指南(8/9) 對上層資料流程圖而言，其處理及資料流是下層資料流程圖之處理及其資料流之匯總，且外部實體與資料儲存均不變。 以表5-5為例，訂單處理與送貨處理可整合至銷售管理，而其資料為兩者資料流之聯集（如表5-6）。

表5 -6 整合後之資料流表達範例 整合

圖5-16 處理之向上整合

資料流程圖建構指南(9/9) 步驟三：向下分解以建立低層DFD 若步驟一產生之處理已很單純，則可不必再向下分解。但在某些情況下，例如一個處理包含太多的工作或操作，可能需將處理向下分解成多個較單純之低層處理。 向下分解之原則可依內聚力或程式碼之多寡來判定，例如不要超過200行。

圖5-17 處理之向下分解

5.3.3 資料流程圖(1/10) 一般來說，資料流程圖繪製之原則如下： 處理以動詞片語命名，外部實體、資料流與資料儲存以名詞片語命名，每一物件的命名均為唯一。 典型的處理是把輸入轉換成輸出，而非僅傳送資料。因此，處理之輸入與輸出並不相同。 具完整性(Completeness)。系統所需要之元素應全部包含在資料流程圖中。 具一致性(Consistency)。資料流程圖中，某一層之資訊範圍亦需包括在其他層中。 時間(Timing)。資料流程圖無法表達時間。 反覆設計(Iterative Development)。資料流程圖需反覆繪製，才能較完美地表達系統。

5.3.3 資料流程圖(2/10) 最底層的資料流程圖稱為基本的(Primitive)資料流程圖，下列情況可幫助我們判斷資料流程圖是否已被分解到最底層： 當每個處理已被分解到單一決策、單一計算或對單一資料庫操作時，例如檢索、修改、新增、刪除或讀寫等。 當每個資料儲存表達單一實體之資料，例如客戶、員工、產品或訂單。 當系統使用者不必看到更細部，或當分析者已記載到足夠詳細可做後續的系統發展工作。 當每一企業表單(Business Form)或交易、電腦之即時展示與報告被視為單一資料流

5.3.3 資料流程圖(3/10) 除了上述原則外，另有一些資料流程圖製作準則(Celko, 1987)： 處理 (1)不可以僅有輸出而無輸入。 (2) 不可以僅有輸入而無輸出。 不正確 正確 不正確 正確

5.3.3 資料流程圖(4/10) 資料儲存與外部實體 (1)資料不可直接由一資料儲存移到另一資料儲存，必須由處理移動。 (2)資料不可直接由外部實體移至一資料儲存，必須透過處理至資料儲存。

5.3.3 資料流程圖(5/10) (3)資料不可直接由資料儲存移至外部實體，必須透過處理再至外部實體。   (4)資料不可直接由外部實體移至外部實體，必須透過處理。

5.3.3 資料流程圖(6/10) 資料流 (1)資料流僅以單方向之箭頭符號表示。資料可能在處理與資料儲存間流動，例如先讀取再更新資料，此兩者應以分開之兩箭頭表示，因為兩個事件發生之時間不同且資料亦不同。

5.3.3 資料流程圖(7/10) (2)資料流之分叉表示完全相同之資料從同一地點流出，並流入不同的地方。 (3)資料流之匯合表示完全相同之資料從不同的地方流出，並流入相同的地方。 B A B A

5.3.3 資料流程圖(8/10) (4)資料流不可由一處理流出再直接流入該處理。 (5)一資料流至一資料儲存意謂著資料之更新，例如資料之刪除或修改。資料從資料儲存流出意謂著讀取或使用。 (6)兩個或兩個以上之資料流可出現在單一箭頭上，只要這些資料流結合成一包裝(Package)並一起移動。 A B C

5.3.3 資料流程圖(9/10) (7)一合成資料流在某一層級可被拆成其下一層之一或多個子資料流，但不可加新資料，且上層資料流必須相等於其下一層之子資料流之集合。 (8)處理之輸入必須足以經由處理產生必要的輸出。 (9)在資料流程圖最底層，可能加入一些新的資料流，以表示某些特殊情況之資料傳遞。這些資料流表示典型的錯誤訊息或確認告示(Notices)

5.3.3 資料流程圖(10/10) (10)為避免資料流交叉，資料流程圖中之資料儲存或外部實體可重複。重複之資料儲存可用雙重直線表示；重複之外部實體在其一角可用斜線表示。

5.4 資料流程圖的評估(1/6) 資料流程圖的產生是經由一連串反覆階層化動作，以獲得最後之資料流程圖。一般來說，整個資料流程圖之製作常無法一次做好，需要反覆修改才能愈趨實用。 DeMarco(1979)認為，完成後之資料流程圖必須測試其正確性(Correctness)與有用性(Usefulness)，茲將這兩個準則介紹如下。

5.4 資料流程圖的評估(2/6) 測試資料流程圖的正確性 對資料流程圖做外部一致性檢查 對資料流程圖進行內部一致性檢查(Consistency Checking) 資料守恆(Data Conservation) 排演(Walkthrough)

5.4 資料流程圖的評估(3/6) 對資料流程圖做外部一致性檢查 確認資料流程圖中的每個資料流、處理及檔案皆有名稱，且均有資料字典定義之。 確認每個處理是否有一個低層次資料流程圖與它對應，否則該處理便是最低層處理，且應有一處理描述以描述該處理（系統）之行為。 確認每個資料儲存是否在實體關係圖中至少存在一個實體與之對應。

5.4 資料流程圖的評估(4/6) 對資料流程圖進行內部一致性檢查 確認資料流程圖是否平衡(Balancing)，例如檢查其上下層間之資料流、資料儲存與外部實體是否皆一致。 檢查資料流程圖是否存在重複或多餘的處理。 檢查資料流程圖中是否存在只有輸出沒有輸入(Output-Only)或只有輸入沒有輸出(Input-Only)的處理。 檢查資料流程圖中是否存在只有輸出沒有輸入(Output-Only)或只有輸入沒有輸出(Input-Only)的資料儲存。 檢查資料流程圖的編號是否正確。

5.4 資料流程圖的評估(5/6) 資料守恆 觀察處理的輸出及輸入資料流，判斷是否存在有多餘的或缺少的資料流。 排演 有關資料流程圖中可能的概念性錯誤(Conceptual Error)，例如使用者作業需求方面之錯誤，若只由技術人員進行檢查很難發現，因此可以透過使用者及系統發展人員共同排演與開會討論，對資料流程圖做總檢查以找出概念性錯誤。

5.4 資料流程圖的評估(6/6) 測試資料流程圖的有用性 測試資料流程圖的有用性，即評估資料流程圖是否過於複雜，不容易閱讀等。 通常測試資料流程圖的有用性必須評估以下事情： 處理的名稱是否有意義與唯一。 最低層資料流程圖中是否存在內聚力太弱的處理，若有，則需進行向下階層化。 任何一張資料流程圖中，是否存在某個處理之介面複雜度太高，即輸出入資料流數目太多，若是，則需進行再分割。 任何一張資料流程圖中，處理個數是否太多，若是，則需進行向上階層化。

5.5 資料流程圖轉結構圖與模組設計 處理規格描述 結構圖與HIPO圖

5.5.1 處理規格描述(1/4) 處理規格描述(Process Specification)允許系統分析師在資料流程圖最底層之每個基本處理單元，精確地描述其商業規則（例如作業處理邏輯）。 許多不同的方法可被用於描述處理規格，例如： 流程圖 法則 結構化英文(Structured English) 程式設計語言(Program Design Language, PDL)等 目前結構化英文與程式設計語言較常被用於處理規格描述。

結構化英文 在最極端的形式，結構化英文僅由下列所組成： 有限的、必要的動詞與名詞的集合，例如 Read、Write、Add、Subtract、Compute 與 Validate 等動詞與名詞的集合，而名詞常在資料字典中定義。 控制方法藉由結構化程式語言(例如IF-THEN-ELSE與DO-WHILE等)來描述可能行動(Alternative Actions) 與重複行動。

程式設計語言 程式設計語言之概念由Caine、Farber 與 Gordon 在 1975 年提出。基本上，程式設計語言沒有嚴格的定義，只要以日常生活的語言將程式設計的概念描述出來即可。

5.5.1 處理規格描述(4/4) 程式設計語言之撰寫準則： 使用口語化的描述，明確地敘述例行程序(Routine) 的每個動作。 避免使用特定程式語言的寫法來表達，也就是程式設計語言之描述須與程式語言獨立。 根據程式的意圖來撰寫程式設計語言，也就是應描述「程式要做些什麼？」而不是「我要怎麼用自己熟知的語言來寫這個程式？」 反覆地設計與修飾才能使所寫出之程式設計語言與程式碼間的差距拉近，也就是可非常直覺地、無須多加思索地把程式設計語言轉為程式碼。

表5-7a 不好的PDL描述範例

表5-7b 修改後的PDL描述範例

程式設計語言 好的程式設計語言描述應該在程式完成後能成為程式的註解。以表5-8a之操作為例，該操作以程式設計語言完成描述後可作為程式編輯之參考，程式編輯後，原來之程式設計語言描述便成為該程式的註解，如表5-8b所示。

表5-8a PDL描述範例

表5-8b PDL描述與程式範例

5.5.2 結構圖與HIPO圖(1/10) 繪製資料流程圖後，需將資料流程圖轉成結構圖，才可作為程式設計時所參考的依據。 資料流程圖轉結構圖之主要目的是以模組的角度，將相同功能的處理合併，因為資料流程圖是以流程為導向，各處理可能會有重複的功能，因此需要結構圖來幫助釐清資料流程圖中有哪些功能是重複的，以增加程式的再用性。

5.5.2 結構圖與HIPO圖(2/10) 結構圖(Structure Chart)與HIPO圖(Hierarchical Input Process Output)等文件工具的目的是用來表達系統的模組結構(Structure)及系統架構(Architecture)，而非針對程序邏輯(Procedural Logic)。 結構圖以圖形之方式，顯示一資訊系統之模組如何以層級方式組成，以及如何以資料傳遞來表示模組間之互動關係。

5.5.2 結構圖與HIPO圖(3/10) 結構圖之元件：

5.5.2 結構圖與HIPO圖(4/10) 模組(Module) 一個模組是執行某特定工作的一連串敘述，類似資料流程圖的「處理」。例如有的模組包括COBOL敘述、PL/1程序、組合語言、外部副程式及以任何語言完成的程式等。 連繫(Contact) 一個連繫是連接兩個模組的符號，由監督模組（呼叫模組）到附屬模組（被呼叫模組）。

5.5.2 結構圖與HIPO圖(5/10) 資料耦合 資料耦合用以表達資料在兩個模組間的傳遞，資料經常是一個單一資料元素，有時可能為一資料結構或甚至是整筆記錄。 一個耦合是一個由某一模組移動至另一模組的資料項。 所有的或通過的資料必定以一個耦合出現。一個連繫可能有數個耦合，每一個耦合必須要被填入資料字典中。 耦合的名稱不需要是唯一，但應該定義清楚。 旗標 一個旗標是一個測試的資料項，其目的是聯繫在某些條件下的訊息，以及其他資料項的聯繫。

5.5.2 結構圖與HIPO圖(6/10) 結構圖的根部(Root)有一協調模組(Coordinating Module)，其下一層是協調模組所呼叫的模組。 以系統為例，根部可想像成主選單，而其每個附屬模組是主選單之選項。 例如有兩個模組，第一個模組主要負責讀取資料A與B，另一模組將A、B兩者經過計算後製作成資料C。前者為協調模組，而後者為被呼叫的模組，其結構圖表示如圖5-19。

圖5-19 結構圖範例一

5.5.2 結構圖與HIPO圖(7/10) 除了上述符號外，在結構圖中尚有其他符號： 條件呼叫模組 模組下之菱形意謂著一次僅一個附在其下之下層模組被呼叫。菱形表示模組碼中，有條件指令來決定哪個下層模組被呼叫，如下圖所示。

5.5.2 結構圖與HIPO圖(8/10) 嵌入模組 連接兩模組之特殊符號稱為「帽」(Hat)，意指在下層模組之功能對系統來說，邏輯上非常重要，但僅需要幾條程式碼去執行該功能，且此功能本身實際上亦包含在上層模組中。 例如大學註冊系統應包含計算學生平均成績(Grade Point Average, GPA)之程式碼，但計算GPA僅需幾行程式碼，並不值得另成一分開之模組。因此，計算GPA之模組，邏輯上以一分開之模組出現在結構圖上，但完成此功能之實際程式碼將被包含在上層模組中，如圖5-21所示。

圖5-21 嵌入模組

5.5.2 結構圖與HIPO圖(9/10) HIPO圖亦是以圖形之方式，顯示一資訊系統之模組如何以層級方式組成，其符號與結構圖相似，但HIPO圖上並不需表示模組間之互動關係，例如少了模組間之資料流(Yourdon, 1989)與控制流，圖5-22a與圖5-22b可說明結構圖與HIPO圖之差異。

圖5-22a 結構圖範例二

圖5-22b HIPO圖範例

5.5.2 結構圖與HIPO圖(10/10) HIPO圖比結構圖少了資料流，這些輸入與輸出之資料流常在HIPO圖之另一元件，稱IPO(Input Process Output)圖（如下圖）中表達，也就是說，HIPO圖中之每個模組可進一步的將輸出入與處理規格描述表示在IPO圖中(Yourdon, 1989)。

5.5.3 DFD轉結構圖或HIPO圖(1/8) 由資料流程圖轉結構圖的步驟實施以前，要先有一個完整之資料流程圖，也就是要有第零階至最底層之資料流程圖，接著去除資料儲存。 資料流程圖轉結構圖或HIPO之步驟有四： (1) 設立總裁(President)與副總裁(Vice Presidents) (2) 設立較低層模組 (3) 模組設計與結構圖修改 (4) 進行評鑑

5.5.3 DFD轉結構圖或HIPO圖(2/8) 步驟一：設立總裁與副總裁 使用總裁與副總裁的原因，主要是因為結構圖與組織中之組織圖相似。 在組織中，總管理者常稱為總裁，其下執行不同管理任務者稱為副總裁，可將環境圖上之系統視為總裁，而第零階資料流程圖上之處理視為副總裁，資料流程圖上之資料流變成結構圖上模組間必要的聯繫。 處理聯繫時，暫時先忽略所有錯誤之發生情況、資料庫及其資料流等。

5.5.3 DFD轉結構圖或HIPO圖(3/8) 步驟二：設立較低層模組 把第一階及其更低階資料流程圖上之處理，依序懸掛在結構圖上的副總裁底下，例如某第零階之資料流程圖下有更低階之資料流程圖，則須把第一階之處理掛在其第零階處理之下；同樣地，第二階之處理應掛在其所屬第一階處理之下。 在安置模組時，要把輸入模組置於左方，輸出模組置於右方，其他之移轉步驟模組置於中間，各模組應按其執行之先後順序置於結構圖上，且每一階之間必須加上必要之連繫。此步驟完成後，第一版之結構圖即已完成。

5.5.3 DFD轉結構圖或HIPO圖(4/8) 步驟三：模組設計與結構圖修改 完成第一版之結構圖後，應先對結構圖中之每一模組進行模組設計，再進一步修改結構圖，使之更完美。這些工作包括： 需加入資料流程圖中所沒有的例外狀況處理，出現錯誤時之錯誤訊息處理及操作時可能之輔助訊息處理等。 將結構圖上較弱的地方再分解且加以重新組織。

5.5.3 DFD轉結構圖或HIPO圖(5/8) 原則上，完成資料流程圖建構後，每一個最底層的處理至少都將是一個模組。 經上述修改後之結構圖不一定很好，應用內聚力與耦合力之設計評估準則可幫助我們進一步地加以改善： 檢查內聚力 檢查耦合力

5.5.3 DFD轉結構圖或HIPO圖(6/8) 檢查內聚力 DeMarco(1979)將七種內聚力分為可接受與不可接受的內聚力，摘述如下：

5.5.3 DFD轉結構圖或HIPO圖(7/8) 檢查耦合力 模組間的耦合力不是單一的情形，可能存在兩種以上的耦合力，這時候要以較高的耦合力為準。 例如兩個模組間同時具有資料結構型及共同型之耦合關係，則應以共同型之耦合力為準。 應檢查結構圖上是否有不可接受的耦合力，若有，則應加以修正，因為較強之耦合力將導致較弱的內聚力，而使得系統不易維護，應盡量避免。

5.5.3 DFD轉結構圖或HIPO圖(8/8) 步驟四：進行評鑑 完成模組設計與結構圖修改後，接下來應確定結構圖的運作功能。也就是該結構圖應能正確地描述系統行為，以完成流程圖上所描述之企業流程與規則。 進行評鑑的目的是希望能盡早找出錯誤並及早修正，而不希望等到系統完成或在運作時發生錯誤再去修改它。

5.6 結論(1/3) 本書建議資料流程圖之建立採由中間往外之策略，該策略之概念與執行已經過修改與擴充，主要概念有二： 處理間之資訊輸入與輸出以資料庫為中心，也就是說，大部分之處理所需之資料輸入與輸出都直接由資料庫，而非處理直接傳遞。 以需求分析之環境圖、流程圖配合處理描述、藍圖與資料詞彙，表達使用者之巨觀需求，並將這些資訊直接轉成資料流程圖之元素，以簡化資料流程圖之製作。

5.6 結論(2/3) 此外，流程圖之處理描述、資料流程圖之處理描述和模組設計中之處理規格描述間有一些差異，摘述如下：

5.6 結論(3/3) 雖然資料流程圖已廣泛地應用於企業流程塑模上，但基本上，資料流程圖之應用仍有其不足的地方，例如： 資料流程圖之應用是功能導向的結構化分析，一旦流程或功能有所改變，將會導致資料流程圖產生一連串改變。 資料流程圖缺乏時間狀態表示，在記載流程順序時，並未提供和時間有關的資訊與控制。 有關資料流程圖在製作上及使用者之學習方面仍須再改進。