概述

22級軟件工程考試細節及復習相關問題見下面這篇帖子，作者自己復刻了一版真題

吉林大學軟件工程2025年期末真題（回憶復刻版）-CSDN博客

下面是作者復習時整理的筆記，放到csdn之后序號排版稍微有點亂

21級考試情況可以參考學長的這篇帖子：

吉林大學計科21級《軟件工程》期末考試真題_吉林大學軟件工程期末-CSDN博客

---

重點結構梳理

車海燕老師總結的考試重點，僅供參考

第一章

1. 軟件與軟件危機涉及到的概念，軟件危機的一些現象，軟件工程的基本原則

2. 軟件的主要特點

3. 軟件生命周期的劃分，軟件定義，軟件開發和軟件的運行維護

4. 定義階段包括問題定義、可行性研究、需求分析

5. 開發階段包括軟件設計（主體設計和詳細設計）、實現（編碼和測試）

6. 運行維護

第二章 軟件過程

1. 各種模型：瀑布模型、V模型（簡單了解）、快速原型模型、階段式開發、螺旋模型、噴泉模型

2. RUP和敏捷過程（概念、核心思想、優點缺點）、微軟過程（略過）

第三章 可行性研究

1. 可行性研究：概念，技術、經濟、操作、法律等方面的可行性

2. 系統流程圖不做要求，成本效益分析簡單了解

第四章 需求分析（重點）

1. 軟件的需求、從哪幾個方面、為什么重要、為什么獲取困難

2. 軟件需求要滿足的特征：正確性、完整性、可追溯性、可實現性、可測試性（不具有可測試性時該如何調整，量化）

3. 數據流圖：相關概念、分步驟繪制（基本系統模型、功能級的數據流圖、細化的數據流圖），填寫缺失內容，需要會完整畫最頂層的數據流圖

4. 數據流圖注意事項：父子圖的平衡、數據流的命名問題、什么時候使用數據存儲文件

第五章 總體設計

1. 設計原理和啟發式規則（含義，重點回顧）

2. 重點掌握7個不同程度的劃分（內聚和耦合）

3. 面向數據流的設計方法，變換流、事務流（映射過程特別注意）

4. 體系結構風格（重點掌握管道過濾器、層次兩種）

第六章 詳細設計

1. 過程設計（表達方式）

2. 人機交互界面（重要性、考慮的問題）

3. 程序復雜度的定量度量（會畫流圖）

第七章 編碼和測試（重點）

1. 編碼風格

2. 測試的原則和步驟

3. 黑白盒測試（等價位劃分、邊界值分析）

4. 基本路徑測試法

5. 集成測試（重點）

6. 軟件可靠性：計算平均故障時間MTTF

第八章 軟件維護

1. 維護的類型、影響

2. 決定軟件的可維護性有哪些

3. 提高可維護性

4. 軟件開發的各個階段都要做哪些事（維護性復審）

第九章 項目管理

1. 工程網絡圖的繪制以及相關的關鍵路徑，空余時間的計算

2. 人員組織方式（兩大）

3. 軟件配置管理（軟件配置項、期限、如何處理流程變化）

第十章 面向對象

1. UML基礎知識

2. 需求建模+OOA

---

第一章 軟件工程概論

一、軟件的定義

軟件=程序+數據+文檔（邏輯實體）

程序：按實現設計的功能和性能要求執行的指令序列

數據：使程序正常操作信息的數據結構

文檔：與程序開發、維護有關的圖文材料

二、軟件的特點

A. 邏輯實體而不是具體物理實體，有抽象性

B. 軟件開發中無硬件那樣明顯的制造過程，對軟件的質量控制必須著重在軟件開發方面下功夫

C. 軟件無硬件那樣的機械磨損與老化問題

軟件故障源于開發過程中存在錯誤，軟件不存在磨損與老化，但存在退化，退化源于修改。

三、軟件危機

1. 定義：計算機軟件在開發和維護過程中所遇到的一系列嚴重問題

? ? ? ? ? ? ? ?a. 如何開發軟件，以滿足日益增長的軟件的需求；

???????????????b. 如何維護軟件。

2. 軟件危機的原因：

????????1.? ?軟件本身的特點

??????????????????軟件的邏輯性

??????????????????程序的復雜性、規模龐大

????????2.??軟件開發和維護方法不正確

??????????????????忽略軟件定義時期的工作，特別是需求分析

??????????????????認為軟件開發就是寫程序并使之運行

??????????????????輕視維護

3. 消除軟件危機的途徑（正確認識、取長補短、更新換代）：

????????A. 對軟件有正確認識（軟件定義）

????????B. 充分認識軟件并不是一種個體勞動的神秘技巧而是一種組織良好、管理嚴密、各類人員協調配合共同完成的工程項目

????????C. 充分吸取借鑒人類長期以來在工程項目中積累的行之有效的原理、概念、技術和方法

????????D. 推廣使用實踐中總結出的開發軟件成功的技術和方法，迭代方法，消除早期階段的錯誤觀念和做法

????????E. 開發和使用更好的軟件工具

4. 軟件產品質量的最理想情況是以最低成本滿足所有要求

四、軟件工程定義?

????????軟件工程是指導計算機軟件開發和維護的一門工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它，這就是軟件工程

????????“軟件工程”術語是在1968年NATO會議被首次提出

五、軟件工程的本質特性

??A. 軟件工程關注大型程序構造（規模）

??B. 軟件工程中心課題是控制復雜性

??C. 軟件經常變化

??D. 開發軟件效率很重要

??E. 和諧合作是開發軟件的關鍵

??F. 軟件必須有效地支持它的用戶（價值）

??G. 軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品（兩個空間）

六、七條原理

1. 用分階段的生命周期計劃嚴格管理

2. 堅持階段評審（技術+管理）

3. 實行嚴格的產品控制（實行基準配置管理）

4. 現代化程序設計技術

5. 結果應能清楚地審查（可見性+清晰的標準）

6. 開發人員少而精（對應不能通過增加程序員數量來趕項目進度）

7. 承認不斷改進軟件工程實踐的重要性

七、軟件工程基本內容

????????軟件工程包括管理和技術兩方面內容。

????????管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。

????????技術方面通常把軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學（范型）。

八、軟件工程方法學的三要素

??????????方法：完成軟件開發各項任務技術的方法，回答“How”

??????????工具：軟件工具為軟件工程方法提供了自動或半自動的軟件支撐環境

??????????過程：為了獲得高質量軟件所需完成的一系列任務的框架，它規定了完成各項任務的步驟，將軟件工程的方法和工具綜合起來以達到合理、及時地進行軟件開發的目的。

??使用最廣泛的軟件工程學方法：

????傳統方法學：生命周期法/結構化范型（采用結構化技術，每一階段技術審查和管理復審，存在語義斷層問題，把數據和操作分開），不適用軟件規模龐大、需求模糊或經常變化的情況

????面向對象方法學：對象+類+繼承+消息通信，以數據為主線，封裝數據+操作，盡量模擬人類習慣的思維方式，使問題空間與求解空間在結構上盡可能一致

九、軟件生命周期

1. 軟件定義

   1. 問題定義

   2. 可行性研究

   3. 需求分析

2. 軟件開發

   1. 總體設計

   2. 詳細設計

   3. 編碼和單元測試

   4. 綜合測試（集成測試/驗收測試/現場測試/平行運行）

3. 運行維護

   1. 適應性維護

   2. 改正性維護

   3. 完善性維護

   4. 預防性維護

---

第二章 軟件過程

一、重要概念

1. 過程：產生某種預定輸出的一系列可預測的步驟（包含一組活動、約束、資源要素） 或使用資源將輸入轉化為輸出的活動所構成的系統

2. 過程的特性：

   1. 使用一定資源、受一定限制，生成一定中間及最終產品

   2. 過程包含的活動事先都規定好

   3. 過程中每個活動的開始、結束有明確的規定

   4. 每項活動都有相應指導規則，用以明確目標

   5. 各活動以順序組織

   6. 過程可能包括若干相關關聯子過程

   7. 過程中的活動、資源以及產品都可能受約束

3. 為什么使用過程：

   1. 能保證各活動之間是有組織和一致的

   2. 可被檢查、理解、控制和改進

   3. 過程也是傳授經驗的一種方式

4. 軟件過程：為建造高質量軟件所需完成任務的框架，它規定了完成各項任務的工作步驟

5. 軟件過程與軟件工程的關系：

   1. 軟件工程實踐應該是由有創造力、有知識的人在定義好的、成熟的軟件過程中進行的，該過程適合于他們建造的產品和他們的市場需要

   2. 軟件過程定義了軟件開發中采用的方法，但軟件工程還包含該過程中應用的其他技術和工具

6. 當談及的過程涉及到某種產品的建造時，常把過程稱作為生命周期

軟件過程與軟件生命周期的關系：

1. 軟件過程是在軟件生命周期中所實施的一系列活動的集合

2. 軟件生命周期與選擇的軟件過程有關，不同的軟件過程可能對應不同的軟件生命周期

二、瀑布模型

1. 瀑布模型的特點：

   1. 階段間具有順序性和依賴性

   2. 盡量推遲物理實現

   3. 質量保證：每個階段都必須完成規定的文檔，并對文檔評審

