模组间的耦合力.PPT

D、結構化技術 主要的結構化技術 結構化程式設計 (Structured Programming) 由上而下發展 (Top-down Development) 結構化設計 (Structured Design) 結構化分析 (Structured Analysis) 1.結構化程式設計 由Dijkstra (1969)提出 消除程式因goto而造成如麵條式的混亂狀態 強調任何程式邏輯均可由三種結構組成 循序(sequence)：簡單命令式的指令如 COMPUTE, READ, WRITE 與代數指令如X=Y+Z。 選擇(condition)：需做決策時，用 IF-THEN-ELSE 指令與 CASE 指令。 重複(repetition)：當需反覆時，用 DO-WHILE 與 DO-UNTIL 指令。 結構化程式之邏輯概念 2.由上而下發展 起源於1960年代末期 強調把大問題依序分解成具層級結構之小模組，並由上層模組開始進行程式設計及測試 層級化設計 延緩考慮細節問題 由上而下設計 把大而複雜的問題分解成較小且較簡化的問題，直到原來的問題已可用一些容易且可理解的小問題組合來代表。例： 先將主程式分為A、B、C三個子程式 再劃分子程式A為A1與A2，子程式C為C1與C2 3.結構化設計 起源於1960年代末期，其概念先於結構化分析 主要目的：將資訊系統依由上而下發展，並將程式設計模組化與結構化。 決定系統應有哪些模組？ 模組間以何種相互聯繫才能最有效解決問題？ 特別強調系統的可維護性 模組(Module) 即副程式，為一連串指令的集合，包括： (1)模組名稱：唯一且應有意義，應能表達模組的功能 (2)輸入：模組被呼叫時，呼叫模組所需輸入的資料 (3)輸出：模組執行後所產生的輸出結果 (4)處理邏輯：為達成模組功能，模組內所需具備的執行程序與邏輯。 (5)內部資料：該模組獨自擁有而不與其他模組共用的資料 3.1 結構化設計之經驗法則 模組大小 基於小模組較大模組容易維護與修改，故結構化設計較傾向用小模組。 一般來說，小模組約包含 200 個以下的程式指令 例如，可列印在1～2頁之A4紙內 控制間距 一個模組不要同時控制太多即時模組，因為控制太多模組將不利瞭解與維護。 最多不要超過9個(Magic Number 7±2) 控制範圍 為縮小影響範圍與控制範圍，當甲模組之行為被乙模組所影響，則甲模組應從屬於乙模組。 3.2 結構化設計之評估準則 要達到良好的系統設計與提升模組的品質，需考慮： 模組的內聚力(cohesion)：一個模組內部所做事情的相關程度。 模組間的耦合力(coupling)：一個系統內部各模組之間的相關程度。 其他考慮因素：如功能分割、錯誤訊息等。 內聚力 衡量模組內部工作相關程度的方法 也就是衡量模組完成一件單一、且定義清楚之工作的程度 良好的設計希望一個模組僅處理單一功能 功能內聚力：一個模組只做一件事情 順序內聚力：模組內具有多個功能或處理多件事情，且一項功能的輸出立即成為下一個功能的輸入、共用相同的資料 耦合力 一種衡量模組間相互關聯強度的方法 解決了一模組內的錯誤狀況，但在其他的模組內引起新的錯誤，這種現象稱為連鎖反應(Ripple Effect)。 解決連鎖反應之可行方法是儘量使一個模組不與其它模組糾結在一起，即讓每個模組儘可能的獨立，亦即降低模組間的耦合力。 良好的設計希望即模組間的溝通只使用簡單型別之參數來溝通。 其他考量因素 一個良好的設計除了內聚力與耦合力的分析外，尚包括： 模組功能的分割：當模組太大、為了減少功能重複的模組、為了管理的需求、為了發展可重複使用的模組或發展易撰寫的模組等情況時，都是模組功能分割的適當時機。 模組除了原處理外，亦需考量錯誤、輔助訊息及例外狀況之處理。 4.結構化分析 彌補結構化設計之不足 結構化設計最終需產出模組化與結構化之程式和符合正規化之資料庫 結構化設計並未具體解決上述問題，因此結構化分析乃應運而生 起源於1970年代中期 利用圖形化文件工具(graphic documentation tools)進行企業流程及企業資料格式塑模 結構化分析之圖形化文件工具 事件(Event)及事件列(Event List) 資料流程圖(Data Flow Diagram, DFD) 環境圖(Context Diagram) 資料字典 (Data Dictionary, DD) 處理規格描述 (Process Specification, PS) 實體關係圖(Entity Relationship Diagram, ERD) 結構化分析與設計及塑模工具 結構化分析與設計 總結 主要是應用DFD及ERD等圖形化工具，將企業流程分解成具層級結構之小模組，並將企業資料格式分解成滿足正