信管知識梳理（三）軟體工程相關知識

• 2022 年 3 月 29 日
• 筆記
• 資訊系統項目管理, 項目管理

軟體工程是指應用電腦科學、數學及管理科學等原理，以工程化的原則和方法來解決軟體問題的工程，其目的是提高軟體生成率、提高軟體品質、降低軟體成本。

一、需求分析

軟體需求是指用戶對新系統在功能、行為、性能、設計約束等方面的期望。

1.1 軟體需求層次

軟體的需求主要分為三個層次，從低到高依次是系統需求、用戶需求和業務需求

1.1.1 系統需求

系統需求主要是從系統角度來說明軟體需求，包括功能需求、非功能需求和設計約束

1. 功能需求：規定開發人員必須在系統中實現的軟體功能，滿足業務需要
2. 非功能需求：系統必須具備的除功能需求外的特性，其中包括軟體品質屬性
   • 性能需求：響應時間、吞吐量、資源利用率等
   • 安全性、可靠性、可維護性與易用性等等
3. 設計約束：系統的限制條件或補充說明，如系統必須採用國產資料庫系統

1.1.2 用戶需求

用戶需求指用戶要求系統必須能完成的任務或功能

1.1.3 業務需求

業務需求是客戶對相同高層次的目標要求，通過業務需求可以確定項目範圍和視圖，來自於項目投資人

1.2 需求分析與定義

1.2.1 品質功能部署

品質功能部署(Quality Function Deployment, QFD)是將用戶要求轉化成軟體需求的技術，目的是最大限度的提升用戶的滿意度。QFD將軟體需求分成三類，分別是常規需求、期望需求和意外需求

1. 常規需求：用戶認為系統應該做到的功能或性能，實現越多用戶越滿意
2. 期望需求：用戶不能正確描述想要得到的功能需求，想當然認為系統應具備的功能或性能
3. 意外需求：用戶要求範圍外的功能或性能，實現這些需求用戶會更高興，但不實現也不影響其購買的決策

二、對象和類

2.1 面向對象的基本概念

1. 對象：由數據及其操作所構成的封裝體，是構成系統的基本單位
2. 類：類和對象的關係為，對象是類的實例，類是對象的模板
3. 抽象：通過特定的實例抽取共同特徵以後形成概念的過程。比如對象是現實中某個實體的抽象，類是一組對象的抽象
4. 封裝：將相關概念組成一個單元模組，並通過一個名稱來引用它。只能通過對象對外提供的介面進行調用
5. 繼承：表示類之間層次關係，這種關係使得某類對象可以繼承另外一類對象的特徵
6. 多態：使得在多個類可以定義同一個操作或屬性名，並在每個類中可以有不同的實現
7. 介面：描述對操作規範的說明
8. 消息：體現對象間的交互，通過它向目標對象發送操作請求
9. 組件：表示軟體系統中可替換的、物理的組成部分
10. 復用：指將已有的軟體及其有效成分用於構造新的軟體或系統。組件技術是軟體復用實現的關鍵
11. 模式：描述了一個不斷重複發生的問題，以及該問題的解決方案。包括特定環境、問題和解決方案三個組成部分。

2.2 類之間的關係

類與類之間有不同的關係，主要有這六類：

1. 關聯(Association)：關聯提供了不同類對象之間的結構關係，關聯繫統的是對象實例之間的關係，不表示兩個類之間的關係
2. 依賴(Dependency)：兩個類A和B，如果B的變化可能引起A的變化，則稱類A依賴於類B
3. 泛化(Generalization)：泛化描述一般事物與該事物中的特殊種類之間的關係，也就是父類與子類之間的關係。而繼承關係是泛化關係的反面，可以這樣說，子類繼承了父類，父類是子類的泛化。
4. 聚合(Aggregation)：表示類之間的整體與部分的關係，部分可能同時屬於多個”整體”，”部分”與”整體”的生命周期可以不相同
5. 組合(Composition)：表示類之間的整體與部分的關係，但不可分
6. 實現(Realization)：一個類或多個類可以實現一個介面，而每個類分別實現介面中的操作

三、統一建模語言UML