2. 瀑布模型的優點：

   1. 可強迫開發者采用規范的方法

   2. 嚴格規定每階段必須提交文檔

   3. 每階段的產品都經過質量保證小組驗證

   4. 實質是一種文檔驅動的模型（既是優點也是缺點）

3. 瀑布模型的缺點：

   1. 要求用戶不經過實踐就直接提出完整準確的需求，大多數情況下不切實際

   2. 僅通過紙面上的規格說明（靜態）很難完整正確地認識軟件產品（動態）

   3. 軟件開發過程被強行線性化，不符合非線性化的開發實際

   4. 軟件開發耗時長，可運行的軟件版本在后期才會得到，一旦出問題，代價巨大

   5. “文檔驅動”可能最終開發出的軟件產品不能真正滿足用戶的需求

三、V模型（簡單了解）

本質是把瀑布模型中隱含的迭代過程明確出來，使抽象等級的概念更加明顯

改進了的瀑布模型，強調測試和分析設計之間的關聯

• 單元、集成測試校驗程序設計

• 系統測試校驗系統設計

• 驗收測試確認需求

是活動驅動的

過于簡單、理想化的抽象，仍未解決對需求變化適應性差的問題

驗證與確認：是否正確的完成某部分/完成某部分工作是否滿足需求

四、原型/快速原型模型

快速建立起一個可以在計算機上運行的程序，往往是最終產品的一個子集

1. 采用原型法時，關鍵的因素是建立模型的速度，而不是原型運行的效率。

2. 原型化方法從用戶界面的開發入手，首先形成系統界面模型，并就“同意什么和不同意什么”提出意見

1. 優點：

   1. 不帶反饋環，軟件的開發基本線性進行

      1. 原型系統已與用戶交互得到驗證

      2. 開發人員在建立原型時已經學到很多（避免錯誤）

   2. 利用原型有助于統一和增強客戶和開發者對需求的理解、定義、確認

   3. 可以結合瀑布模型，兩者互補性強

2. 缺點：

   1. 原型不可能面面俱到

   2. 客戶：不可把原型當作正式運行的軟件

   3. 開發者：同上，還需牢記沒有考慮質量因素的部分

   4. 原型只是模型而已，不能從原型得到最終的產品（進化原型模型可以，從原型迭代得到最終產品）

五、階段式開發（演化模型）

（1）漸增式開發：

1. 增量模型是一種需要快速構建核心產品的好方法

2. 增量模型把軟件作為一系列增量構件來設計、編碼、集成和測試

3. 每個構建由多個相互作用的模塊構成，完成特定的功能

4. 第一個構建實現基本需求、提供最核心功能

??優點：

1. 適用于人手不足、不能在軟件項目期限之前實現一個完全版本的軟件的情況

2. 能有計劃地管理技術風險

3. 每個增量都發布一個高質量的可操作的版本，用戶能在較短時間內使用上部分內容

4. 逐步增加產品功能，使用戶有比較充裕的時間來學習和適應新產品

??難點：（核心：增量模型結構導致的矛盾和沖突）

1. 軟件體系結構必須是開放的，每個新的增量構件無縫集成到現有軟件體系結構，增加了設計階段的投入

2. 本身具有矛盾性，一方面要求將軟件看作一個整體，一方面要求把軟件看作構件序列，且構件之間彼此獨立，需要開發人員協調這一矛盾

（2）迭代式開發（螺旋模型）：風險驅動

基本思想：使用原型以及其他方法來盡量降低風險

可看做每個階段之前都增加風險分析過程的快速原型模型

優點：

1. 是對瀑布模型的發展，由客戶對階段性結果做出評審，對保證軟件質量十分有利

2. 引入風險分析，測試活動的確定性增強

3. 最外層代表維護，開發與維護采用同樣方式，使維護與開發得到同樣的重視

缺點：

1. 適合內部開發，否則風險分析要在合同前完成或者客戶理解（分析之后可能會取消，風險若消除不掉就終止）

2. 只適合大項目，風險分析占比過大，占用資源，增加成本

3. 對風險分析能力要求高，否則會退化為瀑布模型或更糟

六、噴泉模型

1. 噴泉體現了面向對象軟件開發過程迭代和無縫的特性（相鄰兩個過程可能有重合）

2. 階段之間可以重疊，沒有明顯的界限

3. 迭代性，像噴泉一樣可以來回上下

4. 為了避免過于無序，應該把一個線性過程作為總目標

5. 容易進行維護工作

七、RUP（統一軟件開發過程）

1. RUP是一種過程框架、詳細規范性過程模型

   1. 其軟件知識庫基本上涵蓋了軟件開發的所有活動

   2. 為面向對象設計和開發提供了定義明確的結構

   3. RUP之中的設計和文檔記錄都使用UML

   4. 理想開發環境下軟件過程的一種完美形式，但沒有給出具體完整的部署方案

2. RUP最佳實踐

   1. 迭代式開發 ：容納需求變更/減少風險

   2. 管理需求（用例和腳本）

   3. 基于構件的體系架構（一開始就需要給出）

   4. 可視化建模（UML，便于確保一致性和溝通交流，盡早發現問題）

   5. 驗證質量（貫穿全流程，越晚發現成本越高）

   6. 控制軟件變更

3. 迭代式開發特點

   1. 在大規模投資之前，關鍵風險已得到解決

   2. 初始迭代可以支持早期的用戶反饋

   3. 經常進行測試和集成

   4. 通過目標里程碑來聚焦于短期工作重點（短周期）

   5. 進度是通過評估實施情況來衡量的（用實現多少功能評估）

   6. 可以部分實現、部分部署（目的：盡快部署，對應瀑布模型風險問題）

4. 九個核心工作流（靜態）

   過程工作流	支持工作流
   業務建模 需求 分析與設計 實現 測試 部署	配置與變更管理 項目管理 環境提供

5. 工作階段（動態） 二維生命周期

????????Inception（先啟）：生命周期目標里程碑

????????建立業務模型，定義最終產品視圖，確定項目的范圍

????????Elaboration（精化）：生命周期架構里程碑

????????設計并確定系統的體系結構，制定項目計劃，確定資源需求

????????Construction（構建）：初始可操作性能里程碑

????????開發所有構件和程序，集成為客戶需要的產品，測試所有功能

????????Transition（移交）：產品發布里程碑

????????把開發出的產品提交給用戶使用

? 6. RUP 迭代式開發

1. 每個項目開發過程由多個迭代過程組成

2. 每次迭代只考慮一部分系統需求

3. 每個迭代都是風險驅動的

4. 每個迭代都可以看作是一個“小型瀑布模型”過程（以一個交付版本結束，結果是一個增量）

5. 每次迭代以不同的重點和強度訪問核心工作流

7. RUP生命周期的特點（與螺旋模型相比）

1. 給出每個階段迭代完成交付的增量的具體要求，即四個階段的里程碑

2. 詳細闡述了九大核心工作流程中活動內容的重點和強度不同

3. 對每次迭代過程中不同核心工作流程活動的并行化支持

8. RUP 優點：

1. 用例驅動、以架構為中心、迭代和增量；

2. 具有二維迭代性，有利于降低風險、適應需求變化（每次迭代都是風險驅動的）；

3. 是可配置的，具有通用性；

9. RUP 缺點：

1. 在理想的項目開發環境下軟件過程的一種完美模式；

2. 未給出具體的剪裁、擴充等配置實施的方法準則。

八、敏捷過程

1. 敏捷過程的價值觀：

   1. 個體和交互 勝過 過程和工具

   2. 可以工作的軟件 勝過 面面俱到的文檔

   3. 客戶合作 勝過 合同談判

   4. 響應變化 勝過 遵循計劃

2. 價值驅動，資源、時間有限且固定

3. 高可視性，高可適應性，持續產出業務價值

4. 強調適應而非預測變化，以人為中心

   1. 人是軟件項目獲得成功最為重要的因素

   2. 軟件開發的主要目標是交付可以工作的軟件，編輯的文檔應盡量短小并且主題突出

   3. 制定細致度逐漸降低的計劃

   4. 簡單化設計，只涉及與當前迭代最吻合的手段，不會進行過度設計（對質量要求較高的情況下可以采用RUP）

   5. 到了開發的后期也歡迎改變需求，利用變化來創造競爭優勢

   6. 交付的時間間隔越短越好

   7. 工作的軟件是首要的進度度量標準

實例：

（1）極限編程（XP）：把最好的開發實踐運用到極致

????????適用：需求模糊且經常改變

????????特點：對變化和不確定性反應更迅速、更敏捷；快速的同時保持可持續的開發速度

????????使用用戶素材獲取需求、測試驅動開發（先寫測試代碼，再具體編寫程序）、結對編程

????????持續的集成、可持續的開發速度、重構、使用隱喻（全局視圖）

（2）Scrum方法：

????????三個特點：關注當下（簡單性）、放權（團隊自組織，自己協調如何完成任務）、提高溝通效率（面對面交流）

????????重要概念：待辦事項列表（產品列表），2-4周的沖刺/迭代（每次增量待辦事項or用戶故事），團隊做出承諾主動認領任務，每天進行反思戰略會議

????????三個角色：產品負責人，Scrum Master（教練，監督，不要管理團隊），開發團隊（多功能團隊，保證團隊不受外界干擾）

