第四章 結構化技術 一、結構化技術之概念 二、主要的結構化技術 三、結構化分析與設計三部份 結構化程式設計 由上而下發展 結構化設計 第四章 結構化技術 一、結構化技術之概念 二、主要的結構化技術 結構化程式設計 由上而下發展 由上而下設計、編碼、整合測試 結構化設計 經驗法則、評估準則(chap 5.2)、文件工具 結構化分析 三、結構化分析與設計三部份

一、結構化技術之概念 系統開發模式 結構化技術 (又稱軟體工程技術) 強調系統開發過程中應有之步驟以及執行程序 不涉及每個步驟可支援的方法或技術 結構化技術 (又稱軟體工程技術) 起源於1960年代末期 主要強調如何應用一些概念、策略與工具，以提升系統分析與設計、程式設計與測試之效率與效能等。

二、主要的結構化技術 結構化程式設計 (Structured Programming) 由上而下發展 (Top-down Development) 結構化設計 (Structured Design) 結構化分析 (Structured Analysis)

2.1 結構化程式設計 由Dijkstra (1969)提出 消除程式因goto而造成如麵條式的混亂狀態 強調任何程式邏輯均可由三種結構組成 循序(sequence)：簡單命令式的指令如 COMPUTE, READ, WRITE 與代數指令如X=Y+Z。 選擇(condition)：需做決策時，用 IF-THEN-ELSE 指令與 CASE 指令。 重複(repetition)：當需反覆時，用 DO-WHILE 與 DO-UNTIL 指令。

結構化程式之邏輯概念

2.2 由上而下發展 起源於1960年代末期 強調把大問題依序分解成具層級結構之小模組，並由上層模組開始進行程式設計及測試 包含三個相關但不同方面的「由上而下」： 由上而下設計(Top-down Design) 由上而下編碼(Top-down Coding) 由上而下整合測試 (Top-down Integration Test)

<A> 由上而下設計 把大而複雜的問題分解成較小且較簡化的問題，直到原來的問題已可用一些容易且可理解的小問題組合來代表。例： a. 先將主程式分為A、B、C三個子程式 b. 再劃分子程式A為A1與A2，子程式C為C1與C2 Main Ａ B C Ａ1 Ａ2 C1 C2

由上而下設計的特色： (1)層級化設計：先考慮程式的主要功能，再依次考慮其下的各個次要功能。 (2) 延緩考慮細節問題：先考慮高層次之功能，再考慮其下之次功能。 (3) 與程式語言無關：可選用任何一種語言來撰寫，而不需更改設計內容。 (4) 便於驗證：可檢驗程式的主要功能是否劃分完備。

另一種設計方式為由下而上設計 先考慮程式中較底層的項目及其間的關係，再將這些基本的部份組成較高層次的部份，繼續組成更高層次的部份，最後組合成一個完整的程式。 見下頁圖示 優點：能及早對程式內部各子程式作績效評估 缺點：難以完全規劃一個程式；不易根據此方式將程式劃成幾個部份及 明確定出其間相互影響之資料與關係。

由下而上設計圖例 先獨立發展各個細部的子程式X, Y, Z 再將X, Y, Z組成較高的子程式A1 經過逐次整合成為完整系統 Ｘ Ｙ Ζ Main A1 A1 B Ｘ Ｙ Ζ Ｘ Ｙ Ζ

<B> 由上而下編碼 一種程式編輯的策略 當高階模組被設計完成後，就先對高階模組編碼。 通常不需等到整個系統的架構全部設計完成，即可著手撰寫程式。 此種做法在系統很大時，有助於縮短時間。

<C> 由上而下整合測試 在低階模組尚未完成程式撰寫前，先測試系統的高階模組 首先由結構圖上最頂端的模組開始進行測試，而以虛擬模組(Dummy Module)暫時代替其下一層未完成的模組。 以下圖為例，測試模組 A 時， C與 D是虛擬模組，同樣的，測試B時，E與F是虛擬模組。

由上而下測試之虛擬模組關係