UML(Unified Modeling Language) 是一種定義良好、易於表達、功能強大而且普遍使用的建模語言，它融入軟體工程領域的新思想、新方法和新技術，作用域不限於支援面向對象分析（Object-Oriented Analysis，OOA）和面向對象設計（Object-Oriented Design，OOD）,支援從需求分析開始的軟體開發全過程。

UML 獨立於軟體開發過程，它不是程式設計語言，是一種可視化的建模語言。

3.1 UML中的關係

UML 用關係把事物結合在一起，主要有以下四種關係（也就是類與類之間的6種關係）：

1. 依賴（dependency）：兩個事物之間的語義關係，其中一個事物發生變化會影響另一個事物的語義

2. 關聯（association）：描述一組對象之間連接的結構關係

   • 聚合(Aggregation)：兩個對象是整體與部分，可以分割
   • 組合(Composition)：兩個對象是整體與部分，但是無法分割

3. 泛化（generalization）：一般化和特殊化的關係，描述特殊元素的對象可替換一般元素的對象

4. 實現（Realization）：一個類或多個類實現一個介面，其中的每個類分別實現介面的操作

3.2 UML視圖

UML 由視圖(View)、圖(Diagram)、模型元素(Model Element)和通用機制(General Mechanism)等幾個部分組成：

• 視圖：是表達系統的某一方面的特徵的UML建模元素的子集，由多個圖組成，是在某個抽象層上對系統的抽象表示
• 圖：是模型元素集的圖形表示，通常是由弧(關係)和頂點(其他模型元素)相互連接構成的
• 模型元素：代表面向對象中的類、對象、消息和關係等概念，是構成圖的最基本的常用概念
• 通用機制：用於表示其他資訊，比如注釋、模型元素的語義等。

而視圖則是從不同視角為系統構架建模，形成系統的不同視圖，主要有這樣五類視圖：

1. 用例視圖（Use Case View）：強調從用戶角度看到的或需要的系統功能，是被稱為參與者的外部用戶所能觀察到的系統功能的模型圖
2. 邏輯視圖（Logical View）：展現系統的靜態或結構組成及特徵，也叫做結構模型視圖或靜態視圖
3. 並發視圖（Concurrent View）：體現系統的動態或行為特徵，也叫做模型視圖或動態視圖
4. 組件視圖（Component View）：體現系統實現的結構和行為特徵，也叫做實現模型視圖
5. 部署視圖（Deployment View）：體現系統實現環境的結構和行為特徵，也叫做物理視圖或環境模型視圖

視圖主要有圖類組成，下面來看看具體的UML圖

3.3 UML圖

UML圖總共有14種，如下所示：

1. 類圖：描述系統中類的靜態結構

2. 對象圖：是類圖的實例

3. 用例圖：從用戶角度描述系統功能，系統與外部系統及用戶之間的交互

4. 組件圖：描述組件與組件之間關係，主要包括組件、介面和關係。像這種：

   

5. 配置圖：描述環境元素的配置，並把實現系統的元素映射到配置上，顯示系統中軟體和硬體的物理架構，類似於這種：

   

6. 狀態圖：描述一個狀態機，它由狀態、轉移、事件和活動組成。類似於下面這種：

   

7. 時序圖：按照時間順序描述系統元素之間的交互

   

8. 協作圖（通訊圖）：按照時間和空間順序描述系統元素間的交互和他們之間的關係

   

9. 活動圖：描述系統元素的活動，活動圖主要用來表示活動次序，狀態圖主要用來表示狀態

   

10. 組合結構圖：描述結構化類的內部結構，包括結構化類與系統其餘部分的交互點，如下圖：

    

11. 包圖：描述由模型本身分解而成的組織單元，以及它們之間的依賴關係，如下圖所示：

    

12. 定時圖：是一種交互圖，強調消息跨越不同對象或參與者的實際時間，而不僅僅知識關心消息的相對順序

    

13. 製品圖：描述電腦一個系統的物理結構

14. 交互概覽圖：活動圖和順序圖的混合

四、軟體架構設計

軟體架構不僅指定了系統的組織結構和拓撲結構，並且顯示了系統需求和構件之間的對應關係，提供了一些設計決策的基本原理。

4.1 軟體架構風格

