第一章 軟件工程學概述

1.1 軟件危機（Software Crisis）

概念

定義：軟件危機指在計算機軟件開發與維護過程中遇到的一系列嚴重問題，源于1960年代軟件復雜度激增與傳統開發方法失效的矛盾。

本質：軟件規模擴大 → 開發效率/質量下降 → 項目失控。

典型表現

表現	具體說明
成本與進度超支	項目實際成本/工期遠超預估（例：銀行系統開發預算翻倍）
質量低下	軟件錯誤頻發、性能不穩定（例：早期操作系統頻繁崩潰）
維護困難	修改代碼如同“拆炸彈”（例：Y2K千年蟲問題修復耗資數百億美元）
需求不明確/變化頻繁	用戶無法準確描述需求，開發中頻繁變更（例：政府管理系統多次返工）

根本原因

原因	說明
軟件復雜度激增	系統功能膨脹導致傳統“手工作坊式”開發無法應對（如：阿波羅登月軟件bug率極高）
缺乏工程化方法	無標準流程、文檔缺失、團隊協作混亂
溝通與管理不足	用戶-開發者-管理者信息斷層（經典案例：IBM OS/360系統延期超預算）

考點提示**：選擇題常考軟件危機的表現與原因，簡答題需答出至少3個表現。

1.2 軟件工程（Software Engineering）

定義

• 核心思想：應用工程化原則（系統性、規范性、可量化）解決軟件問題。
• 目標：提高質量、降低成本、控制風險。

本質特性

特性	說明
系統性	全生命周期管理（需求→設計→編碼→測試→維護）
規范性	標準化文檔（如需求規格說明書、設計文檔）
工程化	項目管理（進度控制、風險評估）、質量保證（測試、評審）
創新與適應	持續改進方法（如敏捷開發適應需求變化）

如何解決軟件危機

措施	實例
標準化開發流程	瀑布模型（階段劃分）、敏捷開發（迭代交付）
模塊化設計	將系統拆分為獨立模塊（如MVC架構分離數據/視圖/控制）
強化質量管理	單元測試、代碼審查（如GitHub Pull Request審核機制）

📌 考點提示：簡答題常考“軟件工程如何消除軟件危機”，需結合特性與措施作答。

1.3 軟件生命周期模型

核心模型對比

模型	關鍵思想	優點	缺點	適用場景
瀑布模型	線性階段推進	管理簡單、文檔完整	需求變更困難、風險滯后	需求明確的小型項目
快速原型模型	快速構建原型驗證需求	降低需求風險	原型代碼質量低、易忽略架構	用戶需求模糊的項目
增量模型	分批次交付功能	早期交付、風險分散	模塊集成復雜度高	大型可拆分系統
螺旋模型	風險分析驅動迭代	強風險控制、支持大型項目	管理成本高、流程復雜	高風險復雜系統（如航天）

模型選擇場景

• 學生管理系統 → 瀑布模型（需求穩定）
• 電商平臺 → 增量模型（模塊清晰：用戶/訂單/支付）
• AI醫療診斷系統 → 螺旋模型（技術風險高）

考點提示：綜合題常要求比較模型優缺點，需熟記表格內容。

1.4 軟件工程方法學

結構化方法 vs 面向對象方法

維度	結構化方法（Structured）	面向對象方法（OO）
核心思想	自頂向下分解功能	對象模擬現實世界
關鍵機制	模塊化、順序/分支/循環	類/繼承/封裝/多態
優點	流程清晰、易調試	復用性高、適應需求變化
缺點	靈活性差、難以應對復雜交互	學習曲線陡峭
典型代表	SA/SD方法（結構化分析/設計）	UML建模、設計模式

結構化方法要點

1. 自頂向下設計：先整體后細節（例：先設計“學生管理系統”總體架構，再細化模塊）。
2. 三大控制結構：
   • 順序：語句線性執行
   • 分支：if-else/switch
   • 循環：for/while
3. 禁用goto：避免面條式代碼（Spaghetti Code）。

考點提示：簡答題常考“結構化程序設計要點”，需答出三大控制結構。

典型考題解析

下列哪項不是軟件危機的典型表現？
A. 成本超支
B. 質量可靠
C. 維護困難
D. 需求不明確
??答案??：B（軟件危機表現為質量低下，而非可靠）

問題：簡述瀑布模型的優缺點及適用場景。
??參考答案??：

• 優點：階段劃分清晰、文檔完備、管理簡單。
• 缺點：需求變更困難、風險滯后發現。
• 適用：需求明確、技術成熟的小型項目（如圖書館管理系統）。

---

本章知識圖譜

graph LR
A[軟件危機] --> B[原因：復雜度/方法不足/溝通問題]
A --> C[表現：成本/質量/維護/需求]
B --> D[軟件工程：工程化解決方案]
D --> E[生命周期模型：瀑布/原型/增量/螺旋]
D --> F[方法學：結構化 vs 面向對象]

復習建議：

1. 理解軟件危機與軟件工程的因果關系（為什么需要軟件工程）。
2. 對比記憶生命周期模型，結合實例區分應用場景。
3. 結構化方法重點掌握“三大控制結構”和“模塊化”。

第二章 可行性研究

可行性研究是軟件開發生命周期的第一步，解決“要不要做”的核心問題。本章內容系統性強，需重點掌握分析維度、建模工具和實戰方法。

2.1 可行性研究的目的與任務

為什么需要可行性研究？

