模组的内聚力cohesion.PPT

D、結構化技術 結構化技術之概念 主要的結構化技術 結構化程式設計 由上而下發展 結構化設計 經驗法則、評估準則、文件工具 結構化分析 結構化分析與設計做法 1. 結構化技術之概念 系統開發模式 強調系統開發過程中應有之步驟以及執行 程序 不涉及每個步驟可支援的方法或技術 結構化技術 (又稱軟體工程技術) 起源於1960年代末期 主要強調如何應用一些概念、策略與工具，以提升系統分析與設計、程式設計與測試之效率與效能等。 2. 主要的結構化技術 結構化程式設計 (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、B、C三個子程式 再劃分子程式A為A1與A2，子程式C為C1與C2 由下而上設計 先獨立發展各個細部的子程式X, Y, Z 再將X, Y, Z組成較高的子程式A1 經過逐次整合成為完整系統 由上而下整合測試 在低階模組尚未完成程式撰寫前，先行測試系統的高階模組 由頂端模組開始測試，而以虛擬模組(Dummy Module)暫代下一層未完成的模組 系統的錯誤若在上階層，則可及早發現。 需要製造虛擬模組。 2.3 結構化設計 起源於1960年代末期，其概念先於結構化分析 主要目的：將資訊系統依由上而下發展，並將程式設計模組化與結構化。 決定系統應有哪些模組？ 模組間以何種相互聯繫才能最有效解決問題？ 特別強調系統的可維護性 模組(Module) 即副程式，為一連串指令的集合，包括： (1)模組名稱：唯一且應有意義，應能表達模組的功能 (2)輸入：模組被呼叫時，呼叫模組所需輸入的資料 (3)輸出：模組執行後所產生的輸出結果 (4)處理邏輯：為達成模組功能，模組內所需具備的執行程序與邏輯。 (5)內部資料：該模組獨自擁有而不與其他模組共用的資料 結構化設計之法則與工具 包括設計經驗法則、評估準則與文件工具等 經驗法則 模組大小、控制間距、控制範圍 評估準則 模組內部所做事情的相關程度(內聚力) 模組間的相關程度(耦合力) 有很好的功能分割 文件工具 結構圖(Structure Chart) HIPO圖 (Hierarchical Input Process Output) 模組規格描述、資料字典 2.3.1 結構化設計之經驗法則 模組大小 基於小模組較大模組容易維護與修改，故結構化設計較傾向用小模組。 一般來說，小模組約包含 200 個以下的程式指令 例如，可列印在1～2頁之A4紙內 控制間距 一個模組不要同時控制太多即時模組，因為控制太多模組將不利瞭解與維護。 最多不要超過9個(Magic Number 7±2) 控制範圍 為縮小影響範圍與控制範圍，當甲模組之行為被乙模組所影響，則甲模組應從屬於乙模組。 2.3.2 結構化設計之評估準則 要達到良好的系統設計與提升模組的品質，需考慮： 模組的內聚力(cohesion)：一個模組內部所做事情的相關程度。 模組間的耦合力(coupling)：一個系統內部各模組之間的相關程度。 其他考慮因素：如功能分割、錯誤訊息等。 2.3.2.1 內聚力 衡量模組內部工作相關程度的方法 也就是衡量模組完成一件單一、且定義清楚之工作的程度，可分為七種： 功能內聚力(Functional Cohesion) 順序內聚力(Sequential Cohesion) 溝通內聚力(Communication Cohesion) 程序內聚力(Pr