軟件工程概論

第一章 概述

軟件

軟件是計算機程序、規程以及運行計算機系統可能須要的相關文檔和數據，從軟件的內容來看，軟件更像是一種嵌入式的數字化知識，其造成是一個經過交互對話和抽象理解而不斷演化的過程，根據軟件服務對象的範圍，通常分爲通用和定製兩種。

• 通用軟件(Generic Software)：由軟件開發組織開發、面向市場用戶公開銷售的獨立運行系統（優勢：一次開發，屢次出售 缺點：有風險）
• 定製軟件(Customized Software )：由某個特定用戶委託、軟件開發組織在合同的約束下開發的軟件（優勢：知足用戶個性化需求 缺點：重複利用性差）

軟件的特性

複雜性、不可見性、可變性、一致性

軟件是複雜的，軟件是人類思惟和智能的一種延伸和在異體上的再現，遠比任何以往人類的創造物都要複雜的多，軟件的複雜性是軟件的固有屬性、本質特性。

軟件是不可見的，軟件是客觀世界空間和計算機空間之間的一種邏輯實體，不具備物理的形體特徵。

軟件是不斷變化的，它須要隨着應用、硬件、用戶和社會等各類因素的變化而不斷的被修改和擴展。

軟件必須聽從人爲的慣例並適應已有的技術和系統，軟件須要隨接口的不一樣而改變，隨時間的推移而變化，而這些變化是不一樣的人設計的結果，許多複雜性來自保持與其餘接口的一致，對軟件的任何再設計，都沒法簡化這些複雜特性。

軟件工程三要素

軟件工程以關注軟件質量爲目標，包括過程、方法和工具三要素

• 過程 支持軟件生命週期的全部活動
• 方法 爲軟件開發過程提供「如何作」的技術
• 工具 爲軟件開發方法提供自動的或半自動的軟件支撐環境

ISO9126軟件質量的六個一級特性

功能性、可靠性、可以使用性、有效性、可維護性、可移植性

• 功能性：在指定條件下使用時，軟件產品提供知足明確和隱含需求功能的能力；
• 可靠性：在指定條件下使用時，軟件產品維持規定的性能級別的能力(在規定的條件下，在規定的時間內，軟件不引發系統失效的機率)；
• 易用性（可以使用性）：在指定條件下使用時，軟件產品被理解、學習、使用及其吸引用戶的能力；
• 效率（有效性）：在規定條件下，相對於所用資源的數量，軟件產品可提供適當性能的能力；
• 可維護性：軟件產品可被修改的能力，修改可能包括修正、改進或者適應環境、需求和功能規約的變化；
• 可移植性：軟件產品從一種環境遷移到另外一種環境的能力。

第二章 軟件過程

軟件過程

軟件過程是軟件工程人員爲了得到軟件產品而在軟件工具的支持下實施的一系列軟件工程活動。

軟件過程的基本活動

問題提出、軟件需求規格說明、軟件設計、軟件實現、軟件確認、軟件演化

• 問題提出（可行性分析）：對開發任務進行調研和分析，研究系統的可行性和可能的解決方案，肯定開發總目標和範圍。
• 軟件需求規格說明：軟件需求規格說明描述軟件功能、列出約束條件、定義軟件的輸入和輸出接口。
• 軟件設計：軟件設計是根據需求規格說明，肯定軟件體系結構，進一步設計每一個系統部件的實現算法、數據結構及其接口等，編寫軟件設計說明書。
• 軟件實現：軟件實現是將所設計的各個子系統編寫成計算機可接受的程序代碼。
• 軟件確認：檢查和驗證所開發的系統是否符合用戶的指望。
• 軟件演化：軟件的內在本質是靈活的和可變的。隨着業務需求的變化，軟件必須進化和變動。儘管在開發過程和演化（維護）過程之間存在劃分，可是現實中全新的系統愈來愈少。

軟件過程模型

軟件過程模型描述軟件過程的總體框架，是軟件過程的一種抽象表示。