5. 敏捷過程的特點：

1. 生命周期：敏捷過程是一維，RUP是二維、雙重

2. 人員：

   1. 敏捷過程強調了客戶這一角色的重要性，各成員個體地位關系平等，職責是共同的；首要協作方式為面對面交談

   2. RUP按照角色分工，未給出地位關系，通過”形式化的文檔--模型“協作交互

3. 方法：敏捷過程動態滿足需求，簡單化；RUP以用例驅動方法，以架構為中心；整個過程建模都采用UML

4. 產品：RUP未確定形式化的文檔--模型與軟件兩者的優先級；敏捷過程認為軟件勝過面面俱到的文檔

5. 敏捷開發適合需求模糊或頻繁變化、小型創業項目軟件、客戶深度參與（短平快，團結一致做）

6. 微軟過程：對XP和RUP的結合，選取各自的優勢

九、DevOps（開發運維一體化）

??持續集成（確保軟件可運行）->持續交付（確保處于隨時可部署的狀態同時實現快速交付）->持續部署（從代碼變更提交到生產環境部署，端到端快速推進）

1. 開發部署速度快，提高效率

2. 快速解決故障，產品質量更高

---

第三章 可行性研究

1. 目的：用最小的代價，在盡可能短的時間內確定問題能否解決

2. 實質：一次壓縮、簡化的系統分析和設計過程

3. 根本任務：對日后行動方針提出建議

4. 可行性研究的成本一般為預期總成本的5%-10%

5. 方面：兩個重點（技術可行性，經濟可行性）

   1. 技術可行性：使用現有的技術能實現這個系統嗎，要解決技術風險問題

   2. 經濟可行性：這個系統的經濟效益能超過他的開發成本嗎？

   3. 操作可行性：系統的操作方式在這個用戶組織內是否行得通

   4. 法律可行性：可能導致的任何侵權、妨礙和責任

   5. 開發方案的選擇性研究：提出多種方案并推薦較優方案

6. 可行性研究過程

7. 系統流程圖（未做要求）：

1. 是概括地描繪物理系統的傳統工具

2. 它的基本思想是用圖形符號以黑盒子形式描繪組成系統的每個部件

3. 它表達了數據在系統各部件之間的流動情況

8. 系統流程圖的分層：

1. 用一張高層次的系統流程圖描繪系統的總體概貌，表明系統的關鍵功能

2. 分別把每個關鍵功能擴展到適當的詳細程度，畫在單獨的一頁紙上

3. 便于閱讀者按從抽象到具體的過程逐步深入地了解一個復雜的系統

9. 成本/效益分析的第一步是估計開發成本、運行費用和新系統將帶來的經濟效益

10. 成本估計：

（1）代碼行技術：

??估計的成本：e=(a+4m+b)/6

??其中，a是最樂觀估計的成本，b是最悲觀估計的成本，m是一般估計的成本

（2）任務分解技術

（3）自動成本估計技術

運行費用：操作費用和維護費用

經濟效益：使用新系統增加的收入和可以節省的運行費用

1. 投資回收期：使得累積的經濟效益等于最初投資所需要的時間

2. 貨幣的時間價值

---

第四章 需求分析

一、概述

1. 需求：就是系統的特征（Features），或對系統為達到某個目標所能做的事情的一個描述（是問題信息和系統行為、特性、設計及制造約束的描述的集合）

2. 需求分析的目標

需求分析要求系統必須確定完成哪些工作，及對目標系統提出完整、準確、清晰、具體的需求

3. 需求難以建立的原因

誤解；交流障礙；“完整性”問題；需求永遠不會穩定；用戶意見不統一；錯誤的要求；認識混淆

4. 兩種需求：（系統需求/客戶需求）

??功能需求：系統與環境之間的交互——描述系統必須支持的功能和過程的系統需求

??非功能需求：客戶給出的具體約束、指標——描述操作環境和性能目標的系統需求

??區別：功能性需求描述系統應該做什么，非功能性需求描述為如何實現功能性需求設定約束

??非功能需求必須依附于功能需求而存在

5. 兩種需求文檔

??????????需求定義：需求的描述，用應用域語言，客戶/和用戶和開發人員共同編寫

??????????需求規約：軟件需求規格說明，用開發人員擅長的技術術語編寫，分析人員編寫

二、需求分析的任務

1. 必須理解并描述問題的信息域：根據這條準則應該建立數據模型（ER模型，類圖）

2. 必須定義軟件應完成的功能：這條準則要求建立功能模型（數據流圖，用例模型）

3. 必須描述作為外部事件結果的軟件行為：這條準則要求建立行為模型（狀態轉換圖，UML行為圖）

4. 必須對描述信息、功能和行為的模型進行分解：用層次的方式展示細節

5. 確定對系統的綜合要求

6. 分析系統的數據要求

7. 導出系統的邏輯模型

8. 修正系統的開發計劃

三、需求過程

1. 定義：用來導出、確認和維護系統需求文檔的一組結構化活動

2. 需求過程本質：在問題空間與求解空間中間架設橋梁

3. 三個階段：

   ?? 針對進行了需求分析和協商之后進行最終確認。也可以使用原型技術（能用于試驗，反應系統性能、效率）

   1. 需求提取

      ????發現需求的過程，從項目干系人角度考慮發現它們的真正需求。

      ????系統需求的資料來源 主要是項目干系人

      ????與用戶溝通獲取需求的方法：

      • 訪談

      • 面向數據流自頂向下求精

      • 簡易的應用規格說明技術FAST（面向團隊）

      • 場景分析

      • 快速建立軟件原型（是開發用戶接口的唯一有效方式，需求提取階段僅用于發現功能需求）

      ????不提倡把原型做成最終系統（原型趨向于非結構化，系統靈活性降低、長期成本增加、系統生存期縮短）

      需求提取中注意的事項：

      1. 確定系統的邊界

      2. 從多個角度考察待解決的問題（確定需求優先級）

      3. 把需求按照必要程度分三類

   2. 需求分析與協商

      1. 初步篩查（是否滿足需求的特性）、不同干系人需求的沖突和解。

      2. 比原始需求更加精準和完整。

      3. 需求分類：發現需求之間的共性和例外關系、提高文檔跟蹤能力、幫助找到遺漏的需求

      4. 使用交互矩陣發現沖突與重疊

      5. 保證需求是可測試的：摒除需求中不確定、不完整、不正確的部分，使用定量描述

   3. 需求確認

四、需求的表達方法-系統模型

1. 流程：綜合要求->數據要求->導出目的系統的邏輯模型->修整系統的開發計劃

2. 分類：

????????（1）行為模型（包含所有過程層面的內容）：

??????????????????功能模型：描述數據的功能轉換，兩種方式：DFD，面向對象觸發相應服務

??????????????????動態模型：描述與時間有關的變化

???????（2）結構模型（靜態模型）：描述系統的實體結構

五、結構化分析方法

1. 傳統的結構化分析方法是一種面向數據流進行需求分析的方法

2. 具體而言，傳統的結構化分析方法就是用抽象模型的概念，按照軟件內部數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟件為止

3. 導出目標系統的邏輯模型

? 4. 結構化分析方法從三個方面建模：

??????????核心：數據字典

??????????數據建模——實體關系圖

??????????功能建模——數據流圖

??????????行為建模——狀態轉換圖

六、狀態轉換圖

1. 活動表的語法格式如下： 事件名(參數表)/動作表達式

2. 事件表達式的語法如下： 事件說明［守衛條件］／動作表達式

3. 其中，事件說明的語法如下: 事件名(參數表)

4. 數字電路中的時序邏輯電路圖就涉及了狀態轉換圖的畫法，操作系統中就緒態、掛起態和運行態的轉換也可用狀態圖表示

七、數據流圖（DFD）

1. 定義：描述數據在系統中如何被傳送或變換，以及描述如何對數據流進行變換的功能

2. 數據流圖所使用的符號：

   ??源點、終點：系統之外的實體，是為了幫助理解系統接口而引入的

   ??加工/變換：對數據進行處理的單元。要編號和起合理的名字

   ??數據流：一組數據項組成，不能在源點/終點和數據存儲之間流動

   ??文件：暫存數據。

   ??特殊符號：*：表示且；$$\oplus$$：表示異或

特別注意：

1. 數據流和數據存儲支持了數據的抽象，將數據視為系統中的實體，而不關注數據的具體內容或實現細節

2. 數據流不能在源點/終點、數據存儲之間流動。

3. 對于一些簡單的加工過程可以直接寫在數據字典的條目里，而如果是一些很復雜的加工就要使用判定表等方式來進行記錄。

4. 一個加工的分解子加工個數應當控制在7+2以內。

5. 通常先為數據流命名，然后再為與之相關聯的處理命名。

????????3. DFD

?4. 層次化的數據流圖

為了表達詳細的加工情況，將采用層次結構的數據流圖。具體來說，采用自頂向下逐層構建數據流圖的方式

步驟：

1. 首先構建頂層數據流圖（基本系統模型）：只含有一個代表軟件系統整體處理功能的轉換

2. 畫出系統的內部（系統功能級數據流圖）：將頂層中的處理分解為若干多個處理

