第一章 概述
軟件
軟件是計算機程序、規程以及運行計算機系統可能需要的相關文檔和數據，從軟件的內容來看，軟件更像是一種嵌入式的數字化知識，其形成是一個通過交互對話和抽象理解而不斷演化的過程，根據軟件服務對象的范圍，一般分為通用和定制兩種。
- 通用軟件(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工具自動處理，也可以手工分析。
- 盡量找出程序的基本結構，並在進一步理解的基礎上添加一些設計信息，逐步抽象建立系統設計模型。
正向工程
- 利用從現有程序中恢復的設計信息而修改或重構現有系統，以提高系統的整體質量。
- 通常正向工程並不是簡單地構造一個與原有系統功能等價的系統，而是結合新的用戶需求和軟件技術擴展原有系統的功能和性能。