軟體工程是指應用電腦科學、數學及管理科學等原理，以工程化的原則和方法來解決軟體問題的工程，其目的是提高軟體生成率、提高軟體質量、降低軟體成本。
一、需求分析
軟體需求是指使用者對新系統在功能、行為、效能、設計約束等方面的期望。
1.1 軟體需求層次
軟體的需求主要分為三個層次，從低到高依次是系統需求、使用者需求和業務需求
1.1.1 系統需求
系統需求主要是從系統角度來說明軟體需求，包括功能需求、非功能需求和設計約束
- 功能需求：規定開發人員必須在系統中實現的軟體功能，滿足業務需要
- 非功能需求：系統必須具備的除功能需求外的特性，其中包括軟體質量屬性
- 效能需求：響應時間、吞吐量、資源利用率等
- 安全性、可靠性、可維護性與易用性等等
- 設計約束：系統的限制條件或補充說明，如系統必須採用國產資料庫系統
1.1.2 使用者需求
使用者需求指使用者要求系統必須能完成的任務或功能
1.1.3 業務需求
業務需求是客戶對相同高層次的目標要求，通過業務需求可以確定專案範圍和檢視，來自於專案投資人
1.2 需求分析與定義
1.2.1 質量功能部署
質量功能部署(Quality Function Deployment, QFD)是將使用者要求轉化成軟體需求的技術，目的是最大限度的提升使用者的滿意度。QFD將軟體需求分成三類，分別是常規需求、期望需求和意外需求
- 常規需求：使用者認為系統應該做到的功能或效能，實現越多使用者越滿意
- 期望需求：使用者不能正確描述想要得到的功能需求，想當然認為系統應具備的功能或效能
- 意外需求：使用者要求範圍外的功能或效能，實現這些需求使用者會更高興，但不實現也不影響其購買的決策
二、物件和類
2.1 物件導向的基本概念
- 物件：由資料及其操作所構成的封裝體，是構成系統的基本單位
- 類：類和物件的關係為，物件是類的例項，類是物件的模板
- 抽象：通過特定的例項抽取共同特徵以後形成概念的過程。比如物件是現實中某個實體的抽象，類是一組物件的抽象
- 封裝：將相關概念組成一個單元模組，並通過一個名稱來引用它。只能通過物件對外提供的介面進行呼叫
- 繼承：表示類之間層次關係，這種關係使得某類物件可以繼承另外一類物件的特徵
- 多型：使得在多個類可以定義同一個操作或屬性名，並在每個類中可以有不同的實現
- 介面：描述對操作規範的說明
- 訊息：體現物件間的互動，通過它向目標物件傳送操作請求
- 元件：表示軟體系統中可替換的、物理的組成部分
- 複用：指將已有的軟體及其有效成分用於構造新的軟體或系統。元件技術是軟體複用實現的關鍵
- 模式：描述了一個不斷重複發生的問題，以及該問題的解決方案。包括特定環境、問題和解決方案三個組成部分。
2.2 類之間的關係
類與類之間有不同的關係，主要有這六類：
- 關聯(Association)：關聯提供了不同類物件之間的結構關係，關聯絡統的是物件例項之間的關係，不表示兩個類之間的關係
- 依賴(Dependency)：兩個類A和B，如果B的變化可能引起A的變化，則稱類A依賴於類B
- 泛化(Generalization)：泛化描述一般事物與該事物中的特殊種類之間的關係，也就是父類與子類之間的關係。而繼承關係是泛化關係的反面，可以這樣說，子類繼承了父類，父類是子類的泛化。
- 聚合(Aggregation)：表示類之間的整體與部分的關係，部分可能同時屬於多個"整體"，"部分"與"整體"的生命週期可以不相同
- 組合(Composition)：表示類之間的整體與部分的關係，但不可分
- 實現(Realization)：一個類或多個類可以實現一個介面，而每個類分別實現介面中的操作
三、統一建模語言UML
UML(Unified Modeling Language) 是一種定義良好、易於表達、功能強大而且普遍使用的建模語言，它融入軟體工程領域的新思想、新方法和新技術，作用域不限於支援物件導向分析（Object-Oriented Analysis，OOA）和麵向物件設計（Object-Oriented Design，OOD）,支援從需求分析開始的軟體開發全過程。
UML 獨立於軟體開發過程，它不是程式設計語言，是一種視覺化的建模語言。
3.1 UML中的關係
UML 用關係把事物結合在一起，主要有以下四種關係（也就是類與類之間的6種關係）：
-
依賴（dependency）：兩個事物之間的語義關係，其中一個事物發生變化會影響另一個事物的語義
-
關聯（association）：描述一組物件之間連線的結構關係
- 聚合(Aggregation)：兩個物件是整體與部分，可以分割
- 組合(Composition)：兩個物件是整體與部分，但是無法分割
-
泛化（generalization）：一般化和特殊化的關係，描述特殊元素的物件可替換一般元素的物件
-
實現（Realization）：一個類或多個類實現一個介面，其中的每個類分別實現介面的操作
3.2 UML檢視
UML 由檢視(View)、圖(Diagram)、模型元素(Model Element)和通用機制(General Mechanism)等幾個部分組成：
- 檢視：是表達系統的某一方面的特徵的UML建模元素的子集，由多個圖組成，是在某個抽象層上對系統的抽象表示
- 圖：是模型元素集的圖形表示，通常是由弧(關係)和頂點(其他模型元素)相互連線構成的
- 模型元素：代表物件導向中的類、物件、訊息和關係等概念，是構成圖的最基本的常用概念
- 通用機制：用於表示其他資訊，比如註釋、模型元素的語義等。
而檢視則是從不同視角為系統構架建模，形成系統的不同檢視，主要有這樣五類檢視：
- 用例檢視（Use Case View）：強調從使用者角度看到的或需要的系統功能，是被稱為參與者的外部使用者所能觀察到的系統功能的模型圖
- 邏輯檢視（Logical View）：展現系統的靜態或結構組成及特徵，也叫做結構模型檢視或靜態檢視
- 併發檢視（Concurrent View）：體現系統的動態或行為特徵，也叫做模型檢視或動態檢視
- 元件檢視（Component View）：體現系統實現的結構和行為特徵，也叫做實現模型檢視
- 部署檢視（Deployment View）：體現系統實現環境的結構和行為特徵，也叫做物理檢視或環境模型檢視
檢視主要有圖類組成，下面來看看具體的UML圖
3.3 UML圖
UML圖總共有14種，如下所示：
-
類圖：描述系統中類的靜態結構
-
物件圖：是類圖的例項
-
用例圖：從使用者角度描述系統功能，系統與外部系統及使用者之間的互動
-
元件圖：描述元件與元件之間關係，主要包括元件、介面和關係。像這種：
-
配置圖：描述環境元素的配置，並把實現系統的元素對映到配置上，顯示系統中軟體和硬體的物理架構，類似於這種：
-
狀態圖：描述一個狀態機，它由狀態、轉移、事件和活動組成。類似於下面這種：
-
時序圖：按照時間順序描述系統元素之間的互動
-
協作圖（通訊圖）：按照時間和空間順序描述系統元素間的互動和他們之間的關係
-
活動圖：描述系統元素的活動，活動圖主要用來表示活動次序，狀態圖主要用來表示狀態
-
組合結構圖：描述結構化類的內部結構，包括結構化類與系統其餘部分的互動點，如下圖：
-
包圖：描述由模型本身分解而成的組織單元，以及它們之間的依賴關係，如下圖所示：
-
定時圖：是一種互動圖，強調訊息跨越不同物件或參與者的實際時間，而不僅僅知識關心訊息的相對順序
-
製品圖：描述計算機一個系統的物理結構
-
互動概覽圖：活動圖和順序圖的混合
四、軟體架構設計
軟體架構不僅指定了系統的組織結構和拓撲結構，並且顯示了系統需求和構件之間的對應關係，提供了一些設計決策的基本原理。
4.1 軟體架構風格
軟體架構風格是描述某一特定應用領域中系統組織方式的慣用模式（idiomatic paradigm），核心問題是達到架構級的軟體複用。Garlan 和Shaw對通用軟體架構風格進行了以下分類：
4.1.1 資料流風格
資料流風格顧名思義，所有的資料是按照流的形式在執行過程中前進，不存在結構的反覆與重構。主要包括批處理序列和管道-過濾器兩種具體的架構風格。
-
批處理序列：每一步處理都是順序且獨立執行的，如下圖所示：
-
管道-過濾器：過濾器負責對資料進行處理和計算（所有的矩形），管道則是過濾器之間資料流動的通道（所有的黑色箭頭），其結構如下圖所示：
4.1.2 呼叫/返回風格
呼叫返回就是指在系統中採用了呼叫和返回的機制。包括物件導向風格、主程式/子程式，層次結構三種：
-
主程式/子程式風格：這種風格是結構化開發時期的經典架構風格，比如
main方法呼叫子函式就是這種架構風格 -
物件導向風格：這種風格建立在資料抽象和麵向物件的基礎上，物件是通過函式和過程的呼叫來互動
-
層次結構風格：層次結構中每一層提供一個抽象功能，作為上層通訊的基礎
4.1.3 獨立構件風格
獨立構件風格主要強調系統中的每個構件都是相對獨立的個體，它們之間不通訊，以降低耦合度，提升靈活度。主要包括程式通訊和事件系統子風格
- 程式通訊架構風格：構件是獨立的過程，連線件是訊息傳遞。
- 事件系統風格：構件不直接呼叫一個過程，而是觸發或廣播一個或多個事件。
4.1.4 虛擬機器風格
人為構建一個執行環境，在這個環境之上，可以解析與執行自定義的一些語言，這樣可以增加架構的靈活性。主要包括直譯器和規則為中心的兩種架構風格。
- 直譯器：具有直譯器風格的軟體中含有一個虛擬機器，可以模擬硬體執行過程和一些關鍵應用。
- 規則為中心：基於規則的系統包括規則集、規則直譯器、規則選擇器及工作記憶體
4.1.5 倉庫風格
倉庫風格中有兩種不同的構件：中央資料結構說明當前狀態，獨立構件在中央資料儲存上執行，倉庫與外構件間的相互作用在系統中會有大的變化。倉庫風格主要包括資料庫系統、超文字系統和黑板風格。
-
資料庫系統：也就是常見的資料庫系統設計
-
超文字系統：早期的靜態網頁
-
黑板系統：解決複雜的非結構化問題，能在求解過程中綜合運用不同知識源，使得問題的表達、組織和求解變得容易。
4.2 軟體設計
軟體設計主要解決軟體如何做的問題，合理的軟體設計方案既可以保證系統的質量，也可以提高開發效率。從方法上來講，軟體設計分為結構化設計與物件導向設計。
4.2.1 結構化設計
結構化設計（Structure Design）是一種面向資料流的方法，是一個自頂向下、逐步求精和模組化的過程。其基本思想是將軟體設計成由相對獨立且具有單一功能的模組組成的結構，主要分為概要設計和詳細設計兩個階段
- 概要設計：又叫做總體結構設計，主要任務是將系統的功能需求分配給軟體模組，確定每個模組的功能和呼叫關係，形成軟體的模組結構圖、即系統結構圖
- 詳細設計：為每個具體任務選擇適當的技術手段和處理方法
遵循原則：高內聚，低耦合
4.2.2 物件導向設計
主要任務是對類和物件進行設計，包括類的屬性、方法，以及類與類之間的關係。通常遵循這六大原則：
詳細可以看這篇文章：設計模式學習筆記（一）設計模式六大原則 - 歸斯君 - 部落格園 (cnblogs.com)
4.2.3 設計模式
設計模式是前人經驗的總結，它使得人們可以方便地複用成功的軟體設計。詳情可以看我的系列文章：
設計模式學習筆記（二）工廠模式、模板模式和策略模式的混合使用 - 歸斯君 - 部落格園 (cnblogs.com)
五、軟體工程的過程管理
軟體過程是軟體生命週期中的一系列相關活動，即用於開發和維護軟體及相關產品的一系列活動。軟體產品的質量取決於軟體過程。而在軟體過程管理方面，最著名的是能力成熟度模型整合（Capability Maturity Model Integration, CMMI），它融合各種模型，形成了組織範圍內過程改進的單一整合模型，其主要目的是消除不同模型之間的不一致和重複，降低基於模型進行改進的成本。
CMMI 主要有連續式和階段式兩種表示法結構：
5.1 連續式表示法
連續式表示法則是相對於單個CMMI過程域，使用能力等級來描述組織過程狀態的特徵。主要有過程管理、專案管理、工程和支援四個過程組。稱為過程能力等級
| 過程能力 | 過程域 |
|---|---|
| 過程管理 | 組織級過程焦點、組織級過程定義、組織級培訓、組織級過程效能、組織級改革與實施【三個過程改革培訓】 |
| 專案管理 | 專案計劃、專案監督與控制、供應商合同管理、整合專案管理、風險管理、整合化的團隊、定量專案管理【四個專案團隊管合同風險】 |
| 工程 | 需求管理、需求開發、技術解決方案、產品繼承、驗證、確認【兩個需求技術，整合認（確認）證（驗證）】 |
| 支援 | 配置管理、度量和分析、過程和產品質量保證、決策分析和解決方案、組織級整合環境、因果分析和解決方案【制（配置）度（度量）保證決策，環境決定因果】 |
5.2 階段式表示法
階段式表示法是相對於CMMI模型整體，使用成熟度級別來描述組織過程總體狀態的特徵。主要有初始級、可管理級、已定義級、量化管理級和優化管理級五個成熟度級別。稱為組織成熟度等級
| 成熟度 | 過程域 |
|---|---|
| 可管理級 | 需求管理、專案計劃、配置管理、專案監督與控制、供應商合同管理、度量和分析、過程和產品質量保證 |
| 已定義級 | 需求開發、技術解決方案、產品整合、驗證、確認、組織級過程焦點、組織級過程定義、組織級培訓、整合專案管理、風險管理、整合化的團隊、決策分析和解決方案 |
| 量化管理級 | 組織級過程效能、定量專案管理 |
| 優化管理級 | 組織級改革與實施、因果分析和解決方案 |
六、軟體測試及其管理
6.1 測試的方法
軟體測試方法包括靜態測試和動態測試。靜態測試主要採用人工檢測和計算機輔助靜態分析的手段對程式進行檢測；動態測試是指在計算機上實際執行程式進行軟體測試。
6.1.1 靜態測試
靜態測試主要包括對文件和對程式碼的靜態測試：
- 對文件的靜態測試：主要以檢查單的形式進行
- 對程式碼的靜態測試：主要有桌前檢查（Desk Checking）、程式碼走查和程式碼審查
6.1.2 動態測試
動態測試主要包括白盒和黑盒測試：
-
白盒測試：也稱為結構測試，主要用於軟體單元測試。將程式看成是一個透明的白盒，測試人員清楚程式的結構和演算法。測試方法主要有：
- 控制流測試
- 資料流測試
- 程式變異測試
其中靜態測試的方法也可以實現白盒測試，屬於白盒測試的範疇
-
黑盒測試：又叫做功能測試，主要用於整合測試、確認測試和系統測試中。黑盒是將程式看成是一個不透明的黑盒，測試人員不清楚程式內部的結構和演算法。只檢查程式功能是否按照SRS的要求正常使用，程式是否能適當地接收輸入資料併產生正確的輸出資訊。
6.2 測試的型別
測試可以分為單元測試、整合測試、確認測試、系統測試、配置項測試和迴歸測試等類別
6.2.1 單元測試
也叫做模組測試，測試的物件是可獨立編譯或彙編的程式模組。
6.2.2 整合測試
目的檢查模組之間，以及模組和已整合的軟體之間的介面關係，並驗證已整合的軟體是否符合設計要求。
6.2.3 確認測試
用於驗證軟體的功能、效能和其他特性是否與使用者需求一致。根據使用者的參與程度可以包括：
- 內部確認測試：主要由軟體開發組織內部按照SRS進行測試
- Alpha測試和Beta測試：Alpha測試指使用者在開發環境下測試，Beta指使用者在實際使用環境下進行測試
- 驗收測試：指標對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 業務流程整合
也叫做過程整合，這種整合超越了資料和系統，它由一系列基於標準的、統一資料格式的工作流組成。它不僅要提供底層應用支撐系統之間的互聯，同時要實現存在於企業內部的應用之間，本企業和其他合作伙伴之間的端到端的業務流程的管理。比如企業-銀聯-銀行資金業務及流程整合。