軟件過程模型包括：瀑布模型、快速原型模型、增量模型、螺旋模型、形式化方法模型、基於組件的開發模型

• 瀑布模型 將軟件過程劃分爲需求定義與分析、軟件設計、軟件實現、軟件測試、軟件運行與維護等一系列基本活動。以上活動自上而下、相互銜接的固定順序，如瀑布流水，逐級下落。

• 快速原型模型 快速原型模型的第一步是迅速構建一個能夠運行的軟件原型，實現用戶與系統的交互，由用戶對該原型進行評價，進一步細化待開發軟件需求。結果逐步調整使其知足用戶的要求以後，開發人員能夠將用戶的真正需求肯定下來。第二步則在第一步的基礎上開發用戶滿意的軟件。（特色：有效適應用戶需求的變化不知循環多少次，進度難以控制）

• 增量模型 增量模型在各個階段並不必定交付一個可運行的完整產品，而是交付知足用戶需求的一個子集。第一個增量每每是實現基本需求的核心產品，交付用戶使用後，通過評價造成下一個增量的開發計劃，其中包括對核心產品的修改和一些新功能的發佈。這個過程在每一個增量發佈後不斷重複，直到產生最終的完善產品。

• 螺旋模型 將瀑布模型和快速原型模型結合起來，強調了風險分析，特別適合大型複雜軟件系統（優勢：風險驅動（關注軟件的重用、關注早期錯誤的消除、將質量目標放在首位、將開發階段與維護階段結合在一塊兒）（缺點：須要風險評估的經驗適應內部大規模軟件開發）

• 形式化方法模型 首先將軟件需求描述提煉成採用數學符號表達的形式化描述；而後通過一系列的形式化轉換將形式化描述轉換成可執行程序；最後將整個系統集成起來測試。 (優勢：因爲數學方法具備嚴密性和準確性，形式化方法開發過程所交付的軟件系統具備較少的缺陷和較高的安全性) (缺點：開發人員須要具有必定技能並通過特殊訓練;形式化描述和轉換是一項費時費力的工做,成本高，質量不必定高;現實應用的系統大多數是交互性強的軟件，可是這些系統難以用形式化方法進行描述)

第三章 軟件項目管理

項目管理(PM)

就是在項目活動中運用相關知識, 技能, 工具和技術知足項目的要求。

項目管理的五個階段

啓動、計劃、監督、控制、收尾

• 啓動: 肯定項目範圍、組建項目團隊、創建項目環境
• 計劃: 肯定項目活動、預算項目成本、制定進度計劃
• 實施（監督+控制）: 監控項目執行、管理項目風險、控制項目變動
• 收尾: 客戶驗收項目、安裝培訓軟件、總結項目經驗

Albrecht的軟件信息域的5個基本特徵

• 外部輸入：用戶進行添加或修改的表格。
• 外部輸出：產生的報表輸出和屏幕輸出。
• 外部查詢：獨立查詢。
• 內部邏輯文件：軟件修改或保存的邏輯紀錄集合。
• 外部接口：與其餘系統進行信息交換或共享的 文件。

軟件風險

一個不肯定的事件或者狀況，若其一旦發生，會對項目的目標，例如，範圍、進度、成本和質量，產生積極或消極的影響。

• 特色:事先難以肯定；一旦發生將帶來損失，影響項目實施，甚至會致使項目失敗

• 類別:軟件規模、商業影響、客戶特性、軟件過程、開發技術、開發環境、開發人員

軟件風險管理過程

風險識別→風險評估→風險管理計劃→風險監控

風險識別是試圖採用系統化的方法，識別特定項目已知和可預測的風險 風險識別的經常使用方法是創建風險條目檢查表，即利用一組提問來幫助項目管理者瞭解在項目和技術方面的一些風險。

第四章 需求工程

不一樣角度的需求