軟體架構風格是描述某一特定應用領域中系統組織方式的慣用模式（idiomatic paradigm），核心問題是達到架構級的軟體復用。Garlan 和Shaw對通用軟體架構風格進行了以下分類：

4.1.1 數據流風格

數據流風格顧名思義，所有的數據是按照流的形式在執行過程中前進，不存在結構的反覆與重構。主要包括批處理序列和管道-過濾器兩種具體的架構風格。

1. 批處理序列：每一步處理都是順序且獨立執行的，如下圖所示：

   

2. 管道-過濾器：過濾器負責對數據進行處理和計算（所有的矩形），管道則是過濾器之間數據流動的通道（所有的黑色箭頭），其結構如下圖所示：

   

4.1.2 調用/返迴風格

調用返回就是指在系統中採用了調用和返回的機制。包括面向對象風格、主程式/子程式，層次結構三種：

1. 主程式/子程式風格：這種風格是結構化開發時期的經典架構風格，比如main方法調用子函數就是這種架構風格

2. 面向對象風格：這種風格建立在數據抽象和面向對象的基礎上，對象是通過函數和過程的調用來交互

   

3. 層次結構風格：層次結構中每一層提供一個抽象功能，作為上層通訊的基礎

   

4.1.3 獨立構件風格

獨立構件風格主要強調系統中的每個構件都是相對獨立的個體，它們之間不通訊，以降低耦合度，提升靈活度。主要包括進程通訊和事件系統子風格

1. 進程通訊架構風格：構件是獨立的過程，連接件是消息傳遞。
2. 事件系統風格：構件不直接調用一個過程，而是觸發或廣播一個或多個事件。

4.1.4 虛擬機風格

人為構建一個運行環境，在這個環境之上，可以解析與運行自定義的一些語言，這樣可以增加架構的靈活性。主要包括解釋器和規則為中心的兩種架構風格。

1. 解釋器：具有解釋器風格的軟體中含有一個虛擬機，可以模擬硬體執行過程和一些關鍵應用。
2. 規則為中心：基於規則的系統包括規則集、規則解釋器、規則選擇器及工作記憶體

4.1.5 倉庫風格

倉庫風格中有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存儲上執行，倉庫與外構件間的相互作用在系統中會有大的變化。倉庫風格主要包括資料庫系統、超文本系統和黑板風格。

1. 資料庫系統：也就是常見的資料庫系統設計

2. 超文本系統：早期的靜態網頁

3. 黑板系統：解決複雜的非結構化問題，能在求解過程中綜合運用不同知識源，使得問題的表達、組織和求解變得容易。

   

4.2 軟體設計

五、軟體工程的過程管理

軟體過程是軟體生命周期中的一系列相關活動，即用於開發和維護軟體及相關產品的一系列活動。軟體產品的品質取決於軟體過程。而在軟體過程管理方面，最著名的是能力成熟度模型集成（Capability Maturity Model Integration, CMMI），它融合各種模型，形成了組織範圍內過程改進的單一集成模型，其主要目的是消除不同模型之間的不一致和重複，降低基於模型進行改進的成本。

CMMI 主要有連續式和階段式兩種表示法結構：

5.1 連續式表示法

連續式表示法則是相對於單個CMMI過程域，使用能力等級來描述組織過程狀態的特徵。主要有過程管理、項目管理、工程和支援四個過程組。稱為過程能力等級

5.2 階段式表示法

階段式表示法是相對於CMMI模型整體，使用成熟度級別來描述組織過程總體狀態的特徵。主要有初始級、可管理級、已定義級、量化管理級和優化管理級五個成熟度級別。稱為組織成熟度等級

六、軟體測試及其管理

6.1 測試的方法

軟體測試方法包括靜態測試和動態測試。靜態測試主要採用人工檢測和電腦輔助靜態分析的手段對程式進行檢測；動態測試是指在電腦上實際運行程式進行軟體測試。

6.1.1 靜態測試

靜態測試主要包括對文檔和對程式碼的靜態測試：

1. 對文檔的靜態測試：主要以檢查單的形式進行
2. 對程式碼的靜態測試：主要有桌前檢查（Desk Checking）、程式碼走查和程式碼審查

6.1.2 動態測試