• 避免資源浪費：在投入大量開發資源前驗證項目可行性（例：某市政府耗資千萬開發智慧城市系統，因技術不成熟最終廢棄）。
• 決策依據：為管理層提供是否啟動項目的客觀數據支持。

核心任務

任務	說明
技術可行性	現有技術能否實現？(如：AI醫療診斷需評估深度學習算法的成熟度)
經濟可行性	投入 vs 收益分析（計算ROI）(例：開發成本500萬，預計年收益200萬，回收期2.5年)
操作可行性	用戶能否接受？(如：老年人醫院系統需考慮觸屏操作便利性)
法律可行性	是否符合法規？(例：金融系統需滿足GDPR數據隱私要求)

考點提示：簡答題常考四個可行性維度的定義，需結合案例說明。

2.2 系統流程圖（System Flowchart）

核心作用

• 可視化物理流程：描述系統如何與外部實體（人/設備）交互（非邏輯細節）。
• 區分邊界：明確軟件系統與外部環境的接口。

關鍵符號與含義

符號	名稱	用途
	處理框	表示程序/人工處理過程（例：銀行柜員審核開戶申請）
	輸入/輸出	廣義輸入輸出（例：掃描身份證）
	文檔	紙質/電子文件（例：打印存款單）
	磁盤	數據庫/文件存儲（例：客戶信息數據庫）

經典案例解析

圖書館借書系統流程圖

關鍵點：箭頭表示物理流動方向（非數據流），如紙質借書單從打印機傳遞到書庫管理員。

2.3 數據流圖（DFD）與數據字典（DD）

數據流圖（Data Flow Diagram）

分層設計思想：

• 頂層圖（Context Diagram）：系統黑盒視圖（1個加工+外部實體+數據流）
• 0層圖（Level-0 DFD）：分解頂層加工（4-7個關鍵加工）
• 1層圖（Level-1 DFD）：細化0層加工

繪圖規則：

1. 加工名用動詞短語（例：“計算利息”而非“利息計算器”）
2. 數據流用名詞（例：“存款金額”）
3. 禁止控制流（如“審核通過”是控制信號，應轉為“審核結果”數據流）

實例：ATM取款系統DFD片段

數據字典（Data Dictionary）

作用：定義DFD中所有元素的詳細規格說明書。

核心條目格式：

1. 數據流：存款單 = 姓名 + 身份證號 + 存款類型 + 金額  
2. 數據項：金額 = 數字(10,2)   // 10位整數，2位小數  
3. 加工：計算利息 = 存款金額 × 利率 × 存期  
4. 文件：客戶信息 = {客戶ID + 姓名 + 手機號}  

考點提示：應用題常要求補充DFD缺失的數據流或修正錯誤符號。

---

2.4 可行性研究實戰案例

機票預訂系統可行性分析

1. 技術可行性：

   • 接口：需對接航空公司API（技術成熟）
   • 性能：支持1000并發查詢（需負載測試）

2. 經濟可行性：

   開發成本：人力50萬 + 硬件30萬 = 80萬  
   年收益：售票傭金200萬/年  
   ROI = (200-80)/80 = 150%  // 可行  
   

3. 操作可行性：

   • 用戶：旅行社員工有電腦操作基礎
   • 培訓：提供2天操作手冊培訓

4. 法律可行性：

   • 數據合規：乘客信息加密存儲（符合《網絡安全法》）

---

典型考題解析

應用題示例

繪制“患者監護系統”頂層DFD：
??參考答案??：

---

本章知識圖譜

graph TB  A[可行性研究] --> B[目標：避免資源浪費]  A --> C[四大維度：技術/經濟/操作/法律]  A --> D[工具：系統流程圖+DFD+數據字典]  D --> E[系統流程圖：物理交互]  D --> F[DFD：邏輯數據流]  D --> G[數據字典：元素定義]  

復習建議：

1. 對比記憶系統流程圖（物理）與DFD（邏輯）的符號差異
2. 掌握經濟可行性計算方法（ROI=年凈收益/總成本×100%）
3. 練習DFD分層繪圖：頂層圖必須只有1個加工

第三章 需求分析

3.1 需求分析的目的與任務

為什么需要需求分析？

• 彌補可行性研究的不足：可行性研究確定“做不做”，需求分析解決“做什么”，細化到可執行細節（例：ATM系統需明確“單筆取款上限5000元”）。
• 避免后續返工：需求不清晰導致50%的項目失敗（Standish Group數據），需求分析降低后期修改成本。

四大核心任務

任務	說明	實例（機票預訂系統）
確定綜合要求	功能、性能、安全等全局需求	支持1000并發用戶，響應時間<2秒
分析數據要求	定義數據結構與關系（ER圖）	乘客信息={身份證號+姓名+手機號}
導出邏輯模型	建立行為模型（狀態圖）、功能模型（DFD）	訂票狀態：搜索→選擇→支付→出票
修正開發計劃	根據需求復雜度調整資源與進度	增加3人周用于支付接口安全測試

3.2 軟件需求分類（8類）

考試必考的8類需求

需求類型	說明	案例（醫院掛號系統）
功能需求	系統必須提供的服務（動詞短語）	患者預約科室、醫生、時段
性能需求	響應時間、吞吐量等量化指標	掛號峰值5000次/分鐘，延遲≤1秒
可靠性需求	系統無故障運行概率	365天×24小時可用，故障率<0.1%
出錯處理需求	對異常輸入的響應方式	身份證號格式錯誤時提示“請輸入18位數字”
接口需求	軟/硬件交互規范	支持社保卡讀卡器型號XXX
約束	技術或業務限制	必須使用Java開發，數據庫用MySQL
逆向需求	系統禁止的行為	禁止修改已支付訂單的預約時間
未來需求	預留擴展可能性	預留對接醫保結算接口

