軟體工程期末複習

文章目錄

• 一、軟體工程概述
• • 軟體的概念與特點
  • 軟體危機與軟體工程（概念）
  • 軟體開發過程
  • 軟體過程模型
  • • （一）瀑布模型
    • （二）增量模型
    • （三）螺旋模型
    • （四）噴泉模型
    • （五）原型模型
  • 軟體工程概述總結
• 二、軟體需求工程
• • 軟體需求的基本概念
  • 需求工程的基本活動
  • 需求分析與模組化技術（資料流圖）
  • • （一）結構化分析（SA）方法
    • （二）面向對象的分析（OOA）方法
  • 軟體需求工程總結
• 三、需求分析用例圖
• • 用例模組化執行個體
• 四、面向對象分析與設計
• • 靜态模型
  • • （一）類圖（舉例POS機系統）
  • 動态模型
  • • （一）狀态圖
    • （二）順序圖
• 五、軟體設計
• • 軟體設計階段任務
  • 軟體設計過程
  • 系統結構性模型——層次結構模型
  • 子產品分解
  • MVC設計模式
• 六、軟體測試
• • 軟體測試的基本概念
  • 軟體測試的特點和基本原則
  • 白盒測試法
  • • （一）語句覆寫
    • （二）判定覆寫
    • （三）條件覆寫
    • （四）判定-條件覆寫
  • 黑盒測試法
  • • （一）等價分類法
    • （二）邊界值分析法
  • 軟體測試的概念
  • • （一）單元測試
    • （二）內建測試
    • （三）确認測試
    • （四）系統測試
• 七、軟體維護
• • 軟體維護的基本概念

一、軟體工程概述

軟體的概念與特點

軟體 = 程式+資料+文檔

軟體是程式，以及開發、使用和維護程式所需的所有文檔。

程式：計算機可以接受的一系列指令，運作時可以提供所要求的功能和性能。

資料：使得程式能夠适當地操作資訊的資料結構。

文檔：描述程式的研制過程、方法和使用的圖文資料。

特點：

1. 複雜性
2. 不可見性
3. 一緻性
4. 可變性

軟體危機與軟體工程（概念）

軟體危機： 反應在軟體可靠性沒有保障、軟體維護工作量大、費用不斷上升、進度無法預測、成本增長無法控制、程式、人員無限度地增加等各個方面，以至于形成人們難以控制軟體開發的局面。

主要展現為兩方面：

1.軟體産品品質低劣，甚至在開發過程中就夭折。

2.軟體生産效率低，無法滿足需要。

軟體工程：

1. 将系統性的、規範化的、可定量的方法應用于軟體的開發、運作和維護，即工程化應用到軟體上；
2. 對 1 中所述方法的研究。

目标： 提高軟體的品質和軟體的生産率。

軟體工程三要素： 過程、方法、工具。

軟體開發過程

軟體開發過程： 問題定義–》需求開發–》軟體設計–》軟體構造–》軟體測試–》軟體維護

問題定義：

需求開發：

軟體設計：

軟體構造：

軟體測試：

軟體維護：

軟體過程模型

定義： 是描述軟體過程中各種活動如何執行的描述。

（一）瀑布模型

定義： 将基本的開發活動看成是一系列界限分明的獨立階段，這是一種計劃驅動的軟體過程，有利于規範軟體開發活動。

以預測性為原則

以文檔驅動開發過程

以過程控制為核心

特點：

1. 活動間具有順序性和依賴性；
2. 推遲實作觀點；
3. 品質保證觀點；
4. 缺少對變化的适應;

适用範圍：

瀑布模型适用于功能、性能明确、完整、無重大變化的軟體系統的開發

（二）增量模型

定義： 在每一個新的釋出中逐漸增加功能直到構造全部功能。

（三）螺旋模型

定義： 螺旋模型将瀑布模型與增量模型結合起來,并加入了風險分析。

特點：

1. 瀑布模型+增量模型+風險分析
2. 疊代過程

（四）噴泉模型

定義： 以使用者需求為動力，以對象為驅動的模型，主要用于采用面向對象技術的軟體開發項目。

其開發過程自下而上周期的各階段是互相重疊和多次反複的，可以并行工作。

優點：

1. 各個階段沒有明顯的界限，開發人員可以同步進行開發
2. 提高軟體項目開發效率，節省開發時間

缺點：

由于各個開發階段是重疊的，是以在開發過程中需要大量的開發人員，不利于項目的管理

（五）原型模型