動態測試主要包括白盒和黑盒測試：

1. 白盒測試：也稱為結構測試，主要用於軟體單元測試。將程式看成是一個透明的白盒，測試人員清楚程式的結構和演算法。測試方法主要有：

   • 控制流測試
   • 數據流測試
   • 程式變異測試

   其中靜態測試的方法也可以實現白盒測試，屬於白盒測試的範疇

2. 黑盒測試：又叫做功能測試，主要用於集成測試、確認測試和系統測試中。黑盒是將程式看成是一個不透明的黑盒，測試人員不清楚程式內部的結構和演算法。只檢查程式功能是否按照SRS的要求正常使用，程式是否能適當地接收輸入數據併產生正確的輸出資訊。

6.2 測試的類型

測試可以分為單元測試、集成測試、確認測試、系統測試、配置項測試和回歸測試等類別

6.2.1 單元測試

也叫做模組測試，測試的對象是可獨立編譯或彙編的程式模組。

6.2.2 集成測試

目的檢查模組之間，以及模組和已集成的軟體之間的介面關係，並驗證已集成的軟體是否符合設計要求。

6.2.3 確認測試

用於驗證軟體的功能、性能和其他特性是否與用戶需求一致。根據用戶的參與程度可以包括：

1. 內部確認測試：主要由軟體開發組織內部按照SRS進行測試
2. Alpha測試和Beta測試：Alpha測試指用戶在開發環境下測試，Beta指用戶在實際使用環境下進行測試
3. 驗收測試：指針對SRS,在交付前以用戶為主進行的測試，其測試對象是完整的、集成的電腦系統。

6.2.4 系統測試

系統測試的對象是完整的、集成的電腦系統，系統測試的目的是在真實系統工作環境下，驗證完整的軟體配置項能否和系統正確連接，並滿足系統/子系統設計文檔和軟體開發合約規定的要求。

6.2.5 配置項測試

配置項測試的對象是軟體配置項，配置項測試的目的是檢驗軟體配置項與SRS的一致性。軟體配置項測試就是開發已經完成，準備提供給客戶的產品，可能是執行程式碼，也可能是產品文檔。

6.2.6 回歸測試

回歸測試的目的是測試軟體變更之後，變更部分的正確性和對變更需求的符合性，以及軟體原有的、正確的功能、性能和其他規定的要求的不損害性。

綜合來說，測試的順序應該是單元測試->集成測試->配置項測試->系統測試->確認測試->回歸測試

6.3 軟體調試

軟體測試的標誌是發現錯誤，而軟體調試則是根據錯誤跡象確定錯誤的原因和位置，並加以改正。

七、軟體集成技術

主要介紹軟體層次的集成技術—企業應用集成（Enterprise Application Integration, EAI），企業應用集成技術可以消除資訊孤島，將多個企業資訊系統連接起來，形成一個整體。EAI 主要包括表示集成、數據集成、控制集成和業務流程集成。

7.1 表示集成

表示集成也叫做介面集成，它是比較原始和最淺層次的繼承。該方法把用戶介面作為公共的集成點，把原有零散的系統介面集中在一個新的介面中。

同時表示集成也是黑盒集成，無須了解程式與資料庫的內部構造。它是集成多個系統到一個集成點中。

7.2 數據集成

數據集成是白盒集成，必須首先對數據進行標識並編成目錄，另外還要確定元數據模型，保證數據在資料庫系統中分布和共享。如分散式資料庫提供連接的資料庫訪問中間件技術（數據中間件）

7.3 控制集成

控制集成也叫做功能集成或者應用集成，是在業務邏輯層上對應用系統進行集成。控制集成的集成點存於程式程式碼中，集成處可能只需要簡單使用公開的API（應用程式編程介面）就可以訪問。控制集成是黑盒集成。比如企業應用於微信公眾號、小程式集成

7.4 業務流程集成

也叫做過程集成，這種集成超越了數據和系統，它由一系列基於標準的、統一數據格式的工作流組成。它不僅要提供底層應用支撐系統之間的互聯，同時要實現存在於企業內部的應用之間，本企業和其他合作夥伴之間的端到端的業務流程的管理。比如企業-銀聯-銀行資金業務及流程集成。