易錯點：逆向需求≠錯誤處理，而是業務規則限制（如“禁止刪除已付款訂單”）。

3.3 三大模型的作用

需求分析的三種核心模型

模型	描述對象	工具	作用	實例（銀行轉賬系統）
數據模型	系統數據結構	ER圖	定義實體、屬性及關系（1:1, 1:N, M:N）	賬戶-(1:N)-交易記錄
功能模型	系統行為	數據流圖(DFD)	描述數據如何被處理	輸入金額→驗證余額→執行轉賬
行為模型	狀態變化	狀態轉換圖	描繪系統響應事件的狀態遷移	空閑→驗證→處理→完成

考點：選擇題常考模型與工具的對應關系（如：行為模型→狀態圖）。

3.4 ER圖（實體-聯系圖）

繪圖規則與符號

• 實體：矩形框 → CUSTOMER（客戶）、PRODUCT（產品）

• 屬性：橢圓 → customer_id（主鍵）、product_price

• 聯系：菱形 → places（下單）、contains（包含）

• 基數：

  • 1:1：醫生—值班安排
  • 1:N：部門-<職工（1個部門有N個職工）
  • M:N：學生>-<課程（學生選多門課，課程被多人選）

典型考題

題目：畫出“學生選課系統”的ER圖（1個學生選多門課，1門課被多個學生選，課程有課程號/名稱，學生有學號/姓名）。
??答案??：

3.5 狀態轉換圖

核心元素與案例

• 狀態：圓角矩形 → Idle（空閑）、Payment（支付中）
• 轉移：箭頭 → 點擊支付（事件）
• 起點/終點：[*]

應用題步驟

1. 識別狀態：系統可能處于的階段（如：訂單狀態=待支付/已支付/已取消）
2. 定義事件：觸發狀態轉移的動作（如：“用戶取消”事件使訂單→已取消）
3. 繪制遷移：用箭頭連接狀態，標注事件名

考點：根據文字描述畫狀態圖（例：電梯控制系統）。

3.6 需求分析工具

層次方框圖 vs IPO圖

工具	用途	特點	示例片段
層次方框圖	數據結構的層次分解	樹形結構，自頂向下細化	訂單→訂單頭+訂單明細
IPO圖	描述模塊的輸入/處理/輸出	表格形式，簡潔清晰	輸入：用戶ID → 處理：查詢訂單 → 輸出：訂單列表

IPO圖示例：

模塊名	輸入	處理邏輯	輸出
計算折扣	訂單金額, 會員等級	根據等級查折扣率 × 金額	折扣后金額

高頻考點總結

1. 選擇題：

   • 區分需求類型（如：可靠性需求→故障率）
   • 識別ER圖符號（菱形=聯系）

2. 簡答題：

   • 簡述需求分析的四大任務（綜合要求/數據要求/邏輯模型/修正計劃）
   • 列舉8類需求并舉例（功能/性能/接口…）

3. 應用題：

   • 根據場景畫ER圖（注意M:N關系的轉化）

• 繪制狀態轉換圖（標注事件和狀態）

復習建議：

• 重點掌握ER圖和狀態圖的繪圖規范（考試必考）
• 熟記需求分類的關鍵詞（功能=“做什么”，性能=“多快多穩”）
• 結合案例理解抽象概念（如：逆向需求=業務禁止規則）

第五章 總體設計

5.1 總體設計的兩大階段

1. 系統設計階段
   • 任務：確定技術方案（物理設計）
   • 輸出：硬件選型（如服務器配置）、軟件棧（如MySQL+Tomcat）、網絡拓撲圖
   • 考點：區分“做什么”（需求階段）和“用什么做”（系統設計）
2. 結構設計階段
   • 任務：定義軟件模塊結構
   • 輸出：模塊結構圖（HIPO圖/層次圖）
   • 考點：結構設計聚焦模塊劃分，非算法細節（屬于詳細設計）

5.2 總體設計9步驟

步驟	關鍵行動	考試要點說明
1. 設想方案	提出≥2種可行架構	需包含不同技術路線（如集中式vs分布式）
2. 篩選方案	評估技術/經濟/操作可行性	用決策矩陣加權評分法
3. 推薦方案	輸出《系統設計方案書》	包含架構圖+選型理由
4. 功能分解	模塊劃分（自頂向下）	用H圖展示層級
5. 設計結構	繪制模塊結構圖	箭頭表示調用關系（非數據流）
6. 數據庫設計	ER圖→關系模型	考綱關聯第3章ER圖
7. 測試計劃	制定集成測試策略	重點：自頂向下vs自底向上策略
8. 編寫文檔	《概要設計說明書》	含模塊清單+接口定義
9. 復審	正式技術評審（FTR）	易考點：不通過則返回步驟4

關鍵記憶點：步驟9是質量關卡，未通過需重新分解模塊（步驟4）

5.3 模塊化設計原理

1. 四大基本原則

原理	核心思想	應用案例
模塊化	分治法解決復雜問題	學生管理系統拆分為：登錄/選課/成績管理模塊
抽象	關注本質忽略細節	定義數據庫接口DB.executeQuery()，隱藏具體SQL
逐步求精	分層細化設計	1. 先設計用戶管理模塊 → 2. 細化為添加/刪除/查詢子模塊
信息隱藏	封裝模塊內部細節	支付模塊隱藏加密算法實現

2. 模塊獨立性指標（重點！）