3. 畫處理的內部：把每個處理看成一個小的系統，用第2步的方法畫出每個處理的數據流圖子圖

4. 重復3，直到尚未分解的處理都足夠簡單

編號原則：

每個處理的子處理編號由父處理加細得到。例如：3號處理的子處理依次編號為3.1，3.2等

父圖與子圖的平衡問題：

子圖的輸入/輸出數據流必須與父圖的輸入/輸出數據流必須一致，不得添加或減少（然而，如果父圖中的數據流可以被加細為多個子圖中的數據流，也認為是平衡的）

局部文件問題：

文件(數據存儲)總是局部于分層數據流圖的某一層或某幾層,所以數據流圖中引入的文件都是局部文件。

命名問題：

首先為數據流命名：名字要代表整個數據流的內容，要具體有含義，如果命名困難，則說明應當繼續分解 然后為與數據流關聯的處理命名：規則與數據流命名類似，當一個處理命名時要使用兩個或多個動詞時，將該處理繼續分解。

5. 數據流圖用于：

1. 作為交流信息的工具

2. 作為分析和設計的工具，考慮系統的物理實現

3. 映射出軟件結構

八、數據字典

1. 數據字典是對數據流圖中包含的所有元素的定義的集合。相當于是畫出數據流圖之后對其中的元素進行詳細說明，即定義。讓模型不出現歧義性！

2. 數據字典與數據流圖共同構成系統的邏輯模型。

3. 數據字典包括了對 數據流、數據流分量（數據元素）、數據存儲、處理 四類元素的定義

4. 數據流和數據流分量的區別在于，數據流分量是不可再分的單位，是最小的單位。

5. 寫加工邏輯說明的工具：

   1. 結構化英語

   2. 判定表（依賴多個邏輯條件的取值，不包含處理的順序）

   3. 判定樹

九、其他圖形工具

1. 層次方框圖（描繪數據的層次結構）、Warnier圖（描繪信息的邏輯組織）、IPO圖（描繪數據的關系）

2. 從哪些方面驗證軟件需求的正確性：（驗證軟件需求的方法就是驗證這四個性質）

   1. 一致性

   2. 完整性

   3. 現實性

   4. 有效性

---

第五章 總體設計

一、軟件設計過程

1. 軟件設計的本質：

   1. 軟件設計是軟件開發過程中承前啟后的工作

   2. 軟件設計是在軟件開發中形成質量的地方

   3. 是將需求準確轉換為完整的軟件產品或系統的唯一辦法

2. 軟件設計過程圖：

3.? 概要設計：即總體設計，將需求轉化為數據結構和軟件的系統結構，即系統的模塊劃分

? ? ?詳細設計：得到軟件的詳細數據結構和算法

4. 系統設計階段：確定系統的具體實現方案

? ?結構設計階段：確定軟件結構

????系統設計階段通常涉及確定系統的整體功能、模塊劃分、數據結構、算法選擇等，以便實現系統所需的功能。這個階段關注的是系統的整體實現方案，包括了系統的功能性和非功能性需求的實現方法。

? ? ?而結構設計階段則是在系統設計階段的基礎上，進一步明確軟件系統的組織結構和各個模塊之間的關系，以及確定具體的編程語言、開發框架、數據庫設計等方面的細節。在這個階段，重點是確定軟件的架構，包括模塊化設計、接口定義、數據流和控制流的設計等。

9個步驟了解

軟件設計規約：

1. 需求分析 -> 確認測試

2. 概要設計 -> 系統測試

3. 詳細設計 -> 單元測試

4. 詳細設計規約主要作為軟件設計人員與編程人員之間交流的媒體

5. 概要設計規約主要作為軟件項目管理人員、系統分析人員與設計人員之間交流的媒體

二、軟件設計原理

1. 模塊化：將程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求

   ??比直接完成整個功能工作量要小，但鏈接成本可能會增加，模塊并非越多越好

   ??模塊是可單獨命名和可編址的部分

2. 抽象：抽出事物的本質特性 而暫時不考慮它們的細節。

????????軟件工程過程的每一步都是對抽象的細化（精化）

??????????????????過程抽象：把一個功能抽象成一個函數，比如connect。

??????????????????數據抽象：把一個數據對象抽象成一個數據類型，比如class person

?????3. 逐步求精：為了能集中精力解決主要問題而盡量推遲對問題細節的考慮

????????抽象程度不斷下降實際上是一個逐步求精的過程。自頂向下的設計策略，就是從抽象到具體。

????????4. 信息隱藏和局部化

????????信息隱藏：模塊其中包含的信息對不需要他們的其他模塊來說是不可訪問的，隱藏的是模塊的實現細節。相當于只使用，不關心實現。

????????局部化：把關系密切的軟件元素物理地放得彼此靠近。相當于把關系密切的元素封裝成一個類

??????5. 模塊獨立性：每個模塊完成一個相對獨立的子功能，并且和其他模塊之間的關系很簡單

????????上面四個的直接結果。

????????模塊獨立程度的定性標準度量

?耦合：不同模塊之間彼此互相依賴，耦合度高表示模塊之間聯系緊密。耦合度越高模塊獨立性越小。

????????????內聚：模塊內部元素之間互相結合的緊密程度，與耦合相反

? 三、耦合

1. 耦合強弱取決于接口的復雜程度、進入或訪問一個模塊的點、通過接口的數據

2. 在軟件設計中應該追求盡可能松散耦合的系統，即盡可能獨立的模塊。

3. 耦合類型：（耦合性從低到高，模塊獨立性從強到弱）

????????（1）非直接耦合（弱）：無直接連接，由主模塊調用。

????????如編譯原理課程設計，main函數分別調用語義分析和語法分析

????????（2）數據耦合（弱）：相當于使用一個簡單的參數調用另外一個模塊的功能

????????（3）標記耦合（弱）：與數據耦合不同的是，這里傳遞的參數不是一個簡單變量而是一個記錄信息（參數表），但是可能用到的只是記錄中的非常小的部分。

????????把在數據結構上的操作全部集中在一個模塊中，可消除或轉化這種耦合。相當于本來是將整個記錄傳入另外一個模塊，現在是外加一個模塊用來操作這個記錄，最后傳入一個簡單變量。

????????（4）控制耦合（中等）：明顯地控制選擇另一模塊的功能。就比如程序A給出的控制信息決定了B是開涼水，還是開熱水，A必須知道B內部的邏輯關系。如果B改掉了，那么模塊A會受到影響，比如B換了控制信息。。//傳控制變量 or 傳地址（傳地址更高一點）

????????（5）外部耦合（較強）：全局的簡單變量。一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不是通過參數表傳遞該全局變量的信息，則稱之為外部耦合。

????????如C語言程序中有模塊訪問被修飾為extern的外部變量。注意是簡單變量！

????????（6）公共耦合（強）：它與外部耦合的區別在于，它是一組模塊都訪問同一個公共數據環境（如一個數據結構）！而非一個簡單全局變量。

????????（7）內容耦合（超強，高級語言不允許出現）： 還算是比較離譜的，相當于涉及到程序的指令地址了

四、內聚

1. 內聚表示的是模塊內部 各個元素的緊密程度。

2. 內聚度越高，則一個模塊內部越緊密，模塊獨立性就越強，這和耦合是相反的，耦合是不同模塊之間，不同模塊之間耦合度越高則獨立性越小。總的來說就是合字，都是緊密的意思，內部越緊密那它就越獨立，它若和別的模塊緊密則不獨立

1. 內聚類型：

????????（1）偶然內聚（弱）：沒有聯系，或者即使有聯系，這種聯系也很松散。

????????實際上就是多個模塊有相同代碼，執行相同功能，提取出來當做一個新模塊使用。這個沒有內在聯系，只是用到了同一段代碼而已

????????（2）邏輯內聚（弱）：這種模塊把幾種相關的功能組合在一起，每次調用時，由傳送給模塊的判定參數來確定該模塊應執行哪一種功能

????????整個模塊實現多種功能，具體執行哪種功能需要根據傳遞給該模塊的參數來確定（執行Kruskal還是Prim呢？）

????????（3）時間內聚（弱）：這個模塊大多是多功能模塊，在同一時間段內執行

????????時間內聚的這些模塊會在同一時間段全部執行完！但是他們之間可能沒啥聯系。比如數據庫初始化、界面初始化等一開始就得執行的

????????（4）過程內聚（中）：使用流程圖做為工具設計程序時，把流程圖中的某一部分劃出組成模塊，就得到過程內聚模塊。

????????例如，把流程圖中的循環部分、判定部分、計算部分分成三個模塊，這三個模塊都是過程內聚模塊。（有一定的過程性，但不一定順次執行）

????????這些模塊之間的耦合度可能比較高，單獨的一個模塊由于不是完整功能，內聚度可能也比較低。

????????（5）通信內聚（中）：如果一個模塊內部的各個功能使用了相同的輸入數據，或產生了相同的輸出數據

????????相當于模塊內部的東西，操作同一個數據集。

????????（6）順序內聚（強）：模塊內部的各個處理和同一個功能密切相關，并且必須順序執行

????????但是可能不包含整個功能，所以還不是最高的。

????????（7）功能內聚（強）：所有部分都是為了完成一項具體功能而協同工作，緊密聯系，不可分割的

五、啟發式規則

