第九章 實作及整合階段.pptVIP

第九章 實作及整合階段 軟體工程 -物件導向程式設計與UML系統分析實作 * 議題 簡介 實作及整合 實作與整合階段的測試 圖形介面的整合測試 產品測試 接受度測試 實作與整合階段的CASE工具 整合環境 * 簡介 實作階段進行每一個模組(或物件)的實作，也就是程式撰寫(Coding)的工作。 整合階段，所有的模組會整合成一個系統並進行測試。 實作與整合階段的工作應該要並行進行 。 * 實作及整合 待解決的難題 提供模組測試用的「stub」 錯誤點隔離(Fault Isolation) 方式如下列所示 由上而下之實作與整合 由下而上之實作與整合 三明治之實作與整合 物件導向軟體實作與整合的方式 * 模組流程圖 m1 m2 m3 m4 m5 m6 m7 m8 m9 m10 m11 m12 m13 m1 m2 m3 m4 m5 m6 m7 m8 m9 m10 m11 m12 m13 邏輯模組 操作模組 連結邏輯與操作模組的介面 * 由上而下(Top-Down)的實作與整合 若模組mTop呼叫模組mDown，則mTop會在mDown之前進行實作及整合。 根據所設計的模組流程圖，其實作及整合的順序有兩種 m1、m2、m3、m4、m5、m6、m7、m8、m9、m10、m11、m12及m13； 以群組進行編碼，則為 m1、「m2、m5、m8」、「 m3、m4、m6、m9」、「 m7、m10、m11、m12、m13 」 * 由上而下(Top-Down)的實作與整合 優點 在軟體開發早期就會顯示設計上的主要的缺失。 缺點 需要重複使用的模組可能無法進行適當地測試。 例如，底層的操作模組 * 由下而上(Bottom-Up)的實作及整合 若模組mUp呼叫模組mBottom，則mBottom會較mUp先進行實作與整合。 根據所設計的模組流程圖，其實作及整合的順序有兩種 m12、m13、m8、m9、m10、m11、m5、m6、m7、m2、m3、m4及m1； 以群組進行編碼，則為「m8、m5及m2」、「m9、m6及m3」、「m12、m13、m10、m11及m7」，m4、m1 * 由下而上(Bottom-Up)的實作及整合 優點 default isolation的優勢 操作模組可以仔細測試 缺點 主要的設計錯誤會很遲才會在整合階段中發現，而邏輯模組是最後整合的模組。 * 三明治(Sandwich)實作及整合 根據所設計的模組流程圖，其實作及整合的方式為 m1、m2、m3、m4、m7、m10為邏輯模組 ，以由上而下方式進行實作與整合。 m5、m6、m8、m9、m11、m12及m13，實作與整合方法是由下而上。 當所有的模組已整合完成時，在二模組群組間的介面會一個個進行測試 * 各種實作與整合方式的優缺點 * 物件導向軟體系統的實作及整合 由上而下的方式進行 物件內的每一個方法將如上述傳統由上而下實作與整合的方式，撰寫相對的stubs 由上而下的方式進行 首先物件不會傳送任何的訊息給其他實作與整合的物件， 爾後物件會傳送訊息至其他物件進行實作與整合， 依此方式進行，直到所有的物件實作整合完成為止。 三明治實作整合的方法 物件視為如前述操作模組，來進行由上而下的實作與整合， 然後非物件的邏輯模組以由上而下的方式實作與整合 ， 最後再將其與相關物件整合。 * 實作與整合階段的測試 對於每一個新的模組而言 單元測試(Unit Test) 軟體擁有圖形化使用者介面 圖形介面整合測試(Integration Tesing) 產品測試(Product Testing) 接受度測試(Acceptance Testing) * 圖形介面的整合測試 撰寫測試案例(Test Cases) 進行回歸性測試(regression testing) 提供GUI介面自動化測試的工具 以錄製撥放(Record and Replay) 方式 特定的描述語言(Script)撰寫測試案例 產品 IBM Rational的Robot (Windows Platform) Mercury Interactive 的X Runner (UNIIX) Seapine的QA Wizard for Web * 產品測試 為了要保證接受度測試（acceptance testing）成功，SQA小組必須要進行軟體產品測試（product testing） 以相當接近接受度測試的方式 採用黑箱( black-box )測試 強健性( robustness )測試 壓力( stress )測試 巨量( volume )測試 * 接受度測試 客戶根據接受度測試（acceptance testing）來確認軟體產品所有的特性，是否符