由上而下整合測試之優點： 由上而下整合測試之缺點： 系統的整合測試可以減至最少。 最高階層的介面最先被測試，且被測試的機會最多。 高階層的模組是低階層模組最佳的測試啟動(Driver)模組。 系統的錯誤若在上階層，則可及早發現。 由上而下整合測試之缺點： 需要製造虛擬模組。 以虛擬模組執行輸入、輸出功能較困難。 測試個案的產生可能會很困難。

2.3 結構化設計 起源於1960年代末期，其概念先於結構化分析 主要目的：將資訊系統依由上而下發展，並將程式設計模組化與結構化。 決定系統應有哪些模組？ 模組間以何種相互聯繫才能最有效解決 問題？ 特別強調系統的可維護性

模組(Module) 一連串指令的集合，包括： (1)模組名稱：唯一且應有意義，應能表達模組的功能 (2)輸入：模組被呼叫時，呼叫模組所需輸入的資料 (3)輸出：模組執行後所產生的輸出結果 (4)處理邏輯：為達成模組功能，模組內所需具備的執行程序與邏輯。 (5)內部資料：該模組獨自擁有而不與其他模組共用的資料

結構化設計之法則與工具 包括設計經驗法則、評估準則與文件工具等 經驗法則 模組大小、控制間距、控制範圍 評估準則 模組內部所做事情的相關程度(內聚力) 模組間的相關程度(耦合力) 有很好的功能分割 文件工具 結構圖(Structure Chart) HIPO圖 (Hierarchical Input Process Output) 模組規格描述、資料字典

<A> 結構化設計之經驗法則 模組大小 基於小模組比較簡單的假設，小模組比大模組較易維護與修改，故結構化設計較傾向用小模組。 一般來說，小模組約包含 200 個以下的程式指令 例如，可列印在1～2頁之A4紙內

結構化設計之經驗法則 (Cont.) 控制間距 控制範圍 一個模組不要同時控制太多即時模組，因為控制太多模組將不利瞭解與維護。 最多不要超過９個(Magic Number 7±2) 控制範圍 為縮小影響範圍與控制範圍，當甲模組之行為被乙模組所影響，則甲模組應從屬於乙模組。

<B> 結構化設計之評估準則 要達到良好的系統設計與提升模組的品質，需考慮： 模組的內聚力(cohesion)：一個模組內部所做事情的相關程度。 模組間的耦合力(coupling)：一個系統內部各模組之間的相關程度。 其他考慮因素：如功能分割、錯誤訊息等。

<a> 內聚力 衡量模組內部工作相關程度的方法 也就是衡量模組完成一件單一、且定義清楚之工作的程度，可分為七種： 功能內聚力(Functional Cohesion) 順序內聚力(Sequential Cohesion) 溝通內聚力(Communication Cohesion) 程序內聚力(Procedural Cohesion) 暫時內聚力(Temporal Cohesion) 邏輯內聚力(Logical Cohesion) 偶發內聚力(Coincidental Cohesion)

(1)功能內聚力 一個模組只做一件事情 亦即每個模組僅具有唯一的功能 例如：以下的三個處理均僅針對一件事，若分別成為一個模組，則具有功能內聚力 檢查身分證 號 碼正確性 以異動檔更新 庫存主檔 計算營業稅

(2)順序內聚力 模組內具有多個功能或處理多件事情，且一項功能的輸出立即成為下一個功能的輸入、共用相同的資料 實例： 將計算所得結果 讀取某數值ｘ 計算ｘ之平方 顯示於螢幕上

(3)溝通內聚力 模組內具有多個功能或處理多件事情，且這些功能使用相同的資料(輸入)，但執行順序沒有相關性。 實例： 查詢品名規格 產品資料 查詢庫存數量 產品資料 查詢儲存架位

(4)程序內聚力 模組內具有多個功能或處理多件事情，這些功能必須按照一定的順序來執行，且不共用相同資料 這些功能群集在一個模組內，是為了確保其執行順序 實例：假設一提款系統之處理如下 檢查 密碼 讀取提款 金額 讀取提款機 餘額 計算客戶 存摺餘額