七條啟發式規則：

1. 改進軟件結構提高模塊獨立性

   ????降低耦合，提高內聚

2. 模塊規模應該適中

3. 深度、寬度、扇出和扇入都應適當

4. 模塊的作用域應該在控制域之內

   ????控制域：直接或間接從屬于它的模塊的集合

   ????作用域：它的一個判定影響的所有模塊集合

5. 力爭降低模塊接口的復雜程度

6. 設計單入口單出口的模塊

   ????避免出現內容耦合

7. 模塊功能應該可以預測 ，避免對模塊施加過多限制

   ????只要輸入的數據相同就產生同樣的輸出，這個模塊的功能就是可以預測的

將作用范圍移動到控制范圍的方法：

1. 將判定所在模塊合并到父模塊中，使判定處于較高層次；

2. 將受判定影響的模塊下移到控制范圍內；

3. 將判定上移到層次中較高的位置

六、面向數據流的設計方法

1. 結構化設計方法(SD方法)

   1. 把信息流映射成軟件結構

   2. 信息流可以分為變換流和事務流

   3. 變換型系統結構圖由輸入、變換中心和輸出等三部分組成。

   4. 一旦確定了軟件結構就可以把它作為一個整體來復查，從而能夠評價和精化軟件結構

   5. 特別注意全局特征和局部特征

2. 映射步驟：

????????第1步 復查基本系統模型。

????????第2步 復查并精化數據流圖。

????????第3步 確定數據流圖具有變換特性還是事務特性。

????????第4步 確定輸入流和輸出流的邊界，從而孤立出變換中心。

????????第5步 完成“第一級分解”

????????第6步 完成“第二級分解”（為每一個模塊寫一個簡要說明）

????????第7步 使用設計度量和啟發式規則對第一次分割得到的軟件結構進一步精化。

????????變換流：第一級分解；第二級分解

事務流：

七、軟件體系結構風格

下列對軟件體系結構的描述錯誤的是（ D ）。

A、軟件體系結構是對子系統、系統構件以及它們之間相互關系的描述。

B、子系統和構件一般定義在不同的視圖內，以顯示軟件系統的相關功能屬性和非功能屬性。

C、軟件體系結構是軟件系統的一組關鍵設計決策。

D、軟件體系結構是軟件需求活動的一種工作產品。

（1）管道和過濾器

每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然后產生輸出數據流。

連接件就象是數據流傳輸的管道（Pipes），將一個過濾器的輸出傳到另一過濾器的輸入 。

在輸入被完全消費之前，輸出便產生了

過濾器不知道它上游和下游的標識

1. 優點：

   1. 具有良好的隱蔽性和高內聚、低耦合的特點

   2. 允許將整個系統的輸入/輸出行為看作是多個過濾器的行為的簡單合成

   3. 支持軟件重用

   4. 易于維護和增強系統

   5. 允許對吞吐量、死鎖等性質進行分析

   6. 支持并行執行，每個過濾器可作為一個單獨的任務完成

2. 缺點：

   1. 導致進程成為批處理的結構

   2. 不適合處理交互的應用

   3. 可能會出現重復執行預備函數，導致系統性能下降，增加了編寫過濾器的復雜性

3. 應用：編譯器、Unix shell

（2）數據抽象與面向對象風格

構件是對象，通過方法和過程調用來交互。

缺點：一個對象和另外一個對象調用進行交互，必須知道對象的標識。

（3）基于事件/隱式調用風格

構件通過發布或廣播一個或多個事件來隱式激發另外一些模塊中的過程。

?? 基于事件/隱式調用風格增加了構件之間進行數據交換的難度

??這些被激發的過程是對這些事件注冊了過程的。

??比如理解為數據庫中的觸發器，某些數據庫對這個表設置了觸發器（注冊過程），當用戶在表中插入一些數據時（構件），隱式激發了數據庫的觸發器。

??優點：

1. 為軟件重用提供了強大的支持，加入一個構件時只需要將它注冊到系統的事件中

2. 為改進系統帶來了方便，用一個構件代替另一個構件時，不會影響到其他構件的接口

??缺點：

1. 構件放棄了對系統計算的控制

2. 聲明或廣播某個事件的過程的語義依賴于被觸發事件的上下文約束，關于正確性的推理存在問題

（4）層次系統風格

每一層為上層服務，并作為下層的客戶（上層調用下層），內部的層只對于相鄰的外層可見（除了輸出函數）

構件：各個層次內部包含的構件

連接件：層次間的協議

如操作系統的那個層次圖。

優點：

1. 支持基于抽象程度遞增的系統設計

2. 支持功能增強，只影響相鄰的上下層

3. 支持重用，服務接口

4. 對標準化的支持，促進實現標準化的任務和接口開發

??缺點：

1. 劃分為分層的模式并不容易

2. 效率降低

3. 如何界定層次間的劃分非常復雜

（5）倉庫風格

兩種構件：中央數據結構 一組獨立構件

兩種風格：傳統的數據庫體系結構（輸入事務觸發選擇）

?? 黑板系統（中央數據結構當前狀態觸發選擇）

（6）客戶/服務器風格

傳統是兩層C/S結構

??瘦客戶機模型：操作都在服務器，客戶只負責標識

---

第六章 詳細設計

一、詳細設計概要

（1）接口設計

1. 軟件構件之間的接口

2. 模塊和消息生產者/消費者的接口

3. 人和計算機的接口，人機界面

（2）過程設計

1. 結構化程序設計技術是詳細設計的邏輯基礎

2. 三種控制結構：順序、選擇、循環，取消GOTO語句

3. 只有一個入口和一個出口

二、過程設計技術和工具

1. ??????一個程序流程圖對應的盒圖表示不是唯一的 PAD圖可以縱橫延伸，圖形的空間效果好

1. 程序流程圖不支持逐步求精

1. 程序流程圖

   

   1. 不是逐步求精的好工具，過早地考慮了細節而非全局結構

   2. 用箭頭代表控制流，因此程序員可以不受約束控制，隨意轉移控制

   3. 不易表示數據結構

2. 盒圖/N-S圖

   

   1. 功能域明確（某個特定控制結構的作用域）

   2. 不可能隨意轉移控制

   3. 很容易確定局部和全程數據的作用域

   4. 方便表示嵌套關系和模塊的層次結構

3. PAD圖

   

   1. 使用結構化的PAD符號設計出的程序必然是結構化程序

   2. 描繪的程序結構清晰、容易記憶

   3. 方便轉化為高級語言源程序，可用轉換工具自動完成

   4. 既可以表示程序邏輯，又能用于描繪數據結構

   5. 支持自頂向下、逐步求精

4. 判定表

   1. 靜態邏輯，不能表達加工的順序，不能表達循環結構

   2. 要求將程序流程圖的多分支判斷都改成兩分支判斷

5. 判定樹 判定樹就是將判定表根據判定表中的所有條件做成分支。從根節點開始一路判斷，最后的葉子節點就是要執行的動作。

6. 過程設計語言PDL

   1. 也被稱為偽代碼，具有嚴格的關鍵字外部語法，用于定義控制結構和數據結構。同時又有著靈活的內部語法（表示實際操作和條件），可以適應各種工程需要

   2. 可以直接作為注釋插入程序片段中，可以使用普通的文字編輯系統編輯，有軟件可以自動由PDL生成程序代碼

   3. 不如圖形界面清晰，且在復雜的條件組合和動作對應關系上不如判定表清晰

三、人機界面設計

1. 人機界面可以看作是基于計算機的系統或產品的最重要的元素

2. 黃金規則

   1. 賦予用戶控制權

   2. 減少用戶的記憶負擔

   3. 保持界面一致

3. 設計過程

????????（1）用戶、任務和環境分析及建模

????????（2）界面設計活動

??????????????????系統響應時間，用戶完成某個控制動作，到軟件給出預期響應之間的時間

? ? ? ????????? ? 用戶幫助設施（集成/附加，部分功能/全部功能，方式，顯示，返回，結構）

? ? ? ????????? ?出錯信息處理（可以理解，從錯誤恢復，負面后果，聽覺/視覺，不帶指責） ????????

? ? ? ????????? ?命令交互（命令行/窗口）

??????????（3）界面構造

??????????（4）界面確認

? ? ? ?4.? 設計指南：

? ? ? ? ? ? ? 1.? 一般交互指南

? ? ? ? ? ? ? 2. 信息顯示指南

? ? ? ? ? ? ??3. 數據輸入指南

四、程序復雜程度的定量度量

1. 用途

程序的復雜程度乘以適當的參數可以估算軟件中地錯誤數量以及軟件開發需要的工作量

結果可以比較兩個算法的優劣

可以作為模塊規模的精確限度

2. McCabe方法

流圖/程序圖：僅僅描述程序的控制流程，完全不表現對數據的具體操作及分支和循環的具體條件 注意:流圖的選擇語句都是單一的，遇到多重選擇問題要將多個選擇條件轉換為多個節點

• 節點（N）：用圓表示，代表一條或多條語句

• 邊（E）：用箭頭表示，一邊必須終止于一個節點

• 區域（V）：由邊和結點圍成的面積.特別的,開區域也算作一個區域

環形復雜度

• V(G)=V，環形復雜度等于區域數量

• V(G)=E-N+2