定義： 原型是一個部分開發的産品，用于加強對系統的了解，有助于明确需求和選擇可行的設計政策。

特點：

1. 快速開發工具
2. 循環
3. 低成本

軟體工程概述總結

二、軟體需求工程

軟體需求的基本概念

定義： 1)使用者解決問題或達到目标所需條件或權能(Capability)。 (2)系統或系統部件要滿足合同、标準、規範或其它正式規定文檔所需具有的條件或權能。 (3)一種反映上面(1)或(2)所述條件或權能的文檔說明。

軟體需求的任務：

确定系統的綜合要求 ：确定系統功能、性能和運作要求

分析系統的資料要求 ：資料要求和資料處理要求

導出系統的邏輯模型 ：采用結構化分析方法或面向對象分析方法導出系統邏輯模型

修正系統的開發計劃 ：對系統成本和進度進行估算，進一步修改開發計劃

需求工程的基本活動

1. 擷取需求
2. 需求分析與模組化
3. 需求規格說明
4. 确認需求
5. 需求管理

軟體需求的分類：

需求分析與模組化技術（資料流圖）

（一）結構化分析（SA）方法

定義： 其基本思想是用系統工程的思想和工程化的方法，根據使用者至上的原則，自始自終按照結構化、子產品化，自頂向下地對系統進行分析與設計。

描述方法：

1. 資料流圖(DFD圖)
2. 資料詞典
3. 加工邏輯說明

檢查DFD圖的正确性：

資料守恒

父圖與子圖的平衡

（二）面向對象的分析（OOA）方法

定義： 識别問題域内的對象,分析它們之間的關系,并建立起三類模型。

軟體需求工程總結

三、需求分析用例圖

用例模組化執行個體

如：

某酒店訂房系統描述如下：

(1) 顧客可以選擇線上預訂，也可以直接去酒店通過前台服務員預訂；

(2) 前台服務員可以利用系統直接在前台預訂房

(3) 不管采用哪種預訂方式，都需要在預訂時支付相應訂金；

(4) 前台預訂可以通過現金或信用卡的形式進行訂金支付，但是網上預訂隻能通過信用卡進行支付；

(5) 利用信用卡進行支付時需要和信用卡系統進行通信；

(6) 客房部經理可以随時檢視客房預訂情況和每日收款情況。

參與者：

1、顧客

2、前台服務員

3、信用卡系統： 該訂餐系統和信用卡系統有互動，是以說信用卡系統也是參與者。

4,、客房部經理

參與者用到了系統中的功能：

1、顧客：線上預訂、通過信用卡進行支付

2、前台服務員：在前台預訂房間、通過現金進行支付

3、信用卡系統：信用卡進行支付時需要和信用卡系統進行通信

4,、客房部經理：檢視客房預訂情況和每日收款情況

四、面向對象分析與設計

靜态模型

（一）類圖（舉例POS機系統）

識别類–》識别屬性–》識别類的操作–》識别類的關系–》建立互動圖

POS機系統識别類的操作和類及屬性

POS機系統類圖示例

動态模型

（一）狀态圖

用來描述一個特定的對象所有可能的狀态,以及由于各種事件的發生而引起的狀态之間的轉移和變化。

并不是所有的類都需要畫狀态圖，有明确意義的狀态，在不同狀态下行為有所不同的類才需要畫狀态圖。

例如學生請假管理系統：

（二）順序圖

順序圖直覺地表示對象之間的行為關系以及操作和消息的時序關系。

幫助分析人員對照檢查用例中描述需求，是否已經落實給具體對象去實作

提醒分析人員去補充遺漏的對象類或操作

幫助分析人員識别哪些對象是主動對象

通過對一個特定的對象群體的動态方面模組化，深入地了解對象之間的互動

例如：

五、軟體設計

軟體設計階段任務

将分析階段獲得的需求說明轉換為計算機中可實作的系統。包括：

• 軟體體系結構的設計
• 使用者界面的設計
• 資料結構的設計
• 算法的設計

軟體設計過程

大體分為如下活動：

• 軟體體系結構的設計
• 抽象說明書
• 接口設計
• 構件設計
• 資料結構設計
• 算法設計

系統結構性模型——層次結構模型

層次結構模型将系統劃分為若幹層次，每個層次提供相應的服務，并且下層的服務隻向它的直接上層提供。

這種結構非常适合增量的軟體開發，新增加的部分将位于原有的系統之上或将原系統包裹起來，進而擴充了原系統的功能。

子產品分解

