Transcript 第九章實作及整合階段

第九章 實作及整合階段
軟體工程
-物件導向程式設計與UML系統分析實作
議題








簡介
實作及整合
實作與整合階段的測試
圖形介面的整合測試
產品測試
接受度測試
實作與整合階段的CASE工具
整合環境
簡介



實作階段進行每一個模組(或物件)的實
作，也就是程式撰寫(Coding)的工作。
整合階段，所有的模組會整合成一個
系統並進行測試。
實作與整合階段的工作應該要並行進
行。
實作及整合
待解決的難題
 提供模組測試用的「stub」
 錯誤點隔離(Fault Isolation)
方式如下列所示
 由上而下之實作與整合
 由下而上之實作與整合
 三明治之實作與整合
 物件導向軟體實作與整合的方式
模組流程圖
m1
m1
m2
m3
m4
m5
m6
m8
m9
m3
m2
m7
m6
m5
m10
m12
m11
m4
m8
m7
m9
m10
m11
m13
邏輯模組
操作模組
連結邏輯與操作模組的介面
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）來確
認軟體產品所有的特性，是否符合開發人員與其
客戶所擬定的需求內容。
四個主要的任務





測試正確性、
強健性、
執行效能、
撰寫文件
一旦軟體產品通過接受度測試，開發人員的任務
即告完成，往後軟體產品任何的修改動作均會在
維護期間進行。
實作與整合階段
的CASE工具


元件整合 、版本控制工具、建構工具和組
態管理工具
前端工具(Front-end Tool)


在軟體發展的早期程序階段包括需求、規劃、
計畫及設計階段的CASE工具 。
後端工具(Back-end Tool)

協助開發、整合及維護階段的CASE工具
整合環境

工具整合

文件撰寫，程式編碼(Coding)、編譯(Compiling)、連
結(Linking)、除錯(Debugging)、版本控制(Version
Control)、建構(Build)與組態(Configure)等。
Version Control
Release
Editor
Compiler
linker
Debugger
總結


實作和整合系統時，常用的三種方法
1.由上而下，
2.由下而上，
3.三明治，
以及在物件導向語言方面應採用和管理的
方法，且探討整合時該採用那些測試方法，
最後探討CASE tool再實作和整合階段時的
用途。