• V(G)=P+1，P是流圖中判斷的數目

  • 在標準的流圖中，一個判斷節點代表一個判斷

  • 在某些非標準流圖中，可能一個節點可以引出n條路徑，這代表著存在n-1個判斷

用途

1. 程序的環形復雜度取決于程序控制流的復雜程度，也是取決于程序結構的復雜程度

2. 對軟件的可靠性給出某種預測

3. 環境復雜度是可加的

---

第七章 編碼和測試

一、編碼

好的程序的代碼邏輯簡明清晰、易讀易懂

1. 程序的內部文檔

2. 數據說明

3. 語句構造

4. 輸入/輸出方法

5. 效率問題

二、測試

1. 測試是程序的執行過程，目的在于發現錯誤

????????一個好的測試用例在于能發現至今未發現的錯誤

????????一個成功的測試用例在于發現了至今未發現的錯誤

????2. 測試方法的種類

（1）黑盒測試

????????把測試對象看作一個黑盒，測試人完全不考慮程序內部邏輯和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合他的功能說明。——功能測試/數據驅動測試

????????黑盒測試不可能用所有的輸入輸出條件來確定測試數據

????????黑盒測試基于程序接口

（2）白盒測試

????????把測試對象看作一個透明的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有的邏輯路徑進行測試。——結構測試、玻璃盒測試或邏輯驅動測試

3. 軟件測試步驟

• 模塊測驗（單元測驗）--編碼和詳細設計

• 子系統測驗（集成測驗）--概要設計和詳細設計

• 系統測驗（集成測驗）--軟件設計（概要設計）和需求說明

• 驗收測試（確認測試）--系統需求說明書

• 平行運行：同時運行開發出的新版本和被他取代的舊版本，比較兩個系統的處理結果

三、單元測試

1. 測試重點

   1. 模塊接口

   2. 局部數據結構

   3. 重要的執行通路

   4. 出錯處理通路

   5. 邊界條件

2. 代碼審查：可以審查出30%-70%的設計錯誤和編碼錯誤

????????預排：一人扮演“測試者”，其他人扮演計算機

? ?3. 驅動程序：接收測試數據，把這些數據傳送給被測試的模塊，印出有關結果

???????存根程序：代替被測試模塊所調用的子模塊，“虛擬子程序”/“樁模塊”：做最少量的數據操作，把控制歸還給調用它的模塊

四、集成測試

• 非漸增式測試：先分別測試每個模塊，再一次性把所有模塊設計要求放在一起結合成所要的程序

• 漸增式測試：把下一個要測試的模塊同已測試好的那些模塊結合起來進行測試，以此類推，每次增加一個模塊。這種方法實質上是同時完成單元測試和集成測試

具體分類:

• 一次性集成：當所有的組件都單獨測試完畢之后，將他們一次性混合起來組成最終的系統，查看其是否能運行成功。（類似于非漸增式測試）

  ??缺點：

  • 需要大量編寫驅動程序和存根程序

  • 所有組件一次進行合并，很難找出所有錯誤的原因

  • 不容易區分接口錯誤與其他類型的錯誤

• 自頂向下集成：從主模塊開始，沿著程序的控制層向下移動，逐漸把各個模塊結合起來。在把【附屬于主模塊的那些模塊】裝載到程序結構中時，使用DFS或BFS策略。

  ??優點：

  • 能夠早期對主要的控制或關鍵的抉擇進行檢驗

  • 不需要驅動程序

  • 選擇DFS時，可以在早期實驗一個完整的功能并驗證此功能

??????????缺點：

????????????????需要編寫存根程序

????????????????為了充分測試高層，可能需要低層的處理

????????????????可能需要很多存根程序

• 自底向上集成：從原子模塊開始組裝和測試，不需要存根程序。

  ??優點：

  • 適用場景：當底層有許多組件是有多種用途的公共例程而經常被其他組件調用時、當設計是面向對象的或者當系統由大量孤立的復用的組件組成時，自底向上集成很有用。

  • 不需要寫存根程序

  • 測試驅動程序數目較少

  • 底層往往承擔著主要的計算和輸出，更容易出錯，該方法能早發現這類錯誤

  • 底層模塊可以并行測試

?????????缺點：

??????????????????對頂層測試較晚，會推遲主要錯誤的發現

? ? ? ? ? ? ? ? ? 程序最后一個模塊加入時，才有具體整體形象

• 三明治集成：將自頂向下和自底向上結合起來，選取某一層作為基準層。選取不同的基準層，整個集成測試會有很大不同。

  ??優點：

  • 允許在測試的早期進行集成測試

  • 結合了自頂向下和自底向上測試的優點，在測試的最開始就對控制和公用程序進行測試

????????缺點：

????????????????在集成之前沒有徹底地測試單獨的組件

五、回歸測試

1. 回歸測試誰指重新執行已經做過的測試的某個子集，以保證由于調試或其他原因引起的變化，不會導致非預期的軟件行為或額外錯誤

2. 回歸測試集：

   1. 代表性測試用例

   2. 可能受修改影響

   3. 被修改過

六、確認測試

????????確認測試有時也叫驗收測試，目標是驗證軟件的有效性 軟件有效性：像預期那樣運行 確認測試以用戶為主來進行 確認:為了保證軟件確實滿足了用戶需求而進行的一系列活動——you built a right thing 驗證:為了保證軟件正確地實現了某個特定的要求地一系列活動——you built it right

????????Alpha測試:用戶在開發者的場景下，在開發者的指導下進行測試

????????Beta測試:開發者不在現場，用戶在一個或多個客戶現場進行測試

七、白盒測試

1. 邏輯覆蓋

   1. 語句覆蓋（每條可執行語句都被執行）

   2. 判定覆蓋（每個判定節點真假都覆蓋）

   3. 條件覆蓋（每個判定中每個條件真假都覆蓋，滿足條件覆蓋不一定滿足判定覆蓋）

   4. 判定/條件覆蓋（判定+條件）

   5. 條件組合覆蓋（每個判定所有條件可能組合出現一次）

   6. 點覆蓋（=語句）

   7. 邊覆蓋（=判定）

   8. 路徑覆蓋（每條可能路徑都經過一次，流圖中每個環至少經過一次）

2. 控制結構測試（基本路徑測試，條件測試和循環測試不作要求）

步驟：

1. 根據過程設計畫出流圖

2. 計算流圖環形復雜度

3. 確定線性獨立路徑的基本集合

   1. 獨立路徑指至少引入程序的一個新處理語句集合或一個新條件的路徑，用流圖術語描述，包含至少一條定義該路徑之前不曾用過的邊

   2. 環形復雜度 >= 獨立路徑數量

4. 設計可強制執行每一條獨立路徑的測試用例 注：某些獨立測試并不能依靠程序正常執行，需要使用驅動程序或放在更大的程序中執行

八、黑盒測試

1. 黑盒測試和白盒測試不能互相代替，兩者互為補充

2. 等價劃分：將所有可能的輸入數據劃分為若干類，每一類導出一個測試用例，一個理想的測試用例可以發現一類錯誤。 確定測試用例：

   1. 設計一個新的測試用例，使得盡可能多的覆蓋并未被覆蓋的有效等價類，重復直到每個有效等價類被覆蓋。

   2. 設計一個新的測試用例，使得僅覆蓋一個尚未被覆蓋的無效等價類，重復直到所有的無效等價類被覆蓋。

3. 邊界值分析：大量的錯誤發生在邊界上而不是輸入范圍的內部。(最大值，最小值，最大值加1，最小值減1)

4. 錯誤推測法：依靠經驗和直覺推測程序中可能會存在的各種錯誤，從而有針對性地編寫檢查錯誤的例子。

5. 綜合策略：

   1. 任何時候都必須使用邊界值分析方法

   2. 必要時使用等價劃分增加測試用例

   3. 用錯誤推斷法增加用例

黑盒與白盒對比：

1. 白盒只考慮測試軟件產品；黑盒只考慮需求規約

2. 黑盒會發現遺漏的缺陷：規格的哪些部分沒有被完成；白盒會發現提交的缺陷：提出哪些實現是錯誤的

3. 白盒的成本遠高于黑盒，因為測試前先有源碼

4. 一個白盒的失敗會導致所有的黑盒測試被重復執行并且重新決定白盒測試路徑

九、軟件可靠性

1. 軟件可靠性（R）：在程序給定的時間間隔內，按照規格說明書成功運行的概率

????軟件可用性（A）：在程序給定的時間點，按照規格說明書成功運行的概率

2. R(250)=0.95：100個相同系統中，有95個無故障的運行了250小時，5個在此期間發生了故障。

? ? A(250)=0.95：在運行的第250個小時，有95正在正常運行，有5個處于故障待處理狀態。

3. MTTF

十、調試

調試是在成功測試之后才開始的工作。任務是進一步診斷和改進程序中潛在的錯誤

調試方法：

1. 蠻干法

   1. 通過內存全部打印來調試

   2. 在程序內部特定位置設置打印語句

   3. 自動調試工具

2. 回溯法：一旦發生錯誤，先確定最先發生“癥狀“的位置，然后人工沿控制流程回追錯誤產生位置