• 業務需求：定義了軟件的遠景和範圍。
• 用戶需求：反映了用戶使用該系統須要完成的任務。
• 功能需求：系統須要具有的功能。
• 非功能需求：系統應該具有的性能。
• 系統需求：面向開發人員、詳細描述系統應該作什麼。 軟件的功能需求必須根據用戶需求來考慮，並且應該與業務需求定義的目標相一致

功能需求

描述系統應該提供的功能或服務，一般涉及用戶或外部系統與該系統之間的交互，通常不考慮系統的實現細節

非功能需求

是從各個角度對系統的約束和限制，反映了應用對軟件系統質量和特性的額外要求，包括過程需求、產品需求和外部需求等類型。

需求工程

需求工程是應用已證明有效的原理和方法，並經過合適的工具和符號，系統地描述出待開發系統及其行爲特徵和相關約束。

• 需求管理：在開發過程當中有效地管理和控制需求變動。
• 需求獲取：開發人員聆聽客戶的需求，觀察用戶的行爲；
• 需求分析：分析和整理所收集的用戶需求；
• 需求規格說明：以文檔形式，精確地闡述一個軟件系統 必須提供的功能和性能以及它所要考慮的限制條件；
• 需求驗證：使用評審和商議等有效手段對其進行驗證， 最終造成一個需求基線；

  需求獲取技術

用戶面談、需求專題討論會、現場考察、原型化方法、基於用例的方法 基於用例的方法 經過用例模型，明確系統功能

特色：以任務和用戶爲中心、有助於客戶瞭解系統功能、有助於開發人員理解用戶需求、能夠採用面向對象分析和設計方法將用例轉化爲設計模型

第六章 面向對象基礎

關聯

關聯是對象屬性之間的靜態聯繫，它經過對象的屬性來表現對象之間的依賴關係

關聯關係

關聯關係是類與類之間最經常使用的一種關係，它是一種結構化關係，表示has-a關係，每每表現爲B做爲A的屬性存在（A關聯B）

依賴關係

依賴關係是一種使用關係，特定事物的改變有可能會影響到使用該事物的其餘事物，在須要表示一個事物使用另外一個事物時使用依賴關係。大多數狀況下，依賴關係體如今某個類的方法使用另外一個類的對象做爲參數。表示要作一件事情，離不開某個對象，每每表現爲B做爲A的方法參數存在（A依賴B）

聚合關係

聚合關係表示一個總體與部分的關係。一般在定義一個總體類後，再去分析這個總體類的組成結構，從而找出一些成員類，該總體類和成員類之間就造成了聚合關係。

第七章 面向對象分析

分析類

在分析模型中，分析類是概念層次上的內容，用於描述系統中較高層次的對象，分析類直接與應用邏輯相關，而不關注技術實現的問題，分析類從軟件的功能需求來看分爲實體類、邊界類和控制類

• 實體類：表示系統存儲和管理的永久信息 entity
• 邊界類：表示參與者與系統之間的交互 boundry
• 控制類：表示系統在運行過程當中的業務控制邏輯 control（一個用例可有多個控制類）

分析活動

理解用例模型→識別分析類→定義交互行爲→創建分析類→評審分析模型

面向對象的分析模型

• 功能模型：由用例和場景表示
• 對象模型：由類圖和對象圖表示
• 動態模型：由狀態圖和順序圖表示

第八章 面向對象設計

設計原則

模塊化、高內聚、低耦合、複用性

軟件體系結構

涉及軟件系統的整體組織、全局控制、數據存取以及子系統之間的通訊協議等。

典型軟件體系結構：倉庫體系結構、分層體系結構、MVC體系結構、客戶機/服務器體系結構、管道和過濾體系結構

• 倉庫體系結構：在倉庫體系結構中，有兩種不一樣的軟件部件：一個表示當前的中心數據結構和一組相互獨立的處理中心數據的子系統。倉庫體系結構無需在子系統之間進行數據轉換，於是是一種共享大量數據的高效方法，並且只要與共享模型一致，新的子系統就能夠很容易的增長到系統中