(5)暫時內聚力 模組內具有多個功能或處理多件事情，但是這些功能僅僅在時序上有所關聯，也就是需在同一時間內完成，但執行上無先後順序 實例：系統開始時，初始狀態之設定如下 設定日期格式 指定資料檔路徑 清除所有變數 設定變數啟始值

(6)邏輯內聚力 模組內具有多個邏輯上相關聯的功能。 實例：一系統輸出模組負責輸出錯誤訊息、使用者的付款日期、報表資料等，至於執行哪個功能，由上層模組所傳遞之參數決定 使用者的 報表資料 付款日期 輸出到 錯誤訊息 磁碟機上 系統輸出 模組 輸 出

(7)偶發內聚力 一個模組內部要做好幾件工作，且每件工作都不相干 在設計時，偶發內聚力應盡量避免，例如可將個別的工作分別獨立出來自成一個模組，使各模組具有功能內聚力 實例： 列印資產負債表 計算所得稅 查詢庫存量

模組內聚力之判定決策樹 是 功能型 是 共用相 順序型 同資料 資料是否有 順序性？ 溝通型 否 是 流程 是否僅從事與問題相關的單一功能 程序型 否 控制 流程是否有 模組內各個活動的關係為何？ 順序性？ 暫時型 否 是 邏輯型 無關 功能邏輯是 否相關聯？ （非以上兩種） 偶發型 否

內聚力之評比因素與比較 依序為：功能、順序、溝通、程序、暫時、邏輯、偶發 可以接受的內聚力：功能、順序、溝通內聚力 良好的設計希望模組內達到功能內聚力，亦即一個模組僅處理單一功能

<b> 耦合力 一種衡量模組間相互關聯強度的方法 解決了一模組內的錯誤狀況，但在其他的模組內引起新的錯誤，這種現象稱為連鎖反應(Ripple Effect)。 解決連鎖反應之可行方法是儘量使一個模組不與其它模組糾結在一起，即讓每個模組儘可能的獨立，亦即降低模組間的耦合力。

五類耦合力 資料耦合力(Data Coupling) 資料結構耦合力(Stamp Coupling) 控制耦合力(Control Coupling) 共同耦合力(Common Coupling) 內容耦合力(Content Coupling)

(1)資料耦合力 模組間使用一些簡單型別資料作為兩模組間傳遞的參數 簡單型別資料如整數、浮點、位元等 實例： 計算房屋 貸款償還 計算客戶帳單 貸款總額 償還率 利率 計算房屋 貸款償還

(2)資料結構耦合力 模組間以資料結構(Data Structure)型別來做程式的介面，但並非每個模組均用到該資料結構之所有欄位。 實例： 有一個資料結構稱為 “租車”，有六個欄位： 牌照號碼 會員編號 使用汽油量……………用於計算油費 汽車款式 已開公里數 租借天數 ………用於計算基本汽車租金

資料結構耦合力實例 產生汽車 租金帳單 計算油費 計算基本 汽車租金 租車

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

(3)控制耦合力 當一模組傳遞旗標去控制另一個模組內的作業(內部邏輯) 例如有兩個模組：報表列印選擇與產生庫存報表或異動報表，前一個模組傳送旗標來控制下一個模組做輸入或輸出之動作，則這兩模組間具有控制耦合力。 報表列印 選擇 列印報表 選擇旗標 庫存報表 異動報表 產生庫存報表 或異動報表

控制耦合力有下列兩項缺點： 如果被呼叫的模組將拆成兩個以上的模組時，會因資料的糾結或是需瞭解呼叫模組等而不易達到目的。 撰寫呼叫模組時，如不了解被呼叫的模組，便不易著手撰寫程式，同時會增加程式測試的成本。

(4)共同耦合力 兩模組使用相同的資料區，且均能夠讀、 寫資料區內之資料 實例：下圖兩模組均可讀寫零件表之資料 更新物料 主檔 更新庫存 兩模組使用相同的資料區，且均能夠讀、 寫資料區內之資料 實例：下圖兩模組均可讀寫零件表之資料 更新物料 主檔 更新庫存 產生錯誤訊息旗標表 無此 料號

