《结构化技术》PPT课件.ppt

D-1,D、結構化技術,結構化技術之概念 主要的結構化技術 結構化程式設計 由上而下發展 結構化設計 經驗法則、評估準則、文件工具 結構化分析 結構化分析與設計做法,D-2,1. 結構化技術之概念,系統開發模式 強調系統開發過程中應有之步驟以及執行 程序 不涉及每個步驟可支援的方法或技術 結構化技術 (又稱軟體工程技術) 起源於1960年代末期 主要強調如何應用一些概念、策略與工具，以提升系統分析與設計、程式設計與測試之效率與效能等。,D-3,2. 主要的結構化技術,結構化程式設計 (Structured Programming) 由上而下發展 (Top-down Development) 結構化設計 (Structured Design) 結構化分析 (Structured Analysis),D-4,2.1 結構化程式設計,由Dijkstra (1969)提出 消除程式因goto而造成如麵條式的混亂狀態 強調任何程式邏輯均可由三種結構組成 循序(sequence)：簡單命令式的指令如 COMPUTE, READ, WRITE 與代數指令如X=Y+Z。 選擇(condition)：需做決策時，用 IF-THEN-ELSE 指令與 CASE 指令。 重複(repetition)：當需反覆時，用 DO-WHILE 與 DO-UNTIL 指令。,D-5,結構化程式之邏輯概念,D-6,2.2 由上而下發展,起源於1960年代末期 強調把大問題依序分解成具層級結構之小模組，並由上層模組開始進行程式設計及測試 層級化設計 延緩考慮細節問題： 包含三個相關但不同方面的由上而下： 由上而下設計(Top-down Design) 由上而下編碼(Top-down Coding)：當高階模組被設計完成後，就先對高階模組撰寫程式 由上而下整合測試 (Top-down Integration Test),D-7,由上而下設計,把大而複雜的問題分解成較小且較簡化的問題，直到原來的問題已可用一些容易且可理解的小問題組合來代表。例： 先將主程式分為A、B、C三個子程式 再劃分子程式A為A1與A2，子程式C為C1與C2,Main,B,C,1,2,C2,C1,D-8,由下而上設計,先獨立發展各個細部的子程式X, Y, Z 再將X, Y, Z組成較高的子程式A1 經過逐次整合成為完整系統,D-9,由上而下整合測試,在低階模組尚未完成程式撰寫前，先行測試系統的高階模組 由頂端模組開始測試，而以虛擬模組(Dummy Module)暫代下一層未完成的模組 系統的錯誤若在上階層，則可及早發現。 需要製造虛擬模組。,D-10,2.3 結構化設計,起源於1960年代末期，其概念先於結構化分析 主要目的：將資訊系統依由上而下發展，並將程式設計模組化與結構化。 決定系統應有哪些模組？ 模組間以何種相互聯繫才能最有效解決問題？ 特別強調系統的可維護性,D-11,模組(Module),即副程式，為一連串指令的集合，包括： (1)模組名稱：唯一且應有意義，應能表達模組的功能 (2)輸入：模組被呼叫時，呼叫模組所需輸入的資料 (3)輸出：模組執行後所產生的輸出結果 (4)處理邏輯：為達成模組功能，模組內所需具備的執行程序與邏輯。 (5)內部資料：該模組獨自擁有而不與其他模組共用的資料,D-12,結構化設計之法則與工具,包括設計經驗法則、評估準則與文件工具等 經驗法則 模組大小、控制間距、控制範圍 評估準則 模組內部所做事情的相關程度(內聚力) 模組間的相關程度(耦合力) 有很好的功能分割 文件工具 結構圖(Structure Chart) HIPO圖 (Hierarchical Input Process Output) 模組規格描述、資料字典,D-13,2.3.1 結構化設計之經驗法則,模組大小 基於小模組較大模組容易維護與修改，故結構化設計較傾向用小模組。 一般來說，小模組約包含 200 個以下的程式指令 例如，可列印在12頁之A4紙內 控制間距 一個模組不要同時控制太多即時模組，因為控制太多模組將不利瞭解與維護。 最多不要超過9個(Magic Number 72) 控制範圍 為縮小影響範圍與控制範圍，當甲模組之行為被乙模組所影響，則甲模組應從屬於乙模組。,D-14,2.3.2 結構化設計之評估準則,要達到良好的系統設計與提升模組的品質，需考慮： 模組的內聚力(cohesion)：一個模組內部所做事情的相關程度。 模組間的耦合力(coupling)：一個系統內部各模組之間的相關程度。 其他考慮因素：如功能分割、錯誤訊息等。,D-15,2.3.2.1 內聚力,衡量模組內部工作相關程度的方法 也就是衡量模組完成一件單一、且定義清楚之工作的程度，可分為七種： 功能內聚力(Functional Cohesion) 順序內聚力(Sequential Cohesion) 溝通內聚力(Communication Cohesion) 程序內聚力(Procedural Cohesion) 暫時內聚力(Temporal Cohesion) 邏輯內聚力(Logical Cohesion) 偶發內聚力(Coincidental Cohesion),D-16,(1) 功能內聚力,一個模組只做一件事情 亦即每個模組僅具有唯一的功能 例如：以下的三個處理均僅針對一件事，若分別成為一個模組，則具有功能內聚力,檢查身分證 號碼正確性,以異動檔 更新庫存主檔,計算營業稅,D-17,(2) 順序內聚力,模組內具有多個功能或處理多件事情，且一項功能的輸出立即成為下一個功能的輸入、共用相同的資料 圖例：,讀取某數值,計算之平方,將計算所得結果 顯示於螢幕上,D-18,(3) 溝通內聚力,模組內具有多個功能或處理多件事情，且這些功能使用相同的資料(輸入)，但執行順序沒有相關性。 圖例：,查詢產品規格,查詢庫存數量,查詢儲存架位,產品資料,D-19,(4) 程序內聚力,模組內具有多個功能或處理多件事情，這些功能必須按照一定的順序來執行，且不共用相同資料 這些功能群集在一個模組內，是為了確保其執行順序 實例：假設一提款系統之處理如下,檢查 密碼,讀取提款 金額,讀取提款機 餘額,計算客戶 存摺餘額,D-20,(5) 暫時內聚力,模組內具有多個功能或處理多件事情，但是這些功能僅僅在時序上有所關聯，也就是需在同一時間內完成，但執行上無先後順序 實例：系統開始時，初始狀態之設定如下,設定日期格式,指定路徑,清除所有變數,設定變數啟始值,D-21,(6) 邏輯內聚力,模組內具有多個邏輯上相關聯的功能。 實例：一系統輸出模組負責輸出錯誤訊息、使用者的付款日期、報表資料等，至於執行哪個功能，由上層模組所傳遞之參數決定,系統輸出模組,錯誤 訊息,使用者的 付款日期,報表 資料,輸出到 印表機上,輸出,D-22,(7) 偶發內聚力,一個模組內部要做好幾件工作，且每件工作都不相干 在設計時，偶發內聚力應盡量避免，例如可將個別的工作分別獨立出來自成一個模組，使各模組具有功能內聚力 實例：,列印資產負債表,計算所得稅,查詢庫存量,D-23,模組內聚力之判定決策樹,否,是否僅從事與問題相關的單一功能,模組內各個活動的關係為何？,是,功能型,資料是否有 順序性？,流程是否有 順序性？,無關 (非以上兩種),共用相 同資料,流程 控制,功能邏輯是 否相關聯？,是,否,順序型,溝通型,是,否,程序型,暫時型,是,否,邏輯型,偶發型,D-24,內聚力之評比因素與比較,依序為：功能、順序、溝通、程序、暫時、 邏輯、偶發 可以接受的內聚力：功能、順序、溝通內聚力 良好的設計希望模組內達到功能內聚力，亦即一個模組僅處理單一功能,D-25,2.3.2.2 耦合力,一種衡量模組間相互關聯強度的方法 解決了一模組內的錯誤狀況，但在其他的模組內引起新的錯誤，這種現象稱為連鎖反應(Ripple Effect)。 解決連鎖反應之可行方法是儘量使一個模組不與其它模組糾結在一起，即讓每個模組儘可能的獨立，亦即降低模組間的耦合力。,D-26,五類耦合力,資料耦合力(Data Coupling) 資料結構耦合力(Stamp Coupling) 控制耦合力(Control Coupling) 共同耦合力(Common Coupling) 內容耦合力(Content Coupling),D-27,(1) 資料耦合力,模組間使用一些簡單型別資料作為兩模組間傳遞的參數 簡單型別資料如整數、浮點、位元等 實例：,D-28,(2) 資料結構耦合力,模組間以資料結構(Data Structure)型別來傳遞參數，但並非每個模組均用到該資料結構之所有欄位。 實例： 有一個資料結構稱為 “租車”，有六個欄位： 牌照號碼 會員編號 使用汽油量用於計算油費 汽車款式 已開公里數 用於計算基本汽車租金 租借天數,D-29,資料結構耦合力之評論,可能產生以下的問題： 雖然每一個模組可能只用到局部的欄位，但只要資料結構內任一個欄位修改過，則所有的相關模組均會受影響。 每一個模組使用了比實際需要更多的記憶體空間。 解決方法： 僅傳遞所要用到的欄位，而不必傳遞整個資料結構，則資料結構耦合力就可變成資料耦合力。,D-30,(3) 控制耦合力,一模組傳遞旗標去控制另一個模組內的作業 (內部邏輯) 例如有兩個模組： 報表列印選擇與產生 庫存報表或異動報表 ，前一個模組傳送旗 標來控制下一個模組 做輸入或輸出之動作 ，則這兩模組間具有 控制耦合力。,D-31,控制耦合力之評論,控制耦合力有下列兩項缺點： 如果被呼叫的模組將拆成兩個以上的模組時，會因資料的糾結或是需瞭解呼叫模組等而不易達到目的。 撰寫呼叫模組時，如不了解被呼叫的模組，便不易著手撰寫程式，同時會增加程式測試的成本。,D-32,(4) 共同耦合力,兩模組使用相同的資料區，且均能夠讀、寫資料區內之資料 實例：下圖兩模組均可讀寫零件表之資料,D-33,共同耦合力之評論,共同耦合力應儘量少用，主要原因為： 如果共用資料產生錯誤，則所有涉及之模組均會受影響。 使用共同資料區的模組名稱均模擬兩可， 不易定義，經常會造成困擾。 模組變動時，不知那些資料會被牽動。,D-34,(5) 內容耦合力,一個模組使用另一個模組內之部份程式碼，或改變其他模組內的局部變數。具有下列特徵： 模組以多個進入點(Multi-entry)的方式進入另一模組 模組參考或改變其他模組的內部資料。 模組改變其他模組內部的執行過程。 此種做法在結構化設計的觀念上是被禁止的,D-35,耦合力之評比因素與比較,D-36,耦合力總結,耦合力愈弱愈好，可以接受的耦合力是資料耦合力與資料結構耦合力 良好的設計希望達到模組間的耦合力為資料耦合力，即模組間的溝通只使用簡單型別之參數來溝通。 模組間的耦合力有時可能不只是單純的一種情形，可能存在兩種以上的耦合力 兩模組間的關係以較強的耦合力為準 例如兩個模組具有資料結構耦合力和共同耦合力的關係，則我們應以共同耦合力為準。,D-37,2.3.2.3 其他考量因素,一個良好的設計除了內聚力與耦合力的分析外，尚包括： 模組功能的分割：當模組太大、為了減少功能重複的模組、為了管理的需求、為了發展可重複使用的模組或發展易撰寫的模組等情況時，都是模組功能分割的適當時機。 模組除了原處理外，亦需考量錯誤、輔助訊息及例外狀況之處理。,D-38,2.3.3 結構化設計之文件工具,結構圖(Structure Chart) HIPO圖 (Hierarchical Input Process Output) 模組規格描述,* 計算送貨明細加總金額 * Begin 移動送貨單的送貨明細資料到第一筆記錄 將送貨單的送貨明細加總金額初值設為0 當送貨單的送貨明細資料還沒超過最後一筆時， 重複以下動作 Begin 送貨單的送貨明細加總金額送貨明細(數量* 售價)原送貨單的送貨明細加總金額 移動送貨單的送貨明細資料到下一筆記錄 End; End;,D-39,2.4 結構化設計,彌補結構化設計之不足 結構化設計最終需產出模組化與結構化之程式和符合正規化之資料庫 結構化設計並未具體解決上述問題，因此結構化分析乃應運而生 起源於1970年代中期 利用圖形化文件工具(graphic documentation tools)進行企業流程及企業資料格式塑模,D-40,結構化分析之圖形化文件工具,事件(Event)及事件列(Event List) 資料流程圖(Data Flow Diagram, DFD) 環境圖(Context Diagram) 資料字典 (Data Dictionary, DD) 處理規格描述 (Process Specification, PS) 實體關係圖(Entity Relationship Diagram, ERD),D-41,3. 結構化分析與設計做法,流程塑模 (chap 5) 將需求分析階段完成的流程圖、處理描述等，以資料流程圖進行流程塑模，接著轉成結構圖，再進一步進行模組設計。 資料塑模 (chap 6) 針對藍圖與資料詞彙，以實體關係圖進行資料塑模，轉成關聯表後，再進行正規化。 使用者介面塑模 (chap 15) 利用介面結構圖、介面藍圖與介面元件規格、介面狀態圖與轉換