• 分層體系結構：層次化是一種概念，它將軟件設計組織成爲類或組件的層次或集合，在同一個層次上的類或組建完成一個特定的目的，良好的層次結構能夠易與系統的擴建與維護，不一樣的層次之間經過接口進行通訊

• MVC子系統：在MVC體系結構中，子系統劃分紅不一樣的三種類型：模型子系統負責存儲系統的中心數據；視圖子系統負責將模型中的數據展現給用戶；控制器子系統負責管理與用戶的交互控制

• 客戶機/服務器子系統：在客戶機/服務器體系結構中，做爲服務器的子系統爲其餘客戶的子系統提供服務，做爲客戶機的子系統負責與用戶的交互。

• 管道和過濾體系結構：在管道和過濾體系結構中，數據在不一樣的子系統之間流動，每個子系統處理輸入的一組數據，並將處理結構輸出給其餘子系統。

詳細設計

方法建模、屬性建模、狀態建模、關係建模

泛化關係

也就是繼承關係，也稱爲「is-a-kind-of」關係，泛化關係用於描述父類與子類之間的關係，父類又稱做基類或超類，子類又稱做派生類。在UML中，泛化關係用帶空心三角形的直線來表示。

設計模式

廣義講，軟件設計模式是可解決一類軟件問題並能重複使用的軟件設計方案；狹義講，設計模式是對被用來在特定場景下解決通常設計問題的類和相互通訊的對象的描述。是在類和對象的層次描述的可重複使用的軟件設計問題的解決方案。 分類

• 應用角度（3）
  • 建立型模式（用來建立對象的模式，抽象了實力化過程）
  • 結構型模式（討論的是類和對象的結構，採用繼承機制來組合接口）
  • 行爲型模式（着力解決的是類實體之間的通信關係，但願以面向對象的方式描述一個控制流程）
• 模式範圍（2）
  • 類模式

  • 對象模式 - Factory模式（工廠模式） 對象型建立模式

    父類負責定義建立對象的公共接口，而子類則負責生成具體對象，將類的實例化操做延遲到子類中完成。

  - Adapter模式（適配器模式）
  
      將一個類的接口適配成用戶所期待的接口。一個適配器容許由於接口不兼容而不能在一塊兒工做的類在一塊兒工做。作法是將類本身的接口包裝在一個已經存在的類中。
    - Bridge模式（橋樑模式）
  	
      將問題的抽象和實現分離開來實現，經過用聚合代替類繼承來解決子類爆炸性增加的問題。
  	  
    - Façade模式（外觀模式）
  	
      爲子系統提供一個更高層次、更簡單的接口，從而下降了子系統的複雜度，使子系統更易於使用和管理。

第十章 軟件測試

• 軟件產品在交付使用前，通常須要通過單元測試、集成測試、確認測試和系統測試

單元測試任務：

• 模塊接口測試（單元測試的基礎，主要檢查數據可否正確地經過模塊）
• 模塊局部數據結構測試（局部數據結構每每是錯誤的根源）
• 模塊中全部獨立執行通路測試
• 模塊的各條錯誤處理通路測試
• 模塊邊界條件測試

集成測試

將全部模塊按照設計要求組裝成一個完整的系統而進行的測試，也稱組裝測試或聯合測試，目的是發現與接口有關的各類錯誤方法 非增量式測試（把全部的模塊按設計要求組裝在一塊兒進行的總體測試）、增量式測試（逐個把模塊組裝到已經測試過的模塊上去，進行集成測試。每加入一個新模塊進行一次集成的測試，重複此過程直至程序組裝完畢）、

確認測試

經過集成測試後，軟件已經徹底組裝了起來，接口方面的錯誤也已排除，這時就能夠對軟件進行最後的確認測試。

• 其任務是檢查軟件可否按合同要求進行工做，便是否知足需求規格說明書中的確認標準。
• 確認測試方法：黑盒測試法。
• 確認測試的2種結果
  • 軟件功能和性能指標知足軟件需求說明的要求，用戶可接受。
  • 軟件不知足軟件需求說明的要求，用戶沒法接受。