3. 原因排除法

   1. 對分查找法：在幾個關鍵節點注入變量的正確值，觀察結果正確性，正確則問題發生在節點前，反之則發生在節點后。

   2. 歸納法

   3. 演繹法

---

第八章 軟件維護

一、重要概念

1. 軟件維護的定義：交付使用之后，為了修改錯誤或增加新需求而修改軟件的過程

2. 維護在軟件生存期中占70%以上

3. 軟件維護的種類：

   1. 適應性維護（25%）

   2. 改正性維護（20%）

   3. 完善性維護（50%）

   4. 預防性維護（5%）：為了提高軟件的可靠性、可維護性等，為以后進一步改進軟件打下良好基礎而對軟件進行的修改

4. 軟件維護的特點

   1. 結構化維護和非結構化維護差別巨大

      1. 結構化維護：有完整的軟件配置，維護整體質量高

      2. 非結構化維護：缺少相關文檔，維護代價巨大

   2. 維護的代價高昂（有形/無形，生產率）

   3. 維護的問題很多

二、軟件的可維護性

1. 軟件的可維護性=可理解性+可測試性+可修改性+可重用性+可移植性

2. 文檔的要求

• 描述如何使用該系統

• 必須描述如何安裝和管理該系統

• 必須描述系統需求和設計

• 必須描述系統實現和測試

? 3. 用戶文檔和系統文檔，各類文檔必須如實反映軟件的當前狀態

三、可維護性復審

1. 需求分析復審：

   1. 標注可能的改進和修改

   2. 軟件可移植性

   3. 系統界面

2. 設計復審：

   1. 評價軟件的結構和過程

   2. 對可能修改的部分預作設計

3. 代碼復審：

   1. 編碼風格

   2. 內部說明文檔

4. 設計和編碼：

   1. 使用可重用的軟件構件

5. 配置復審：

   1. 審查軟件配置成分

6. 在完成每項維護工作后都應該對軟件維護本身進行復審

四、軟件再工程（預防維護）

• 庫存目錄分析

????????應當仔細分析庫存目錄,按照業務重要程度,壽命,當前可維護性,預期修改次數等指標,把庫中應用系統排序,從中找到再工程候選者,然后明智分配再工程資源

????????以下程序可能成為預防性維護對象

1. 預定使用多年的程序

2. 當前正在成功使用的程序

3. 最近的將來可能要做重大修改或增強的程序

• 文檔重構

  • 穩定不變的程序：保持現狀

  • 需要更新文檔但資源有限：使用時建文檔

  • 關鍵應用+需要重構全部文檔：文檔工作減小到必需的最小值

• 逆向工程

????????分析程序以便在【比源代碼更高的抽象層上】創建【程序的某種表示】的過程

????????從現有程序代碼中抽取有關數據、體系結構和處理過程的設計信息，恢復設計結果的過程

• 代碼重構

????????重構難以理解、測試和維護的個體模塊的代碼

• 數據重構

????????對數據體系結構做適應性增強

????????當數據結構較差時,應該對數據進行再工程

????????發生在較低層次，是一種全范圍的再工程活動

• 正向工程

????????改變或重構現有系統，提高整體質量，重新開發

五、練習

---

第九章 項目管理

一、概述

1. 是否需要管理，是區別專業開發和業余編程的重要區別之一

2. 項目（project）：為了創造獨特的產品，實現獨特的服務，達成獨特的結果的暫時性努力。

   ?? 特點：

   1. 獨特的

   2. 暫時性的，存在明確的起止日期

   3. 實現目標之后就完成了

   4. 無法實現的話，也算是結束了/取消了

   5. 一個成功的項目需要滿足甚至超過項目干系人的預期

3. 運營（Operation）：連續的，沒有起止日期，往往是重復同一工作程序

4. 項目約束：時間、金錢、質量

二、軟件成本與工作量

1. 軟件成本需要定期修正。對于多數項目，工作量是軟件成本最大的一塊，并且也是最不確定的一塊

2. 工作量的估算首先從軟件規模估算開始

• 代碼行技術：依據以往的產品，估計一個功能要多少行

  • 依賴開發語言

  • 跨組織由于標準不同，因此不能類比

  • 源程序僅是軟件配置的一個成分，用其來估計整個項目不合理

  • 語言效率高，則估算的生產率偏低.原因:代碼效率越高,寫出來的代碼行數就越少,由此得到的經驗指導下生產率就會很低

• 功能點（FP）技術：依據功能數量，通過對軟件信息域特性和軟件復雜性評估軟件規模

  

  ??上圖中每部分取值為0-5，0表示該部分對系統無影響，5表示該部分對系統很重要，TFC=0.65+0.01(SUM(Fi))，TFC取值在0.65到1.35之間

  • 使用輸入數、輸出數、查詢數（聯機輸入）、主文件數和外部接口數加權求和可以計算出未經調整的功能點計數（UFP）

  • FP=UFP×TFC

1. 對于相同的代碼行數或功能點數，使用不同模型估算將得到不同的結果。主要原因是模型多數都是僅根據若干應用領域中有限個項目的經驗數據推導出來的，適用范圍有限。

2. 軟件開發工作量是軟件規模（KLOC或FP）的函數，其單位通常是人月（PM）。

5. 項目進度計劃的實現方式

1. 工作分解結構

   ????缺點：

   1. WBS

   2. 任務責任矩陣

   3. 最高層是項目本身，接下來是項目的可交付成果以及進一步分解的、更小的可交付成果

   4. 沒有指明活動間的相互依賴關聯

   5. 無法表示可以并行的成分

2. Gantt圖：它具有直觀簡明和容易掌握、容易繪制的優點

3. 工程網絡

三、進度計劃-甘特圖

Gantt圖：

例子：假設有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步完成： 首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。假設一共分配了15名工人去完成這項工作，然而工具卻很有限： 只有5把刮舊漆用的刮板，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。 甘特圖畫法：

優點：

形象的描繪任務的分解情況和子任務開始結束時間

缺點：

1. 不能顯示描述各項作業之間的依賴關系

2. 進度計劃的關鍵部分不明確

3. 有潛力的部分和潛力的大小不明確，可能會造成潛力的浪費

四、進度計劃-工程網絡圖

1. 特點和要求：

   1. 描述任務的分解情況

   2. 注明作業的開始/結束時間

   3. 顯示的描述作業之間的依賴關系

   4. 要求繪制者理解項目中哪些地方可以并行

2. 活動（Activity）：項目的一部分，要耗費一段時間，有開始和結束，用箭頭表示

????????里程碑（Milestone）：是某個活動完成的標志，是一個特定的時間點，用圓圈表示

3. 活動的參數：

1. 前置條件（Precursor）：活動開始前必須發生的事件

2. 持續時間（Duration）：完成活動所需的時間

3. 最終期限（Due Date）：日期，活動必須在此之前完成

4. 結束點（Endpoint）：通常是活動對應的里程碑/可交付的成果

4. 事件的最早時刻（EET）：該事件能夠發生的最早時間（正向選最大）

?????事件的最遲時刻（LET）：不影響竣工的前提下，最晚可以發生的時間（逆向選最小）

可見，工程網絡類似于數據結構中的活動圖

機動時間 = (LET)結束 - (EET)開始 - 持續時間

變式：

1. 機動時間=可用時間-持續時間

2. 機動時間=作業最晚開始時間-最早開始時間

3. 機動時間=作業最晚結束時間-最早結束時間

關鍵路徑：

????????充分條件：持續時間最長，各活動機動時間為0

????????必要條件：事件的最早和最遲時刻相同

關鍵路徑的空閑時間總和最小（現實中不一定為0）

關鍵路徑的壓縮，用邊表示

五、人員組織

1. 項目干系人：有既得利益者

   關鍵項目干系人：能夠促成和破壞項目的成功

????????客戶：負責說明開發軟件的需求和其他風險的承擔

????????用戶：最終使用軟件的人

2. 民主制程序員組：

1. 小組成員平等；

2. 兩兩之間存在通信信道；

3. 規模小（2-8人）；

4. 組織方式非正式

3. 主程序員組：

1. 最好的程序員是主程序員，提供所有支持。通信由一兩個人進行。

2. 專業化和層次化

3. 主程序員，和主程序員一樣高水平的后備程序員，負責事務性工作的編程秘書，辛勤工作的程序員

4. 變化形式：現代程序員組

各種制度的適用情況：

集中式：簡單、重復的問題；模塊化程度高的問題；大項目；周期固定、較短的項目；

分散式：復雜、創新的問題；模塊化程度低的問題；小項目；周期長的項目；

六、軟件配置管理（SCM）

1. 軟件配置管理是軟件系統發展過程中管理和控制變化的規范。

2. 目的：針對變化，控制變化

3. 軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。

4. 軟件配置管理不同于軟件維護，貫徹于整個軟件生命周期

   1. 軟件配置項（SCI）：為了配置管理而作為單獨實體處理的一個工作產品或一段軟件。即軟件過程輸出的全部計算機程序、文檔、數據

   2. 配置管理聚集：SCI的一個集合，簡稱CM聚集

   3. 版本：在一確定的時間點上，某個SCI或某個配置的狀態

   4. 基線：通過了正式復審的軟件配置項

   5. 項目數據庫：一旦一個SCI成為基線，就被放到項目數據庫中