目的： 将系統“分而治之”，以降低問題的複雜性，使軟體結構清晰，便于閱讀和了解，易于測試和調試，因而有助于提高軟體的可靠性。

MVC設計模式

優點：

1. 可以為一個模型在運作時同時建立和使用多個試圖。
2. 視圖與控制器的可接插性。
3. 模型的可移植性。

不足：

1. 增加了系統結構和實作的複雜性。
2. 視圖與控制器間的過于緊密的連接配接。
3. 視圖對模型資料的低效率通路。
4. 目前，一般進階的界面工具或構造器不支援MVC模式。

六、軟體測試

軟體測試的基本概念

定義： 使用人工或自動手段，來運作或測試某個系統的過程。

目的： 檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差别。

軟體測試的特點和基本原則

特點：

• 軟體測試的開銷大
• 不能進行“窮舉”測試
• 軟體測試難度大

基本原則：

• 應盡早地和不斷地進行軟體測試。
• 開發人員應盡量避免進行軟體測試。
• 關鍵是注重測試用例的選擇。
• 充分注意測試中的群集現象。
• 避免測試的随意性，嚴格執行測試計劃
• 妥善儲存測試過程中的一切文檔，為軟體維護提供友善。

白盒測試法

定義： 允許測試人員利用程式内部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。

（一）語句覆寫

定義： 程式中的每個可執行語句至少被執行一次。

（二）判定覆寫

定義： 程式中每個判斷的取真和取假分支至少經曆一次，即判斷真假值均被滿足。

（三）條件覆寫

定義： 每個判斷中每個條件的可能取值至少滿足一次。

（四）判定-條件覆寫

定義： 判斷中所有條件的可能取值至少執行一次，且所有判斷的可能結果至少執行一次。

黑盒測試法

定義： 完全不考慮程式内部的邏輯結構和内部特性，隻依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。

（一）等價分類法

定義： 等價類劃分是将輸入域劃分成盡可能少的若幹子域，在劃分中要求每個子域兩兩互不相交，每個子域稱為一個等價類。

等價類類型：

• 有效等價類是對規格說明有意義、合理的輸入資料構成的集合，能夠檢驗程式是否實作了規格說明中預先規定的功能和性能。
• 無效等價類是對規格說明無意義、不合理的輸入資料構成的集合，以檢查程式是否具有一定的容錯性。

例如：

（二）邊界值分析法

定義： 是對輸入或輸出的邊界值進行測試的一種方法，它通常作為等價類劃分法的補充，這種情況下的測試用例來自等價類的邊界。

基本思想： 故障往往出現在程式輸入變量的邊界值附近邊界值分析法是基于可靠性理論中稱為“單故障”的假設，即有兩個或兩個以上故障同時出現而導緻失效的情況很少。

先确定邊界： 通常輸入或輸出等價類的邊界就是應該着重測試的邊界情況。選取正好等于、剛剛大于或剛剛小于邊界的值作為測試資料，而不是選取等價類中的典型值或任意值。

軟體測試的概念

（一）單元測試

定義： 單元測試（Unit Testing）是對軟體中的最小可測試單元進行檢查和驗證。

（二）內建測試

定義： 在單元測試的基礎之上，将所有子產品按照設計要求組裝成一個完整的系統而進行的測試

（三）确認測試

定義： 驗證系統的功能、性能等特性是否符合需求規格說明。

（四）系統測試

定義： 驗證系統中每個部分均已得到正确的內建，并能完成指定功能。

1. 功能測試
2. 性能測試
3. 安全測試
4. 恢複測試
5. 強度測試
6. 文檔測試

七、軟體維護

軟體維護的基本概念

軟體維護 是軟體被投入運作使用後人們對軟體産品所進行的修改，變更通常是修改現有的元件或增加新的元件，一般不涉及體系結構的重大變化。

維護類型：

• 糾錯性維護：修改軟體缺陷或不足
• 适應性維護：修改軟體使其适應不同操作環境，主要包括硬體變化、作業系統變化或者其他支援軟體變化等
• 完善性維護：增加或修改系統功能，使其适應業務的變化
• 預防性維護：對需要維護的軟體或軟體中的一部分進行重新設計、編碼和測試

特性：

• 時間長、工作量大、成本高
• 維護的副作用
  • 源代碼、資料和文檔的副作用
• 軟體維護困難
  • 讀懂别人程式困難
  • 軟體維護工作難出成果
  • 文檔的不一緻性
  • 軟體開發人員和軟體維護人員時間上的差異