• 步驟
  • 有效性測試：檢查軟件可否按合同要求進行工做，便是否知足需求規格說明書中的確認標準。
  • 軟件配置複查：保證軟件配置齊全。

系統測試

把軟件、硬件和環境鏈接在一塊兒，在實際運行環境下進行全面測試，驗證系統各部件是否都可以正確工做並完成任務。

• 恢復測試（主要檢查系統的容錯能力）
• 安全測試（主要檢查系統對非法侵入的防範能力）
• 強度測試（強度測試檢查程序對異常狀況的抵抗能力；是檢查系 統在極限狀態下運行的時候性能降低的幅度是否在容許的範圍內）
• 性能測試

軟件調試

• 調試方法
  • 簡單的調試方法
  • 概括法調試
  • 演繹法調試
  • 回溯法調試

黑盒測試

該方法把被測試對象當作一個黑盒子，測試人員徹底不考慮程序的內部結構和處理過程，只在軟件的接口處進行測試，依據需求說明書，檢查程序是否知足功能要求。

方法：等價類劃分、邊界值分析、錯誤推測等

白盒測試

該方法把測試對象看做一個打開的盒子，測試人員須瞭解程序的內部結構和處理過程，以檢查處理過程的細節爲基礎，對程序中儘量多的邏輯路徑進行測試，檢驗內部控制結構和數據結構是否有錯、實際的運行狀態與預期的狀態是否一致。

方法：邏輯覆蓋、基本路徑測試

等價類劃分方法

1) 若是某個輸入條件規定了取值範圍或值的個數，則可肯定一個合理的等價類(輸入值或數在此範圍內)和兩個不合理的等價類（輸入值或數不在此範圍） 2) 若是規定了輸入數據的一組值，並且程序對不一樣的輸入值作不一樣的處理，則每一個容許的輸入值是一個合理等價類，此外還有一個不合理等價類（任何一個不容許的輸入值） 3) 若是規定了輸入數據必須遵循的規則，可肯定一個合理等價類（符合規則）和若干個不合理等價類（從各類不一樣角度違反規則） 4) 若是已劃分的等價類中各元素在程序中的處理方式不一樣，則應將此等價類進一步劃分爲更小的等價類

第十一章 軟件演化

軟件維護

軟件被投入運行使用後人們對軟件產品所進行的修改 目的：爲了修改軟件缺陷或增長新的功能而對軟件進行的變動。 軟件變動一般發生在局部，不會改變整個結構

• 類型（軟件維護的不一樣緣由）
  • 改正性維護：修改軟件中的缺陷或不足
  • 適應性維護：修改軟件使其適應不一樣的操做環境，包括硬件變化、操做系統變化、數據庫更換等其餘支持軟件變化。
• 完善性維護：增長或修改系統的功能，使其適應業務的變化。

特色：受開發過程影響大、維護困難多、維護成本高

過程：維護申請→維護分類→影響分析→版本規劃→變動實施→軟件發佈

軟件再工程

軟件再工程以系統理解爲基礎，結合反向工程、重構和正向工程等方法，將現有系統從新構形成爲新的形式。形象地說，就是「把今天的方法學用於昨天的系統以知足明天的須要」。

反向工程

• 是一種設計恢復過程，它是從現有系統的源代碼中抽取數據結構、體系結構和程序設計信息。
• 可使用CASE工具自動處理，也能夠手工分析。
• 儘可能找出程序的基本結構，並在進一步理解的基礎上添加一些設計信息，逐步抽象創建系統設計模型。

正向工程

• 利用從現有程序中恢復的設計信息而修改或重構現有系統，以提升系統的總體質量。
• 一般正向工程並非簡單地構造一個與原有系統功能等價的系統，而是結合新的用戶需求和軟件技術擴展原有系統的功能和性能。