耦合度衡量（從優到劣）：

• 數據耦合（最優）：通過參數傳遞基本數據類型

  // 示例：數據耦合
  calculateTax(income); // 僅傳遞數值
  

• 內容耦合（最差）：直接修改其他模塊內部數據

  // 示例：內容耦合（禁止！）
  moduleA.internalData = 0; // 外部修改內部數據
  

**內聚性分級**（從優到劣）：```mermaid
graph LRG[功能內聚] --> H[順序內聚]H --> I[通信內聚]I --> J[過程內聚]J --> K[時間內聚]K --> L[邏輯內聚]L --> M[巧合內聚]

• 功能內聚（最優）：模塊只做一件事

  class PaymentProcessor {void processPayment() { /* 僅處理支付 */ }
  }
  

巧合內聚

（最差）：模塊內元素無關聯

class Utils { void formatDate() {...} void encryptData() {...} // 無關功能硬湊
}

黃金法則：追求高內聚+低耦合

• 高內聚：模塊內元素緊密相關
• 低耦合：模塊間依賴簡單明確

---

5.4 結構圖設計

1. 從DFD到結構圖

轉換規則：

• 變換型DFD（輸入→處理→輸出）→ 三層結構

  案例：文件處理系統

  讀取文件 → 格式轉換 → 打印報告
  

• 事務型DFD（事件分發）→ 調度中心結構

  案例：ATM系統

  用戶請求 → 分發到存款/取款/查詢模塊
  

2. 結構圖繪制規范

• 符號說明：
  ? 矩形：模塊（寫模塊名）
  → 箭頭：調用方向（??箭頭指向被調用模塊??）
  ◇ 菱形：選擇調用
  ○ 環形：循環調用

• 典型錯誤：
  箭頭標注數據流（應寫調用關系）
  正確標注：

考點總結與答題模板

選擇題速記

• 模塊化目的：降低復雜性
• 最佳耦合類型：數據耦合
• 最差內聚類型：巧合內聚
• 結構圖箭頭含義：模塊調用關系
• 復審未通過：返回功能分解步驟

簡答題模板

題目：簡述模塊化設計的優點
??參考答案??：

1. 降低復雜性：分解為獨立子問題
2. 提高可維護性：模塊可單獨修改（例如支付模塊升級不影響訂單模塊）
3. 促進團隊協作：并行開發不同模塊
4. 增強復用性：通用模塊（如日志模塊）可跨系統復用

題目：比較耦合與內聚
??參考答案??：

維度	耦合（Coupling）	內聚（Cohesion）
定義	模塊間依賴程度	模塊內部元素相關程度
目標	追求低耦合（松耦合）	追求高內聚（緊內聚）
示例	數據耦合（最優）	功能內聚（最優）

應用題技巧

題目：根據DFD設計結構圖
??解題步驟??：

1. 判斷DFD類型（變換型/事務型）
2. 識別核心處理模塊
3. 按調用層級繪制模塊（頂層→中層→底層）
4. 用箭頭標注調用方向（勿畫數據流！）

重要提醒：考試中的DFD通常簡化（如機票預訂系統、銀行儲蓄系統），直接套用變換型/事務型模板即可。

第六章：詳細設計

6.1 詳細設計的本質

• 核心任務：設計程序的 “藍圖”（非直接編碼）

• 輸入：概要設計的模塊結構圖

• 輸出：模塊的 算法描述（流程圖/盒圖/偽代碼） + 數據結構

• 關鍵目標：

  1. 可讀性高（方便他人維護）
  2. 可測試性強（邏輯清晰易覆蓋）
  3. 與編程語言無關（設計先于實現）

考點：區分總體設計（模塊劃分） vs 詳細設計（模塊內部邏輯）

6.2 結構化程序設計

定義

如果一個程序的代碼塊僅通過 順序、選擇、循環 3種基本控制結構連接，且每個代碼塊 只有一個入口和一個出口，則稱為結構化程序。

三種基本結構詳解

結構	圖形表示（流程圖）	特點
順序		按順序執行語句（無分支）
選擇		單分支/雙分支（if-else）
循環		當型/直到型循環（while/for）

重要原則：

• 禁止使用 goto 語句（破壞單入口單出口）
• 嵌套深度 ≤ 3層（否則需拆分子模塊）

6.3 詳細設計工具

1. 程序流程圖（最傳統）

• 優點：直觀易畫

• 缺點：

  • 允許任意跳轉（破壞結構化）
  • 無法約束作用域（如循環體范圍模糊）

2. 盒圖（N-S圖，考試首選）

• 特點：

  • 功能域明確（矩形框限定范圍）
  • 禁止控制轉移（強制結構化）
  • 嵌套結構可視化（循環/選擇一目了然）

3. 判定表（復雜條件場景）

適用場景：多條件組合決策（如折扣規則）
??設計步驟??：

1. 列出所有條件樁（如：會員等級、訂單金額）
2. 列出所有動作樁（如：打9折、打8折）
3. 填充條件組合與對應動作

條件：會員等級	金牌	金牌	銀牌	非會員
條件：訂單≥1000	Y	N	Y	Y
動作：打9折	?	?
動作：打8折			?
動作：不打折				?

🔥 考點：盒圖是結構化設計的黃金工具，判定表用于多條件邏輯

---

6.4 Jackson方法（面向數據結構設計）

核心思想

程序結構 = 數據結構

• 輸入數據結構 → 程序處理結構
• 輸出數據結構 → 程序輸出結構

設計步驟

1. 分析輸入/輸出數據結構

   用 Jackson 圖表示（樹形結構）

2. 映射到程序結構

   • 輸入結構中的元素 → 程序中的處理模塊
   • 輸出結構中的元素 → 程序中的輸出模塊

3. 列出所有操作（如打開文件、計算校驗和）

4. 分配操作到程序模塊

典型考題

設計一個程序：讀入學生成績文件（格式：文件頭+多條記錄），輸出及格學生名單。
??解題??：

1. 輸入結構：文件 → 文件頭 + 成績記錄（學號+分數）

2. 輸出結構：名單 → 標題 + 多條學生信息（學號）

3. 程序結構：

考點總結與答題技巧

• 詳細設計目標：可讀性 > 效率（易維護優先）
• 結構化程序核心：3種控制結構 + 單入口/出口
• 最結構化工具：盒圖（N-S圖）
• Jackson方法適用于 數據主導型系統（如文件處理）

簡答題模板

題目：為什么提倡結構化程序設計？
??答案??：

1. 可讀性強：避免goto導致的“面條代碼”
2. 易維護：單入口單出口減少邏輯路徑
3. 易驗證：可通過數學證明正確性（如霍爾邏輯）

題目：盒圖 vs 流程圖的優缺點？
??答案??：

維度	盒圖（N-S圖）	流程圖
結構化	強制遵守（無法畫跳轉）	允許非結構化跳轉
作用域	圖形邊界明確（如循環體）	依賴箭頭，易混淆
易用性	嵌套復雜時難繪制	繪制簡單

1. 畫盒圖時：

   • 循環結構必須用 矩形框包裹
   • 選擇結構 明確標注T/F分支

2. 判定表設計：

   • 條件組合需 全覆蓋（2?種情況）
   • 動作避免沖突（每列僅一個?）

3. Jackson方法：

   • 輸入/輸出結構需用 樹形圖表示

• 程序結構需與 數據結構嚴格對應

第七章 實現

7.1 測試的本質與目標

• 核心定義：

  測試的目的是在軟件投入生產性運行之前，盡可能多地發現軟件中的錯誤。

• 關鍵認知：

  • 測試是發現錯誤的過程（非證明無錯）
  • 測試橫跨兩個階段：
    • 單元測試（編碼階段，開發者自測）
    • 綜合測試（測試階段，獨立測試團隊）
  • 測試成本占項目總成本 30%~50%（大型系統）

7.2 白盒測試 vs 黑盒測試（簡答題高頻）

維度	白盒測試（結構測試）	黑盒測試（功能測試）
測試依據	程序內部邏輯結構	軟件功能規格說明書
目標	驗證代碼邏輯正確性	驗證功能是否符合需求
執行者	開發者	測試工程師
典型技術	邏輯覆蓋法、路徑測試	等價類劃分、邊界值分析、錯誤推測法
優勢	深度覆蓋代碼路徑	貼近用戶實際使用場景
局限	無法檢測缺失功能	無法保證內部邏輯全覆蓋

考點：區分兩種測試的適用場景（白盒→單元測試；黑盒→系統測試）

7.3 單元測試的五大焦點

單元測試針對單個模塊，驗證以下方面：

1. 模塊接口

   • 檢查參數傳遞：數量/類型/順序是否匹配
   • 示例：調用calculateTax(income)時傳入字符串應報錯

2. 局部數據結構

   • 檢測局部變量初始化/越界/溢出
   • 案例：數組索引超出范圍

3. 重要執行通路

   • 覆蓋所有關鍵邏輯路徑（如if-else分支）

4. 出錯處理通路

   • 驗證異常處理：如文件不存在時是否友好提示

5. 邊界條件

   • 測試臨界值：如循環的0次和最大值+1

7.4 集成測試策略

1. 自頂向下集成

• 過程：從頂層模塊開始，逐步集成下層模塊

• 特點：

  • 需要樁模塊（Stub）：模擬未實現的下層模塊
  • 優點：早期驗證主要控制流
  • 缺點：底層模塊測試延遲

2. 自底向上集成

• 過程：從底層模塊開始，逐步組裝上層

• 特點：

  • 需要驅動模塊（Driver）：調用被測模塊
  • 優點：無需樁模塊，測試用例易設計
  • 缺點：頂層設計缺陷晚期發現

策略	適用場景	測試難度	缺陷發現階段
自頂向下	控制復雜系統	高（需樁模塊）	早期發現頂層問題
自底向上	數據驅動系統	低	晚期發現頂層問題

7.5 邏輯覆蓋測試用例設計

覆蓋強度排序（由弱到強）：

1. 語句覆蓋（最弱）

• 目標：每條語句至少執行1次

• 用例設計：

  if (A>1 && B==0) X=X/A;  // 需覆蓋
  if (A==2 || X>1)X=X+1;  // 需覆蓋
  

  用例：

  A=2, B=0, X=4
  

  → 執行路徑：

  sacbed
  

2. 判定覆蓋（分支覆蓋）

• 目標：每個判定的真/假分支至少執行1次

• 用例設計：

  • 用例1：A=3, B=0, X=3 → 覆蓋第一個判定真分支（sacbd）

• 用例2：A=2, B=1, X=1 → 覆蓋第一個判定假分支（sabed）

3. 條件覆蓋

• 目標：每個條件的可能取值至少執行1次

• 用例設計：

  • 條件1：A>1（真/假）

  • 條件2：B==0（真/假）

  • 條件3：A==2（真/假）

  • 條件4：

    X>1
    

    （真/假）

    用例：

    • A=2, B=0, X=4（全真）

• A=1, B=1, X=1（全假）

7.6 其他關鍵概念

1. α測試

   • 開發環境下由一個用戶測試（通常是內部用戶）
   • 目的：發現嚴重BUG，驗證核心功能

2. β測試

   • 真實環境中由多個用戶測試
   • 目的：收集用戶體驗，檢測兼容性問題

3. 測試用例

   • 定義：測試數據 + 預期輸出的組合

• 示例：輸入用戶名="", 密碼="123" → 預期輸出：提示“用戶名不能為空”

考點總結與答題模板

選擇題速記

• 測試根本目的：發現錯誤
• 最強邏輯覆蓋：路徑覆蓋
• 最弱邏輯覆蓋：語句覆蓋
• α測試 vs β測試：開發環境 vs 真實環境
• 單元測試重點：邊界條件（如循環0次）

簡答題模板

題目：為什么單元測試要聚焦邊界條件？
??答案??：

1. 邊界易出錯：如數組索引越界、循環次數偏差
2. 用戶輸入不可控：可能輸入極端值（如金額=0或極大值）
3. 防御性編程：提前暴露潛在崩潰點

題目：自頂向下集成的優缺點？
??答案??：
??優點??：

• 早期驗證主控邏輯

• 支持深度優先或廣度優先策略

?缺點??：

• 需要開發樁模塊（增加成本）

• 底層細節測試延遲

應用題技巧

設計邏輯覆蓋用例步驟：

1. 繪制程序流程圖（明確判定節點）

2. 列出所有條件（如A>1, B=0）

3. 根據覆蓋要求生成用例：

   • 語句覆蓋 → 選1組數據覆蓋所有語句

• 判定覆蓋 → 2組數據覆蓋所有分支
  • 條件覆蓋 → 2?組數據覆蓋所有條件取值

4. 驗證路徑：標注每個用例的執行路徑

第八章 軟件維護

8.1 軟件維護的本質

定義（考綱原文）：

在軟件交付使用后，為改正錯誤或滿足新需求而修改軟件的過程。

• 關鍵認知：

  • 維護成本 ≈ 開發成本的4倍（大型系統）
  • 維護階段占軟件生命周期 60%+ 時間
  • 75% 的維護成本用于完善性+適應性維護

8.2 維護類型與特點

四類維護活動對比：

類型	觸發原因	占比	典型案例
改正性維護	修復軟件缺陷（BUG）	20%	修復支付金額計算錯誤
適應性維護	適應環境變化（硬件/OS/法律）	25%	適配Windows 11系統
完善性維護	用戶新增功能需求	50%	為電商系統增加“直播購物”功能
預防性維護	主動優化可維護性	<5%	重構老舊代碼方便未來擴展

🔥 考點：

1. 占比最大：完善性維護（用戶需求驅動）
2. 占比最小：預防性維護（技術驅動）

---

8.3 維護流程與方法

結構化維護流程（需完整軟件配置）：

特點：

1. 以設計文檔為起點（非直接改代碼）
2. 依賴回歸測試（用原始測試用例驗證）
3. 成本低、質量高

?? 對比非結構化維護（無文檔）：

• 直接修改代碼 → 測試困難 → 易引入新錯誤 → 成本極高

8.4 維護實施步驟

標準事件流：

1. 確定維護類型（四選一）

2. 中間步驟：理解現有代碼，修改設計/代碼測試（單元+回歸）

3. 最后一步：復審，檢查配置有效性，確認滿足維護需求表

8.5 可維護性提升

五大影響因素：

因素	定義	提升措施舉例
可理解性	快速理解代碼邏輯	寫注釋、模塊化、命名規范
可測試性	易于設計測試用例	提供測試接口、日志輸出
可修改性	修改代碼的難易程度	低耦合設計、避免全局變量
可移植性	適應新硬件/OS環境	用標準庫、隔離平臺相關代碼
可重用性	組件復用的可能性	設計通用工具類（如DateUtils）

2. 提高可維護性的6大措施（簡答題模板）

3. 模塊化設計：高內聚低耦合（如獨立支付模塊）

4. 詳細設計文檔：描述模塊功能與接口

5. 編碼規范：統一命名/注釋風格

6. 防御式編程：輸入校驗、異常處理

7. 使用高級語言：Java/Python > C > 匯編

8. 保留測試用例：便于回歸測試

8.6 系統重構技術

逆向工程 vs 再工程：

技術	定義	目的
逆向工程	分析代碼 → 提取設計信息（代碼→設計）	理解遺留系統邏輯
代碼重構	優化代碼結構（不改變功能）	提高可讀性/可維護性
預防性維護	主動優化為未來準備	本質是軟件再工程
再工程過程模型	6步：庫存分析→文檔重構→逆向工程→代碼重構→數據重構→正向工程	系統化改造舊系統

🔍 考點辨析：

• 逆向工程：理解現有系統（分析）
• 代碼重構：改進代碼質量（優化）
• 再工程：全面升級系統（重建）

本章知識圖譜

graph TBA[軟件維護] --> B[四大類型]A --> C[結構化流程]A --> D[可維護性]B --> E[改正性/適應性/完善性/預防性]C --> F[文檔→設計→代碼→測試]D --> G[五大因素]

📌 考點提示：

• 維護類型占比（完善性>適應性>改正性>預防性）
• 結構化維護起點（設計文檔）
• 提高可維護性措施（模塊化/文檔/規范）

💡 復習建議：

1. 重點記憶四類維護的占比和典型案例
2. 理解結構化維護與非結構化維護的成本差異
3. 掌握可維護性的五大影響因素

• 維護成本占比：開發成本的4倍
• 最常見維護類型：完善性維護
• 最耗時維護類型：改正性維護（定位隱蔽錯誤難）
• 結構化維護起點：評價設計文檔
• 再工程起點：庫存目錄分析

簡答題模板

題目：為什么軟件維護成本高？
??答案??：

1. 需求變化頻繁：用戶新增完善性需求（占50%）
2. 人員流動：新成員理解舊代碼困難
3. 文檔缺失：非結構化維護效率低
4. 系統老化：技術債務累積（如祖傳代碼）

題目：提高可維護性的具體措施？
??答案??：

1. 設計階段：模塊化分解（高內聚低耦合）

2. 實現階段：

   • 編寫可讀代碼（命名規范+注釋）
   • 使用高級語言（如Java）

3. 測試階段：保存測試用例用于回歸測試

4. 維護階段：完善文檔記錄修改歷史

易錯點提醒

• 錯誤：”預防性維護占比最大“ → 改正：完善性維護最大
• 錯誤：”維護從修改代碼開始“ → 改正：結構化維護從評價設計文檔開始

💎 終極提示：本章約5-10分，重點記憶 四類維護占比 和 可維護性措施！

第九章 面向對象方法學

9.1 面向對象方法學核心

特點（簡答題重點）：

定義（考綱原文）：

面向對象方法學的出發點和基本原則，是盡可能模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程。

五大優點：

1. 與人類思維一致

   • 現實世界→對象模型直接映射
   • 案例：銀行系統用"賬戶"對象直接對應真實賬戶

2. 穩定性好

   • 基于對象而非功能分解，需求變化時只需修改局部

3. 可重用性好

   • 通過繼承實現代碼復用（如"VIP客戶"繼承"客戶"類）

4. 易開發大型系統

   • 模塊化程度高（如電商系統分解為訂單、支付、庫存等對象）

5. 可維護性好

   • 封裝性使修改影響局部化

9.2 核心概念辨析

類與對象關系（選擇題高頻）：

概念	定義	關系說明
類	具有相同屬性和操作的對象的模板（如"汽車"類）	類是對象的抽象
對象	類的實例（如"車牌A123的寶馬汽車"）	對象是類的具體化
實例	由類創建的具體對象（與"對象"同義）	實例=對象

🔥 關鍵區別：

• 類 = 設計藍圖（如"學生"類）
• 對象 = 根據藍圖建造的具體事物（如"學號20231101的張同學"）

9.3 面向對象模型

三種模型對比（選擇題必考）：

模型	描述	核心作用	圖形工具
對象模型	靜態數據結構	描述系統"數據"性質，是其他模型的基礎	類圖
動態模型	行為控制	描述對象狀態變化序列（如訂單從"未支付"→"已發貨"）	狀態轉換圖
功能模型	系統功能	描述系統"做什么"，直接反映用戶需求	用例圖

考試重點**：對象模型是最核心模型，為其他模型提供框架

9.4 類的關系類型

四種關系詳解（應用題核心）：

1. 關聯（Association）

• 定義：類間的語義連接（如"學生"-“選課”-“課程”）

• 符號：直線連接類

• 多重性：

  • 1：1（一個學生一個學號）
  • 1：N（一個老師教多個學生）
  • M：N（學生選多門課/課程有多學生）

2. 聚集（Aggregation）

• 共享聚集：部分可屬于多個整體（如"學生"加入多個"社團"）

• 組合聚集：部分與整體共存亡（如"訂單"與"訂單項"）

3. 泛化（Generalization）

• 繼承關系（如"VIP客戶"繼承"客戶"）

  classDiagramCustomer <|-- VIPCustomer
  

• 抽象類：類名標注{abstract}（如"支付方式"抽象類）

4. 依賴（Dependency）

• 臨時使用關系（如"報表生成器"依賴"數據庫連接"）

  classDiagramReportGenerator ..> Database : 使用
  

第十章 面向對象分析

10.1 OOA核心任務

輸入輸出（選擇題）：

• 輸入：用戶需求
• 輸出：三種模型（對象/動態/功能模型）
• 關鍵活動：
  1. 識別類與對象
  2. 定義屬性與服務
  3. 建立對象關系

重點：OOA階段不涉及實現細節（如編程語言）

10.2 建模層次

五個層次說明（簡答題）：

層次	內容	案例（電商系統）
主題層	系統模塊劃分	用戶管理、訂單處理、支付系統
類與對象層	識別核心類	Customer, Order, Product
結構層	類之間關系	Order “1"→"N” OrderDetail
屬性層	類的屬性定義	Order: orderID, totalPrice
服務層	類的操作（方法）	Order: calculateTotal()

主題層作用：簡化復雜系統（如將大型ERP分解為采購/銷售/庫存主題）

10.3 類與對象識別

非正式分析法步驟（應用題）：

非正式分析法步驟（考綱要求）：

1. 提取名詞：從需求描述中圈出所有名詞

   需求：“學生通過選課系統選擇課程，教師管理課程信息”
   名詞：學生、選課系統、課程、教師

2. 篩選候選類：

   • 保留核心實體（學生、課程、教師）
   • 剔除邊界類（選課系統）

3. 確定屬性：用形容詞描述（學生：學號、姓名）

4. 確定服務：用動詞描述（學生：選課()、查詢成績()）

類圖繪制規范：

10.4 用例圖設計

元素與關系（應用題）：

元素說明：

• 行為者(Actor)：系統外部交互者（學生、教師）
• 用例(Use Case)：系統功能單元（選課、評分）
• 關系類型：
  • 包含<<include>>：必選子功能（選課必須驗證身份）
  • 擴展<<extend>>：可選功能（評分可擴展打印成績單）

案例：選課系統

usecaseDiagramactor Student as Sactor Teacher as TS --> (選課) : 包含(選課) .> (身份驗證) : <<include>>(評分) --> (打印成績單) : <<extend>>T --> (評分)

尋找行為者的關鍵問題（考綱要求）：

1. 誰使用主要功能？ → 學生
2. 誰維護系統？ → 管理員
3. 系統交互的硬件？ → 打印機
4. 其他關聯系統？ → 教務系統

本章知識圖譜

📌 考點提示：

• 區分三種模型的作用（對象模型最基礎）
• 掌握四種類關系的符號表示
• 用例圖關系類型（包含 vs 擴展）

💡 復習建議：

1. 重點記憶類圖的四種關系符號
2. 練習用例圖設計，注意行為者位置
3. 理解對象模型是其他模型的基礎

• 面向對象最核心模型：對象模型
• 組合聚集符號：實心菱形
• 用例圖關系：包含→必選，擴展→可選
• 主題層本質：模塊化分解

簡答題模板

題目：為什么面向對象方法更穩定？
??答案??：

1. 基于對象建模：需求變化時只需修改局部對象（如支付方式新增）
2. 封裝性保護：屬性私有化，修改不影響外部調用
3. 繼承機制：通用功能在父類統一維護

題目：泛化與聚集的區別？
??答案??：

維度	泛化（繼承）	聚集（整體-部分）
關系	"是一種"關系（VIP客戶是客戶）	"包含"關系（訂單包含商品項）
生命周期	父子類獨立存在	組合聚集中部分隨整體銷毀而銷毀

應用題避坑指南

1. 畫類圖時：

   • 必須標注多重性（如1、N、*）
   • 組合聚集用實心菱形（整體刪除則部分刪除）

2. 用例圖時：

   • 行為者必須在系統外部（數據庫不算行為者）

• 用例名用動詞+名詞（如"生成報表"）

💎 終極提示：面向對象分析的核心是"識別正確的類"，考試中類圖設計占分高，務必掌握名詞篩選法！

第十三章 軟件項目管理

13.1 項目管理基礎

定義（考綱原文）：

軟件項目管理先于任何技術活動之前開始，并且貫穿于軟件的整個生命周期之中。

• 管理范疇：

  1. 成本估算（規模/工作量）
  2. 進度計劃（甘特圖/關鍵路徑）
  3. 團隊組織（人員配置）
  4. 質量保證（CMM/測試）

13.2 規模估算方法

兩種常用方法對比：

方法	核心原理	適用場景
代碼行技術	基于歷史項目數據，估算新項目的代碼行數（LOC）	有類似項目歷史數據時
功能點技術	通過系統功能數量估算規模（輸入/輸出/查詢/文件/接口數）	早期需求階段（更準確）

功能點計算示例：

• 輸入數：用戶表單（如注冊表單）
• 輸出數：報表（如銷售報表）
• 查詢數：搜索操作
• 文件數：數據庫表
• 接口數：外部系統API

📌 考點：功能點技術獨立于編程語言，更適合早期估算

13.3 團隊組織模式

三種模式對比：

模式	核心特點	缺點
民主制小組	成員平等協商（≤10人）	決策效率低
主程序員組	技術大牛（主程序員）主導 + 后備程序員 + 秘書	主程序員成為瓶頸
現代程序員組	雙負責人： - 技術組長（技術決策） - 行政組長（資源/進度管理）	最佳實踐（權責分離）

布魯克斯定律：

向進度落后的項目中增加人手，只會使進度更加落后。

• 原因：新人培訓成本 + 溝通開銷指數級增長

13.4 軟件質量定義

三個核心要點：

三個核心要點（考綱原文）：

1. 需求符合性：軟件行為與需求規格一致
2. 標準符合性：遵守開發規范（如編碼標準）
3. 隱含需求滿足：滿足未明寫的期望（如可維護性）

? 正確質量觀：

• 通過驗收測試 ≠ 高質量（可能未測隱含需求）
• 無BUG ≠ 高質量（可能不符合可維護性標準）

13.5 能力成熟度模型(CMM)

五個成熟度等級：

軟件質量問題的根源是過程管理不當，而非技術不足。

五個成熟度等級：

等級	關鍵特征	企業狀態
初始級	過程無序，依賴個人英雄主義	小作坊模式
可重復級	可復用成功經驗（如成本估算）	有基本項目管理
已定義級	過程標準化（文檔化流程）	中型企業主流
已管理級	量化控制（如缺陷率統計）	成熟企業
優化級	持續改進過程	行業標桿（如微軟/谷歌）

🔥 考點：

• 國內企業多數處于2~3級
• 最高級是優化級（5級）

本章知識圖譜

📌 考點提示：

• 功能點技術適用于早期估算
• 現代程序員組是最佳實踐模式
• CMM五級名稱及特征（優化級為最高）

💡 復習建議：

1. 重點記憶CMM五個等級名稱
2. 理解布魯克斯定律的實際意義
3. 區分功能點與代碼行估算的適用場景

• 早期規模估算首選：功能點技術
• 最佳團隊模式：現代程序員組（技術+行政分離）
• 質量基礎：需求規格說明書
• CMM最高級：優化級（5級）
• 人員增加的影響：生產率不線性增長（布魯克斯定律）