共同耦合力應儘量少用，主要原因為： 如果共用資料產生錯誤，則所有涉及之模組均會受影響。 使用共同資料區的模組名稱均模擬兩可， 不易定義，經常會造成困擾。 共用資料區內資料時常會被濫用，使模組的邏輯變得複雜，而不易了解。 模組變動時，不知那些資料會被牽動。

(5)內容耦合力 一個模組使用另一個模組內之部份程式碼，或改變其他模組內的局部變數。 內容耦合力具有下列特徵： (1) 一個模組以多個進入點(Multi-entry)的方式進入另一模組。 (2) 一個模組參考或改變其他模組的內部資料。 (3) 一個模組改變其他模組內部的執行過程。 此種做法在結構化設計的觀念上是被禁止的 模組　Ｈ： GO TO G1 模組　G： G1:

耦合力之評比因素與比較

耦合力愈弱愈好，可以接受的耦合力是資料耦合力與資料結構耦合力 良好的設計希望達到模組間的耦合力為資料耦合力，即模組間的溝通只使用簡單型別參數來溝通。 模組間的耦合力有時可能不只是單純的一種情形，可能存在兩種以上的耦合力 兩模組間的關係以較強的耦合力為準 例如兩個模組具有資料結構耦合力和共同耦合力的關係，則我們應以共同耦合力為準。

<c> 其他考量因素 一個良好的設計除了內聚力與耦合力的分析外，尚包括： 模組功能的分割：當模組太大、為了減少功能重複的模組、為了管理的需求、為了發展可重複使用的模組或發展易撰寫的模組等情況時，都是模組功能分割的適當時機。 模組除了原處理外，亦需考量錯誤、輔助訊息及例外狀況之處理。

2.4 結構化分析 彌補結構化設計之不足 結構化設計最終需產出模組化與結構化之程式和符合正規化之資料庫 起源於1970年代中期 結構化設計並未具體解決上述問題，因此結構化分析乃應運而生 起源於1970年代中期 利用圖形化文件工具(graphic documentation tools)進行企業流程及企業資料格式塑模

結構化分析之圖形化文件工具 包括： 事件(Event)及事件列(Event List) 資料流程圖(Data Flow Diagram, DFD) 環境圖(Context Diagram) 資料字典 (Data Dictionary, DD) 處理規格描述 (Process Specification, PS) 實體關係圖(Entity Relationship Diagram, ERD)

三、結構化分析與設計三部份 流程塑模 (chap 5) 資料塑模 (chap 6) 使用者介面塑模 (chap 15) 將需求分析階段完成的流程圖、活動圖或處理描述等，以資料流程圖進行流程塑模，接著轉成結構圖，再進一步進行模組設計。 資料塑模 (chap 6) 針對藍圖與資料詞彙，以實體關係圖進行資料塑模，轉成關聯表後，再進行正規化。 使用者介面塑模 (chap 15) 利用介面結構圖、介面藍圖與介面元件規格、介面狀態圖與轉換表等進行介面展示與描述，完成後再進行進階之使用者介面設計。

結構化分析與設計及塑模工具 需求塑模 流程塑模 資料塑模 使用者介面塑模 資料流程圖→結構圖→模組設計 使用者與 企業需求 需求擷取 實體關係圖→關聯表→正規化 需求轉換 使用者介面塑模 流程圖(或活動圖) ⊙處理描述 ⊙藍圖 ⊙資料詞彙 介面結構圖、介面藍圖與元件 規格、介面狀態圖與轉換表 使用者介面設計 程式設計 資料庫設計

結構化分析與設計 總結 主要是應用DFD及ERD等圖形化工具，將企業流程分解成具層級結構之小模組，並將企業資料格式分解成滿足正規化之資料庫。 有意義之文件模式。 使分析與設計過程更視覺化與標準化。 有較客觀的準則以供衡量 「好」的系統分析與設計及程式設計。 提升程式的一致性、再用性與可維護性。