5. 為什么需要軟件配置管理：

   1. 軟件開發項目的產品數量急劇增加且易被修改和變化

   2. 軟件開發蘊含變化

   3. 產品各部件的版本問題

   4. 工作人員之間既獨立又聯系的關系使得通常的管理手段力不從心

6. 軟件配置管理的5項任務：

   1. 標識

   2. 版本控制

   3. 變化控制（非正式/項目級）

   4. 配置審計（技術復審/軟件配置審計）

   5. 配置狀態報告

7. 配置管理是諸多管理活動中最易操作、最容易實現并且能在項目最先體現出效果的管理手段

8. 軟件質量保證

軟件質量：軟件與（明確地/隱含地定義的）需求相一致的程度

軟件質量的保證措施：

1. 基于非執行的測試（復審或評審）

2. 基于執行的測試（軟件測試）

3. 程序正確性說明

9. 能力成熟度模型（CMM）

目的:通過定義能力成熟度的五個等級,引導軟件開發機構不斷識別出其軟件過程的缺陷,并指出應該做那些改正

能力成熟度模型（CMM）

等級1：初始級
等級2：可重復級
等級3：已定義級
等級4：已管理級
等級5：優化級

七、風險管理

• 風險：能造成惡果的有害事件，未發生。

• 風險轉化時刻：風險變成問題的時候。

• 風險=機遇

• 風險管理的策略：

  • 被動策略：針對可能發生的風險監督項目，直到他們變成真正的問題時，才撥出資源來處理他們。

  • 主動策略：標識潛在風險，評估出現概率和產生的影響，按重要性加以排序，建立計劃管理風險。設立應急計劃，對未知風險能采取可控有效方式回應

---

第十章 面向對象

一、面向對象方法學概述

1. 對象的定義（選擇）：

   1. 對象是具有相同狀態的一組操作的集合

   2. 對象是對屬性值和操作的封裝

   3. 對象:=（ID，MS，DS，MI），標識/操作集合/數據結構/受理的消息名集合（對外接口）

2. 面向方法學的優點：

   ?? 面向對象方法以對象為中心，比較穩定；

   1. 穩定性好：傳統軟件開發方法以算法為核心，依賴功能；

   2. 可重用性好：自含性，靈活性

   3. 輕易開發大型軟件產品

   4. 可維護性好（五個方面：可理解、可修改、可移植、可重用、可測試）

二、UML基礎

1. UML圖：

   1. 用例圖：展示用例（Use Case）、參與者（Actor）及其關系

   2. 類圖：展示類、接口、包及其關系

   3. 對象圖：某個時間點上系統中各對象的快照

   4. 組件圖：展示系統各構件及其關系

   5. 部署圖：展示交付系統中軟硬件間物理關系

   6. 順序圖：按時序展示對象間消息傳遞

   7. 協作圖：強調收發消息的對象間的組織結構

   8. 狀態圖：展示對象在其生命周期中的可能狀態以及在這些狀態上對事件的響應

   9. 活動圖：展示系統從一個活動轉到另一活動的可能路徑和判斷條件

2. Use Case用例圖

   1. 簡介

   2. 用例是非形式化的，可以結構化

   3. 用例間的關系：泛化、包含、擴展

   4. 如何繪制用例圖：【6 分鐘學會 UML 用例圖-嗶哩嗶哩】 https://b23.tv/lay1Wnt

3. 類圖

   1. 類之間的主要關系：泛化（實線空心三角箭頭）、依賴（虛線箭頭）、關聯（橫線+文字）、聚合（空心菱形+文字）、組合（實心菱形+文字）、細化（虛線空心三角箭頭）

   2. 如何繪制類圖：【6 分鐘學會 UML 類圖-嗶哩嗶哩】 https://b23.tv/2QAqZa8

4. 如何理解順序圖：【5 分鐘學會 UML 時序圖（順序圖、序列圖）-嗶哩嗶哩】 https://b23.tv/rf5Rv0E

5. 如何理解活動圖：【3 分鐘學會 UML 活動圖-嗶哩嗶哩】 https://b23.tv/yfAKm80

6. UML拓展：標記值、構造型、約束

三、面向對象的需求提取

1. 用例的定義：本質上，一個用例是用戶與計算機之間為達到某個目的而進行的一次典型交互作用，作為結果，用例代表的就是系統的一個完整功能

2. 場景（Scenario）：場景是用例的真實例子。場景通過舉例說明情況，幫助理解問題域，進而歸納用例。具體執行一次用例，得到一個場景。場景重在可理解性，用例重在完整性

注意：場景是用例的實例，因此其名字帶有下劃線（對象）

?3. 用例的編寫：

1. 開發組織必須事先確定用例規約說明的編寫標準

2. 可以用結構化自然語言編寫用例：三種基本控制結構

3. 主要參與者（也稱主動參與者）觸發用例，次要參與者不觸發用例

4. 前置條件約束了用例開始之前的系統狀態，后置條件約束了用例執行之后的系統狀態

5. 主事件流描述用例中產生“美滿結局”的步驟，備選流描述用例中各種可能“節外生枝、橫生變故、遭遇不測、異常例外”而導致“糟糕結局”的步驟

4. 編寫用例的步驟

1. 總結基本流程（基本流圖）

2. 編寫基本流

3. 繪制事件流示意圖

4. 編寫備選流

5. 找出用例中的參與對象

5. 分析類的劃分：實體類、邊界類、控制類

在UML用例圖中，參與者之間可以有泛化關系，表示子參與者的實例可以與其父參與者對應的用例實例進行交互。

6. 用UML描述系統的5個視圖

1. 用例視圖：系統行為、動力

2. 邏輯視圖：問題及解決方案的術語詞匯、支持功能需求的邏輯結構

3. 組件視圖：組件、子系統、文件、第三方類庫、框架、系統軟件

4. 進程視圖：資源的有效利用、并行、線程通信與同步、異步事件處理、容錯、可伸縮性、吞吐量

5. 部署視圖：軟硬件映射、性能、規模、可靠性、部件的發布、交付、安裝

四、分析類的定義與作用

• 概念：分析類是概念層模型，用于捕獲系統對象模型的雛形，聚焦問題域而非技術細節。

• 目的：通過實體、邊界、控制類劃分職責，隔離變化，實現高內聚、低耦合。

• 關鍵原則：保持粗略性，避免技術細節（如數據庫、界面實現）。

---

五、三類分析類及其職責

??類型??	??職責??	??來源示例??
??實體類??	存儲核心業務數據及操作（如持久化信息）。	領域名詞（如緊急情況報告、事件）
??邊界類??	處理系統與外部實體的交互（如輸入/輸出轉換）。	Actor與系統的交互點（如報告表單）
??控制類??	協調用例行為，封裝業務邏輯流程。	每個用例對應一個（如管理緊急情況控制對象）

關鍵區別：

• 實體類：跨用例復用（如用戶）。

• 控制類：用例專屬（如支付處理控制）。

• 邊界類：隔離外部變化（如硬件/協議適配）。

---

六、分析類的識別方法

1. 實體類識別：

• 來源：領域名詞、系統需跟蹤的實體（如銷售訂單）、數據源（如打印機）。

• 試探法：

  • 檢查用例中的名詞（如“事件”、“資源”）。

  • 避免過度細化：無獨立行為或無標識的客體→轉為屬性（如“訂單ID”作為屬性而非類）。

2. 邊界類識別：

• 規則：每個Actor至少關聯一個邊界類（如出納員→銷售終端界面）。

• 試探法：

  • 輸入點：表單、傳感器（如條形碼掃描儀接口）。

  • 輸出點：通知、消息（如確認彈窗）。

3. 控制類識別：

• 規則：每個用例一個控制類，復雜用例可拆分（如報告緊急情況→分現場控制和調度控制）。

• 生命周期：控制類隨用例啟動/終止而創建/銷毀（如支付流程控制在支付完成后釋放）。

---

七、動態模型到靜態模型的轉換

1. 轉述用例：

   1. 用順序圖描述對象交互（Actor→邊界類→控制類→實體類）。

   2. 消息映射職責：如創建報告消息→實體類的//create()職責。

2. 整理分析類：

   1. 參與類圖（VOPC）：匯總用例中所有參與類及其關聯（如調度員 -- 管理緊急情況控制對象）。

   2. 關聯關系：基于交互圖中的消息路徑確定（如控制類訪問實體類）。

3. 屬性與職責：

   1. 屬性：僅實體類需定義核心屬性（如緊急情況報告.location），避免細節。

   2. 職責：由消息推導（如邊界類//提交表單()、控制類//驗證數據()）。

---

八、關鍵注意事項

1. 迭代與驗證：

   1. 分析模型需多次循環（開發人員自查→客戶聯合評審），確保正確性、一致性。

   2. 用例完善：動態建模可能暴露需求缺失（如順序圖發現遺漏的確認對象）。

2. 抽象層次控制：

   1. 實體類：不包含業務邏輯（僅數據操作）。

   2. 邊界類：不涉及UI細節（僅定義交互契約）。

   3. 控制類：不包含技術邏輯（僅流程協調）。

3. 模型演進：

   1. 分析類在設計階段演變為設計類（職責→方法，關聯→引用）。

   2. 避免過早優化：如泛化關系在分析階段僅用于概念組織（非繼承復用）。