Foundations of Computer Science Chapter 10 軟體工程

Presentation on theme: "Foundations of Computer Science Chapter 10 軟體工程"— Presentation transcript:

1 Foundations of Computer Science Chapter 10 軟體工程
計算機概論 第二版 Foundations of Computer Science Chapter 10 軟體工程

2 10.1 軟體生命週期 軟體工程（software engineering）的基本觀念就是軟體生命週期（software lifecycle）。 圖 軟體生命週期 p.254

3 軟體生命週期中的開發過程包含了四個階段：分析、設計、實作與測試。應用於開發步驟的模型有：瀑布模型與遞增模型。
瀑布模型（waterfall model）：除非前一個階段完成，否則下一個階段就無法開始。 遞增模型（incremental model）：開發團隊首先完成整個系統的簡單版本，除非現有系統已能正常運作，否則開發團隊就不會新增更多的功能。這樣的過程會持續到所需的功能都被加入為止。 p.254

4 圖 瀑布模型 p.255

5 圖 瀑布模型 p.256

6 10.2 分析階段 程序導向分析 倘若實作階段採用程序式語言，那麼分析過程就會使用程序導向分析（procedure-oriented analysis），有數種建模工具可供使用。 資料流程圖（data flow diagrams）：用以顯示系統中資料的流動狀況。 實體－ 關係圖（entity-relationship diagram）：此圖被應用於資料庫設計中。 狀態流程圖（state diagrams）：使用於系統實體因某事件發生而改變其狀態流程。 p.256

7 圖 資料流程圖範例 p.256

8 圖 狀態流程圖範例 p.257

9 若實作階段採用物件導向式語言，那麼分析過程就會使用物件導向分析（object-oriented analysis）。
使用案例圖（use-case diagram）：提供系統使用者的觀點，它顯示出使用者如何與系統連繫。 分析階段的下一步就是為系統產生類別圖式（class diagram）。 狀態圖（state chart）：扮演著與程序導向分析中的狀態流程圖相同的角色。 p.257

10 圖 使用案例圖範例 p.258

11 圖 類別圖式範例 p.258

12 10.3 設計階段 設計階段（design phase）中，系統的所有組成單元都會被定義出來。 程序導向式設計
10.3 設計階段 設計階段（design phase）中，系統的所有組成單元都會被定義出來。 程序導向式設計 在程序導向式設計（procedure-oriented design）中，我們需要設計程序與資料。 結構圖表（structure chart）：程序導向設計常用來列舉模組間關聯的工具。 模組化（modularity）：意指將一個大的專案分割成許多易懂、易於使用的小部分。當系統被分割成模組時，有兩點必須要注意：耦合與凝聚。 p.259

13 圖 結構圖表 p.259

14 耦合（coupling）是用來度量兩個模組間的緊密程度，愈緊密的耦合，彼此間就愈不獨立。
凝聚（cohesion ）是度量一個系統中各個模組間的關聯性有多接近。在軟體系統中，我們希望模組間的凝聚愈大愈好。 物件導向設計 在物件導向設計（object-oriented design）中，設計階段接著仔細製作類別的細節。 p.260

15 圖 類別的屬性與方法範例 p.260

16 10.4 實作階段 瀑布模型中，於設計階段完成後，實作階段（implementation phase）就會接著開始。 語言的選擇 軟體品質
10.4 實作階段 瀑布模型中，於設計階段完成後，實作階段（implementation phase）就會接著開始。 語言的選擇 軟體品質 軟體品質（software quality）被分成三個評估基準：可執行性、可維護性與可移動性。 p.261

17 圖 品質因子 p.261

18 10.5 測試階段 測試階段（testing phase）的目標就是找出錯誤。 玻璃箱測試
10.5 測試階段 測試階段（testing phase）的目標就是找出錯誤。 玻璃箱測試 玻璃箱測試〔glass-box testing；或白箱測試（white-box testing）〕植基於軟體內部結構已知。測試的目標就是檢查軟體所有組成元件，是否符合所設計的要求。基本路徑測試與控制結構測試是其中兩種測試方法。 基本路徑測試（basis path testing）：會產生一組測試數據，可 以讓軟體的每個敘述最少執行一次。 p.263

19 圖 軟體測試 p.263

20 範例 10.1 為顯示基本路徑測試概念與找出程式中的獨立路徑，假設系統是由單一程式組成，且此程式僅有單一迴圈，以 UML 畫於圖 10.12。 p.264

21 圖 基本路徑測試範例 p.264

22 控制結構測試（control structure testing）所包含的測試較基本路徑測試要廣泛，此法使用數種不同的測試種類。 條件測試
資料流程測試 迴圈測試 黑箱測試 黑箱測試（black box testing）命名的由來是因為所測試的軟體內容未知，也不知道它是如何運作的。 徹底測試 隨機測試 邊界值測試 p.265

23 10.6 文件 為能正確的使用軟體，與有效的進行軟體的維護，文件（documentation）的製作是有需要的。軟體的文件可分為三個部分：使用者文件、系統文件與技術文件。 使用者文件 使用者需要文件以正確的執行軟體，傳統稱之為使用手冊。 系統文件 系統文件（system documentation）定義軟體本身，它被撰寫成可以讓非原始開發者用以維護、修改此軟體。 技術文件 技術文件描述軟體系統的安裝與服務。 文件的製作與更新是一個不停歇的過程。 p.266