软件工程学习笔记

教材：《软件工程实例教程》第10版
内容依据：课程教学大纲、课堂笔记、章节作业及考试题型

复习优先级速览

优先级	模块	分值占比
1	UML 建模（用例图、类图、时序图、活动图、状态图）	应用题主力
2	软件过程模型选择	应用题主力
3	需求分析（功能/非功能、模糊需求量化、SRS）	应用题主力
4	软件设计原则、测试用例	客观题 + 应用题
5	软件危机、CMM、可行性研究	客观题

期末分析应用题 + 高阶应用题合计约 70%，不能只背概念，必须会画图、会选模型、会改写需求。

第一章 软件工程概述

1. 软件的发展历程

阶段	大致时期	开发特点	主要问题
程序设计时代	20世纪40年代末至50年代末	个人独立编写小程序	缺少规范和文档
程序系统时代	20世纪60年代至70年代初	作坊式小团体合作	软件规模扩大，软件危机集中暴露
软件工程时代	20世纪70年代至今	按工程化方法组织开发	通过规范过程控制成本、进度和质量

软件规模和复杂度不断增长后，个人或作坊式开发方式无法有效控制项目，软件危机由此暴露，并推动了软件工程的产生。

软件危机推动了软件工程的形成。

2. 软件危机

软件危机是指软件开发和维护过程中出现的一系列严重问题。

典型表现	具体含义
成本失控	实际费用远高于原计划
进度失控	项目延期，无法按时交付
需求偏差	软件不能满足用户真实需要
质量较差	错误多，可靠性不足
维护困难	软件交付后难以修改和扩展
文档不足	缺少完整的开发和维护资料

产生软件危机的主要原因：

• 软件规模和内部关系越来越复杂
• 缺少统一、规范的软件开发过程
• 忽视前期需求分析
• 缺少完善的质量保证和项目管理方法
• 开发人员之间沟通和协作困难

单纯增加开发人员不一定能够提高效率，因为新成员会增加培训、沟通和管理成本。

软件工程能够缓解和控制软件危机，但软件危机并没有彻底消失。

3. 软件的概念与组成

软件是与计算机系统运行有关的程序、数据和文档的完整集合。

软件 = 程序 + 数据 + 文档

组成	含义	常见内容
程序	描述计算机处理规则的指令集合	源程序、可执行程序
数据	程序输入、处理、存储和输出的信息	用户数据、配置数据、业务数据
文档	开发、使用和维护软件所需的资料	需求说明书、设计说明书、用户手册

需要注意：

• 软件不等于程序。
• 开发软件不等于只编写程序。
• “记录”不属于软件组成的三个基本类别。
• 按课程题库口径，软件中的可执行部分是程序和数据。

4. 软件的特点

特点	含义
无形性	软件是逻辑实体，只能通过运行结果观察
无磨损性	软件不会因使用发生物理磨损，但会因需求和环境变化而修改
开发性	软件主要通过分析、设计和编码形成，不是传统流水线制造
智力密集性	软件开发高度依赖人的分析、设计和逻辑思维
复杂性	软件规模越大，模块和关系越复杂
易变性	软件容易修改，但修改可能引起其他部分变化

软件维护阶段通常持续时间较长，所需费用也较高。

5. 软件的分类

按功能分类

类型	作用	例子
系统软件	管理计算机资源，支持系统运行	操作系统、数据库管理系统、编译器
支撑软件	支持软件开发、测试和维护	开发工具、建模工具、测试工具
应用软件	解决用户的具体业务问题	办公软件、工业控制软件、管理系统

常见判断：

• 办公软件属于应用软件。
• 操作系统属于系统软件。
• 数据库管理系统通常属于系统软件。

其他分类方式

分类依据	类型
按服务对象	通用软件、定制软件
按处理方式	实时处理、分时处理、交互式、批处理软件
按规模	微型、小型、中型、大型软件

期末客观题最常考的是系统软件、支撑软件和应用软件的区分。

6. 软件工程

软件工程是应用计算机科学理论、工程管理原则和规范化方法，在规定的成本和进度内，开发、运行和维护满足用户需求的软件。

软件工程是一门工程性学科，其目标是：

• 满足用户需求
• 保证软件质量
• 控制成本和进度
• 提高开发效率
• 提高软件的可维护性
• 使软件生产规范化和工程化

软件工程过程不仅包括设计和编码，还包括需求分析、测试、交付、维护和项目管理。

7. 软件工程方法学

软件工程方法学由方法、工具和过程组成。

要素	含义	例子
方法	规定软件开发各阶段怎样完成	面向对象分析与设计
工具	辅助执行软件工程活动	UML建模工具、测试工具
过程	规定开发活动的顺序和管理方式	瀑布模型、增量模型

软件工程方法学 = 方法 + 工具 + 过程

8. 软件工程基本原则

原则	含义
分阶段管理	按软件生命周期安排任务和资源
阶段评审	每个阶段完成后检查成果，再进入下一阶段
产品与变更控制	对需求、文档和程序的修改进行统一管理
使用现代方法	采用合适的分析、设计、建模和开发技术
结果可审查	各阶段成果应清晰、完整、能够验证
团队小而精	减少不必要的沟通和管理成本
持续改进	根据实践不断改进软件过程

9. AI环境下的软件工程

AI可以辅助代码生成、原型构建、测试和文档编写，但不能自动解决需求不明确、系统复杂、架构设计、质量责任和软件维护等问题。

AI生成结果还可能存在错误代码、安全漏洞和难以维护等风险。

AI可以提高开发效率，但不能代替需求分析、软件设计和测试验证。

AI 时代软件危机的新表现

表现	含义
代码质量不稳定	AI 生成的代码可能存在隐藏缺陷、安全漏洞
责任归属模糊	AI 协助产出的错误由谁负责难以界定
版权与合规风险	AI 可能产出与训练数据相似的代码，引发版权问题
能力依赖	过度依赖 AI 会削弱开发者的分析和设计能力
需求分析更难	用户用 AI 生成原型后，反而更容易跳过真正的需求沟通
维护困难	AI 生成的代码结构混乱，长期可维护性较差

本章重点速记

• 三个时代：程序设计时代 → 程序系统时代 → 软件工程时代
• 程序系统时代的特点：作坊式小团体合作
• 软件危机表现为成本、进度、质量、需求和维护问题
• 软件 = 程序 + 数据 + 文档
• 软件是逻辑产品，具有无形性和无磨损性
• 软件分为系统软件、支撑软件和应用软件
• 软件工程是一门工程性学科
• 软件工程方法学：方法、工具、过程
• 软件工程缓解软件危机，但没有彻底消除软件危机
• AI 时代新危机：代码质量不稳、责任模糊、版权风险、能力依赖

第二章 软件生命周期与软件过程模型

1. 软件生命周期

软件生命周期是软件从提出、开发、交付使用，到最终停止使用的完整过程。

软件生命周期可以分为三个时期：

时期	包含阶段	主要解决的问题
定义时期	问题定义、可行性研究、需求分析	做什么、是否值得做
开发时期	软件设计、编码、测试	怎样做、实现是否正确
使用和维护时期	运行与维护	交付后怎样修改和完善

完整过程：

问题定义 → 可行性研究 → 需求分析 → 概要设计 → 详细设计 → 编码 → 测试 → 运行维护

2. 生命周期各阶段及产物

阶段	核心任务	主要产物
问题定义	明确需要解决的问题	问题定义说明
可行性研究	判断能不能做、值不值得做	可行性研究报告
需求分析	确定软件应当做什么	软件需求规格说明书
概要设计	确定系统总体结构	概要设计说明书
详细设计	确定模块内部实现	详细设计说明书
编码	将设计转化为程序	源程序和可执行程序
测试	发现错误并验证需求	软件测试报告
维护	交付后修改和完善软件	维护记录和新版本

需求分析是软件开发中非常重要的阶段。需求一旦理解错误，后续设计、编码和测试都可能建立在错误基础上。

软件交付给用户并正式投入使用后，进入维护阶段，直到软件被淘汰。

软件维护通常占整个软件生命周期成本的 60% 以上，是生命周期最长的阶段。

软件维护的 4 种类型

类型	含义	例子
改正性维护	修复测试阶段未发现的错误	修复运行中暴露的 bug
适应性维护	适应硬件、软件或数据环境变化	升级操作系统后修改兼容性
完善性维护	为满足新需求而增加功能	增加报表导出 PDF 功能
预防性维护	为减少未来故障而提前改进	重构老代码以提高可维护性

4 种维护中，完善性维护占比最高，改正性维护其次。

3. 软件过程与过程模型

软件过程是：

为开发、交付和维护软件而进行的一组软件工程活动。

软件过程模型是：

对软件开发活动及其先后关系的抽象描述。

“功能模型”不是软件过程模型，而是描述系统功能的模型。

4. 瀑布模型

瀑布模型按阶段依次向下推进：

需求分析 → 软件设计 → 编码 → 测试 → 运行维护

瀑布模型本质上是一种线性顺序模型。

特点	说明
阶段清楚	每个阶段有明确任务和产物
文档完整	便于计划、评审和管理
变更困难	需求变化后返回修改成本较高

适用于需求明确、技术成熟、变化较少的项目。

带反馈的瀑布模型允许后续阶段发现问题后返回前一阶段修改，但仍以顺序为主，是"小幅度回退"。

瀑布 vs 带反馈瀑布 vs V 模型

模型	是否允许回退	核心特征
瀑布模型	不允许	严格线性，需求稳定
带反馈的瀑布模型	仅返回前一阶段	线性为主，允许小修改
V 模型	强调开发与测试对应	每个开发阶段都有对应测试

5. V模型

V模型强调开发阶段与测试阶段的对应关系。

开发阶段	对应测试
用户需求	验收测试
系统需求	系统测试
概要设计	集成测试
详细设计	单元测试

V模型的重点是提前考虑测试，使每个开发阶段都有相应的验证活动。

6. 快速原型模型

原型是为了帮助用户理解和确认需求而建立的软件雏形，不一定是最终软件。

基本过程：

初步需求 → 快速设计 → 建立原型 → 用户评价 → 修改需求

适用于：

• 用户无法准确描述需求
• 用户不知道系统应该是什么样
• 界面和交互方式不明确

原型可以分为：

类型	处理方式
抛弃型原型	需求明确后丢弃，重新开发正式系统
演化型原型	不断修改，逐步发展为最终系统

提示

原型不是必然的最终可运行版本。

7. 增量模型与迭代模型

增量模型

增量模型将系统划分为多个功能部分，按照优先级逐步开发和交付。

例如：

第一增量：核心功能
第二增量：扩展功能
第三增量：完善功能

适用于时间紧、需要先交付高优先级功能的项目。

迭代模型

迭代模型通过多次循环，不断修改和完善已经存在的系统。

增量	迭代
不断增加新功能	不断改进已有功能

实际项目中，增量和迭代经常结合使用。

8. 螺旋模型

螺旋模型综合了瀑布模型和快速原型模型的特点，并增加风险分析。

每一轮主要包括：

1. 制定计划
2. 风险分析
3. 工程开发
4. 用户评审

螺旋模型的核心是：

风险驱动。

适用于规模大、技术新、没有类似产品、风险较高的项目。

9. RUP模型

RUP是一种面向对象的软件开发过程。

三个核心特点：

• 用例驱动
• 以体系结构为中心
• 迭代和增量开发

阶段	主要任务
初始阶段	确定项目目标和范围
细化阶段	分析需求、建立核心架构、处理主要风险
构建阶段	完成系统主要功能
交付阶段	部署系统并交付用户

RUP的每个阶段都可以包含多次迭代。

RUP 的"迭代"是指在限定时间内重复执行一组活动（需求、设计、编码、测试），每次迭代都产生一个可运行的系统版本。 这与传统的瀑布模型"一次性走完全部阶段"截然不同，更适合需求变化大、风险较高的项目。

10. 敏捷开发

敏捷开发强调：

• 短周期迭代
• 持续交付
• 用户参与
• 快速反馈
• 响应需求变化

适用于需求变化较频繁、需要不断发布版本的项目。

11. 基于构件的过程模型

基于构件的过程模型通过复用已有软件构件组装系统。

核心是：

软件复用。

使用构件时需要考虑：

• 构件是否满足需求
• 构件接口是否兼容
• 构件质量是否可靠

12. 过程模型的选择

项目特征	适用模型
需求明确、变化较少	瀑布模型
强调开发和测试对应	V模型
用户说不清需求	快速原型模型
需要先交付核心功能	增量模型
需要持续改进已有功能	迭代模型
规模大、技术新、风险高	螺旋模型
需求频繁变化、持续发布	敏捷开发
大型面向对象项目、强调架构	RUP模型

模型选择题需要根据题目中的项目特征说明选择理由，不能只写模型名称。

13. CMM软件能力成熟度模型

CMM用于评价和改进软件组织的软件开发过程成熟度，不是直接评价某一个软件产品的质量。

等级	名称	核心特点
1	初始级	过程混乱，依赖个人能力
2	可重复级	建立基本项目管理
3	已定义级	过程标准化、文档化
4	已管理级	使用数据进行定量管理
5	优化级	持续改进过程

本章重点速记

• 生命周期分为定义、开发、使用和维护三个时期
• 需求分析是非常重要的阶段
• 软件维护从软件交付使用后开始，维护成本占总成本 60% 以上
• 维护 4 类：改正性、适应性、完善性、预防性（完善性占比最高）
• 瀑布：需求稳定；带反馈瀑布：允许小回退；V 模型：开发与测试对应
• 原型：需求不明确
• 增量：先交付核心功能；迭代：不断完善已有功能
• 螺旋：大型、高风险项目
• RUP：用例驱动、架构中心、迭代增量；每个阶段都包含多次迭代
• CMM评价软件过程成熟度

第三章 问题定义与可行性研究

1. 问题定义

问题定义用于明确项目真正需要解决的问题。

主要确定：

• 当前存在什么问题
• 问题影响哪些用户
• 项目希望达到什么目标
• 系统的范围和边界是什么

问题定义回答“为什么做、解决什么”，不直接研究程序怎样实现。

2. 可行性研究

可行性研究是：

用尽可能小的代价和尽可能短的时间，判断问题是否存在可行的解决方案。

主要回答：

• 项目能不能做
• 项目值不值得做
• 是否应该继续投入

3. 可行性研究的内容

类型	判断内容
技术可行性	现有技术、人员和设备能否实现
经济可行性	成本与收益是否合理
操作可行性	用户和组织能否接受和使用
法律可行性	是否违反法律、合同、版权和隐私要求
时间可行性	能否在规定时间内完成

题目中“从经济方面考虑是否值得开发”属于经济可行性。

4. 投资回收期

投资回收期是收回项目初始投资所需要的时间。

一般情况下：

投资回收期越短，项目越有投资价值。

5. 可行性研究与需求分析的关系

正确顺序：

问题定义 → 可行性研究 → 需求分析 → 软件需求规格说明书

可行性研究判断项目是否值得继续，需求分析才详细确定系统应当做什么。

本章重点速记

• 问题定义：明确问题、目标和范围
• 可行性研究：判断能不能做、值不值得做
• 可行性包括技术、经济、操作、法律和时间
• 投资回收期越短通常越有利
• 可行性研究在需求分析之前

第四章 需求分析与需求规格说明书

1. 软件需求

软件需求是用户对软件系统在功能、行为、性能、接口和约束等方面的期望。

需求分析主要回答：

软件应当做什么。

需求分析阶段不详细研究程序怎样编码、使用什么算法以及模块内部怎样实现。

2. 需求的分类

功能需求与非功能需求

类型	回答的问题	例子
功能需求	系统做什么	用户登录、选择课程、生成成绩单
非功能需求	系统做得怎样	响应时间、安全性、并发能力

如果系统提供了某项功能，但执行结果错误，仍属于功能需求没有正确实现。

例如：用户取款500元，ATM只吐出100元但账户扣除500元，说明取款和扣款功能执行错误。

其他分类方式

分类角度	类型
描述层次	用户需求、系统需求
需求对象	产品需求、过程需求
表达方式	定性需求、定量需求

软件需求可以从不同角度进行分类，功能需求与非功能需求是最重要的分类方式。

3. 合格需求的基本性质

性质	含义
必要性	确实是用户或系统需要的
正确性	符合用户真实意图
完整性	没有遗漏必要内容
一致性	不同需求之间没有矛盾
无歧义性	只有一种明确解释
可行性	技术、成本和时间上能够实现
可验证性	能通过测试判断是否满足
可追踪性	能找到需求来源及对应设计和测试

“可扩展性”通常不属于需求本身的基本性质。

4. 需求分析的基本过程

需求获取 → 需求建模 → 形成需求规约 → 需求验证与确认 → 需求管理

活动	主要内容
需求获取	从用户和业务中收集需求
需求建模	使用模型抽象描述需求
形成需求规约	编写需求规格说明书
需求验证与确认	检查需求是否正确、完整、可行
需求管理	记录、跟踪和控制需求变化

需要区分：

• 检查需求是否正确，属于需求验证与确认。
• 对需求进行版本控制和变更审批，属于需求管理。

5. 需求获取

需求可以来自：

• 用户和业务人员
• 现有业务流程
• 业务表单和文档
• 现有软件系统
• 法律和行业规范
• 市场及竞争产品

需求获取需要用户、需求分析人员、开发人员和测试人员共同参与。

常见需求获取方法

方法	适用情况	主要特点
访谈法	需要深入了解复杂业务	可以追问，但较耗费时间
问卷法	用户数量较多	覆盖面广，但不便深入交流
观察法	需要了解真实工作过程	能发现用户未明确表达的需求
原型法	用户不能准确描述需求	直观，便于获得反馈
文档分析法	已有制度、表单和资料较多	系统性强，但文档可能过时

实际项目通常综合使用多种方法。

6. 模糊需求的修改

需求必须明确、可量化、可验证。

模糊描述	修改后的需求
系统响应速度要快	95%的用户请求应在2秒内返回结果
内存占用不能太高	系统稳定运行时内存占用不得超过1GB
多用户使用时不能崩溃	系统支持500名用户同时在线并稳定运行8小时

修改原则：

模糊形容词 → 具体指标 + 测试条件 + 可验证结果

7. 需求验证与评审

需求评审用于检查需求规格说明书能否作为设计、开发和测试的可靠依据。

主要检查：

• 是否符合用户真实需要
• 是否完整、一致和无歧义
• 是否能够实现
• 是否能够测试
• 是否能够追踪

需求评审应有用户参与。软件工具可以辅助检查，但不能保证需求绝对正确。

8. 软件需求规格说明书

软件需求规格说明书简称SRS，是对系统功能需求、非功能需求、接口和约束的完整、准确和可验证描述。

主要作用：

• 作为用户与开发者之间的约定
• 作为软件设计的依据
• 作为软件测试和验收的依据
• 作为需求变更管理的基础

内容	说明
引言	编写目的、项目背景和术语
系统总体描述	系统范围、用户特点和运行环境
功能需求	系统应提供的功能
非功能需求	性能、安全和可靠性要求
外部接口需求	用户、软件、硬件和通信接口
数据需求	主要数据及其约束
验收与追踪	如何验证和追踪需求

SRS不应详细描述具体算法和程序内部实现过程。

合格 SRS 的评判标准

标准	含义
正确	真实反映用户需求
完整	没有遗漏必要功能
一致	各条需求之间没有矛盾
无歧义	每条需求只有一种理解
可验证	每条需求都能通过测试验证
可追踪	每条需求都能追溯到来源、对应设计和测试
可修改	结构清晰，易于增删修改
不含实现	不描述具体算法、内部结构、编程语言

本章重点速记

• 需求分析回答：软件应当做什么
• 功能需求：做什么；非功能需求：做得怎样
• 合格需求应完整、一致、无歧义、可验证
• 需求过程：获取 → 建模 → 规约 → 验证 → 管理
• 模糊需求必须量化
• 需求分析最终形成SRS
• SRS不写算法的详细实现
• 合格 SRS 7 标准：正确、完整、一致、无歧义、可验证、可追踪、不含实现

第五章 面向对象基础与用例模型

1. 对象与类

对象由三部分组成：

标识 + 属性 + 操作

组成	含义
标识	区分不同对象的唯一身份
属性	对象的数据和状态
操作	对象可以执行的行为

类是具有相同属性和操作的一组对象的抽象描述。

类是对象的模板，对象是类的实例。

2. 面向对象的基本特征

特征	含义	判断关键词
封装	将属性和操作结合，并隐藏内部实现	隐藏内部信息
继承	子类获得父类的属性和操作	子类获得父类内容
多态	同一操作在不同对象中有不同实现	同名操作、不同实现
消息	对象请求另一个对象执行操作	对象之间交互

例如：

• 经理和工人继承员工的共同属性和操作，体现继承。
• 经理和工人的“计算工资”方法不同，体现多态。

3. 面向对象分析的三个模型

模型	主要描述
对象模型	对象、类及其静态关系
动态模型	对象交互和状态变化
功能模型	系统需要完成的功能和处理

其中，对象模型是核心模型。

4. UML

UML是统一建模语言，是一种标准化的图形建模语言。

需要区分：

• UML是一种建模语言。
• UML不是编程语言。
• UML不是完整的软件开发方法。
• UML与具体的软件开发过程相互独立。

UML图	主要描述
用例图	参与者和系统功能
类图	类及其静态关系
时序图	对象之间的消息顺序
活动图	业务流程和分支
状态图	一个对象的状态变化

类图和对象图主要描述静态结构；时序图、活动图和状态图描述动态行为。

5. 用例图

用例图描述：

哪些外部参与者使用系统提供的哪些功能。

可以概括为：

谁使用系统做什么。

基本元素

元素	含义
参与者	系统外部与系统交互的角色
用例	系统向参与者提供的完整功能
系统边界	表示系统范围
关系	表示参与者和用例之间的联系

参与者可以是人、外部设备或其他软件系统，但必须位于系统外部。

用例名称一般使用动宾结构，如“查询成绩”“提交订单”。

6. 用例图中的关系

关联关系

参与者与用例之间使用关联关系，表示参与者使用该功能。

包含关系

使用 <<include>> 表示。

一个用例执行时，必须执行另一个公共用例。

例如：

提交订单 <<include>> 验证身份

箭头指向被包含用例。

扩展关系

使用 <<extend>> 表示。

在特定条件下，为基本用例增加一个可选行为。

例如：

到书通知 <<extend>> 还书

箭头由扩展用例指向基本用例。

泛化关系

表示一般参与者与特殊参与者，或者一般用例与特殊用例之间的继承关系。

情况	关系
每次都必须执行	包含
满足条件才执行	扩展
一般与特殊	泛化

7. 用例图的绘制

基本过程：

1. 确定系统边界。
2. 找出系统外部参与者。
3. 根据参与者目标识别用例。
4. 建立参与者与用例的关联。
5. 判断用例之间是否存在包含、扩展或泛化。
6. 检查是否遗漏角色和功能。

用例图只描述用户可见的系统功能，不描述程序内部实现。

绘制示例：在线选课系统

题目材料：

学生可以登录系统、浏览课程、选择课程和退选课程； 选课前必须先登录；学生在选课时若所选课程已满，系统提示"选课失败"。

分析：

步骤	结果
参与者	学生
用例	登录、浏览课程、选择课程、退选课程
系统边界	整个"在线选课系统"框
关系	"选择课程" <<include>> "登录"
条件分支	"选课失败"是"选择课程"的 <<extend>> 扩展点

关键：include 是每次都必须执行；extend 是特定条件下才触发。

本章重点速记

• 对象 = 标识 + 属性 + 操作
• 类是对象的模板，对象是类的实例
• 隐藏内部信息：封装
• 子类获得父类内容：继承
• 同名操作不同实现：多态
• 面向对象分析包括对象、动态和功能模型
• UML是建模语言，不是开发方法
• 用例图描述“谁使用系统做什么”
• 必须发生用include；条件发生用extend
• 必考题型：给一段文字描述，要求识别参与者、用例和关系

第六章 对象模型与类图

1. 类图

类图描述系统中有哪些类，以及类之间的静态关系。

一个类通常由三部分组成：

类名
属性
操作

2. 类图中的关系

类图中常见五种关系：

• 依赖
• 关联
• 聚合
• 组合
• 继承或泛化

依赖

一个类临时使用另一个类提供的功能。

例如：

类A调用数学函数库。

表示方式：

虚线箭头，由使用者指向被使用者。

关联

两个类之间存在较稳定的业务联系。

例如：

学生选择课程
教师教授课程

聚合

聚合是较弱的整体与部分关系，部分可以脱离整体独立存在。

例如：

公司与部门
班级与学生

表示方式：

空心菱形位于整体一端。

组合

组合是较强的整体与部分关系，部分的生命周期依赖整体。

例如：

订单与订单明细
房屋与房间

表示方式：

实心菱形位于整体一端。

继承或泛化

子类是一种父类，并继承父类的属性和操作。

例如：

经理是一种员工。

表示方式：

空心三角箭头指向父类。

3. 类关系的判断

题目表达	关系
“是一种”	继承
存在稳定业务联系	关联
整体消失，部分仍可存在	聚合
整体消失，部分也随之消失	组合
临时调用另一个类	依赖

4. 多重性

多重性表示一个对象可以与多少个另一类对象建立关系。

表示	含义
1	恰好一个
0..1	零个或一个
*	多个
0..*	零个或多个
1..*	至少一个

例如：

• 一个部门生产多种产品，每种产品只由一个部门生产：一对多。
• 一个工人参与多个项目，一个项目有多个工人：多对多。

5. 类图的构造

基本过程：

1. 根据需求中的名词识别候选类。
2. 删除重复、无关或只适合作为属性的名词。
3. 确定类的职责、属性和操作。
4. 分析类之间的关系。
5. 标注关系的多重性。
6. 检查类图是否与需求一致。

绘制示例：图书管理系统

题目材料：

一本书只属于一个图书类别，一个图书类别包含多本书； 一位读者可以借阅多本书，每本书可以被多位读者借阅（同一时间一本书只能借给一位读者）； 借阅记录记录了哪本书借给了哪位读者以及借阅日期。

分析与结果：

类	关系	关系类型	多重性
图书类别 ↔ 图书	整体与部分	聚合	1 ↔ 0..*
借阅记录 ↔ 图书	业务联系	关联	* ↔ 1
借阅记录 ↔ 读者	业务联系	关联	* ↔ 1

多重性要点：

• 一本书属于一个类别（一对多）
• 一本书同一时间只能借给一位读者（多条借阅记录 → 1 本书，但当前借阅记录唯一）
• 多重性要标在靠近对方类的位置。

本章重点速记

• 类图描述系统静态结构
• 类由类名、属性和操作组成
• 临时使用：依赖
• 稳定联系：关联
• 空心菱形：聚合
• 实心菱形：组合
• 空心三角箭头指向父类
• 类图关系必须标注多重性
• 必考题型：给一段文字描述，要求抽取类、关系和多重性

第七章 动态模型

1. 时序图

时序图描述参与者和对象之间按照时间先后发送消息的过程。

主要回答：

谁在什么时候调用了谁。

时间方向是从上到下。

时序图的组成

元素	含义
参与者	发起系统交互的外部角色
对象	参与完成业务的系统对象
生命线	对象在交互过程中的存在时间
激活条	对象正在执行操作
消息	对象之间的调用
返回消息	操作完成后返回结果

常见消息

类型	含义
同步消息	发送者等待接收者处理完成
异步消息	发送后可以继续执行其他操作
返回消息	接收者返回处理结果

绘图时先确定参与者和对象，再按照实际业务顺序从上到下画出消息。

2. 活动图

活动图描述一个业务过程中的活动、判断、分支和并行流程。

适合描述：

• 用户注册流程
• 订单处理流程
• 审批流程
• 选课流程

元素	作用
初始节点	流程开始
活动节点	执行一项活动
控制流	表示活动顺序
判断节点	根据条件选择分支
合并节点	将多个分支重新合并
分叉与汇合	表示并行任务的开始与结束
终止节点	流程结束
泳道	区分不同角色负责的活动

3. 状态图

状态图描述一个对象在不同事件作用下，状态如何发生变化。

例如订单：

待支付 → 已支付 → 已发货 → 已完成

也可能：

待支付 → 已取消

状态图包括：

• 初始状态
• 状态
• 事件
• 状态转移
• 条件
• 动作
• 终止状态

状态转移的一般形式：

事件 [条件] / 动作

例如：

点击支付 [余额充足] / 扣除金额

状态内部的 3 种动作

动作	含义	写法
entry 动作	进入该状态时自动执行	entry / 发送邮件通知
do 动作	处于该状态期间持续执行	do / 处理订单
exit 动作	离开该状态时自动执行	exit / 保存日志

例：订单进入"已支付"状态时立即发送邮件通知。 写法：entry / 发送邮件通知，属于 entry 动作。

4. 三种动态图的区别

题目关注内容	应使用的图
对象之间按时间发送消息	时序图
完整业务步骤、判断和并行流程	活动图
一个对象经历的状态变化	状态图

本章重点速记

• 时序图：谁在什么时候调用谁
• 时序图时间方向：从上到下
• 活动图：业务步骤、判断、分支和并行
• 泳道区分不同角色负责的活动
• 状态图：一个对象的状态变化
• 状态转换：事件 [条件] / 动作
• 状态内部动作：entry（进入）、do（持续）、exit（离开）
• 流程题用活动图，状态变化题用状态图

第八章 软件设计与实现

1. 软件设计

软件设计是将软件需求转换为可以实现的软件结构和技术方案。

阶段	回答的问题
需求分析	软件做什么
软件设计	软件怎样做
软件实现	把设计转化为可运行系统

2. 概要设计与详细设计

类型	主要内容
概要设计	系统总体架构、模块划分、模块关系和主要接口
详细设计	模块内部逻辑、数据结构、算法和接口细节

概要设计关注系统整体，详细设计关注模块内部。

3. 软件设计原则

模块化

将复杂系统划分为若干职责相对独立的模块。

抽象

保留事物的主要特征，忽略暂时不重要的实现细节。

信息隐藏

隐藏模块内部实现，只向外提供必要接口。

内聚

内聚表示一个模块内部各部分联系的紧密程度。

内聚越高，模块职责越集中。

耦合

耦合表示不同模块之间依赖的紧密程度。

耦合越低，模块之间相互影响越小。

软件设计的重要原则：

高内聚、低耦合。

4. 设计模型的质量要求

要求	含义
正确性	正确反映需求
完整性	不遗漏必要功能和结构
一致性	不同设计图和文档之间没有矛盾
清晰性	表达明确，便于理解
可追踪性	设计元素能够对应具体需求

5. 用户界面设计

用户界面应做到：

• 界面和操作保持一致
• 信息表达清楚
• 操作后及时反馈
• 减少用户记忆负担
• 防止或提示用户错误
• 符合用户使用习惯

6. 软件设计文档

软件设计文档主要包括：

• 系统总体结构
• 模块划分和职责
• 类和对象设计
• 数据设计
• 接口设计
• 用户界面设计
• 异常处理

设计文档应与需求保持一致，并能够指导后续实现。

7. 软件实现

软件实现是将软件设计转化为可以运行的软件系统。

前期成果	对实现的指导
需求规格说明书	确定功能和质量要求
用例图	确定参与者和功能入口
类图	确定类、属性、操作和关系
时序图	确定对象之间的调用顺序
活动图	确定业务流程和分支
状态图	确定对象状态及转换条件

一个完整功能通常按照以下过程运行：

用户界面接收操作 → 业务逻辑处理 → 读取或修改数据 → 返回处理结果

多人共同实现系统时，需要统一模块职责、接口参数和数据格式。

本章重点速记

• 需求分析：做什么
• 软件设计：怎样做
• 软件实现：做出来
• 概要设计关注整体，详细设计关注模块内部
• 设计原则：模块化、抽象、信息隐藏
• 核心要求：高内聚、低耦合
• 设计模型应正确、完整、一致、清晰、可追踪
• 软件实现必须以需求和设计模型为依据

第九章 软件测试

1. 软件测试

软件测试是为了发现软件中的错误和缺陷，并验证软件是否满足规定需求而执行软件的过程。

测试的主要目的：

尽可能发现软件中的错误。

经典结论：

软件测试可以发现软件中存在错误，但不能证明软件中不存在错误。

测试没有发现错误，也不能说明软件完全正确。

2. 测试与调试

软件测试	程序调试
目的是发现错误	目的是定位和修复错误
设计并执行测试用例	分析错误产生的原因
比较实际结果与预期结果	修改程序并重新验证

软件测试不等于程序调试。

3. 软件测试阶段

基本顺序：

单元测试 → 集成测试 → 系统测试 → 验收测试

阶段	主要测试对象
单元测试	单个函数、类或模块
集成测试	模块之间的接口和协作
系统测试	完整的软件系统
验收测试	用户确认软件是否可以交付

4. 黑盒测试与白盒测试

黑盒测试

黑盒测试根据需求、输入和输出进行测试，不关心程序内部结构。

主要检查：

• 功能是否正确
• 输入能否得到正确输出
• 边界输入能否正确处理
• 错误输入是否得到合理提示

常见方法：

• 等价类划分
• 边界值分析
• 决策表
• 场景法

白盒测试

白盒测试根据程序内部结构和逻辑进行测试。

主要检查：

• 语句是否执行
• 分支是否覆盖
• 条件是否覆盖
• 程序路径是否正确

黑盒测试和白盒测试是测试方法，不是软件测试阶段。

5. 等价类与边界值

例如，年龄要求为18至60岁：

等价类	数据
有效等价类	18至60
无效等价类	小于18
无效等价类	大于60
无效等价类	非数字

边界值可以选择：

17、18、19、59、60、61

6. 测试用例

测试用例是为验证某项需求或发现某类错误而设计的一组测试条件、输入、操作步骤和预期结果。

测试用例不等于一个功能。

内容	说明
用例编号	测试用例的唯一编号
测试目标	需要验证的功能或需求
前置条件	执行测试前需要满足的条件
输入数据	测试使用的数据
操作步骤	测试执行过程
预期结果	正确情况下应出现的结果
实际结果	实际执行得到的结果
测试结论	通过或失败

编写过程：

1. 明确对应的需求。
2. 确定前置条件和输入。
3. 写出清晰的操作步骤。
4. 写出可以判断的预期结果。
5. 执行后记录实际结果和结论。

7. 需求跟踪

需求跟踪用于建立以下对应关系：

需求 → 设计 → 代码 → 测试用例 → 测试结果

主要作用：

• 检查每条需求是否被设计
• 检查每条需求是否被实现
• 检查每条需求是否有对应测试
• 分析需求变更的影响

需求跟踪表不是用来查看项目目前进行到哪个阶段。

8. 软件测试报告

软件测试完成后，应形成软件测试报告。

主要记录：

• 测试范围和环境
• 测试用例
• 测试执行结果
• 发现的问题
• 测试结论

软件测试最终形成的主要产物是软件测试报告。

本章重点速记

• 测试目的：尽可能发现错误
• 测试不能证明软件没有错误
• 测试负责发现，调试负责定位和修复
• 测试顺序：单元 → 集成 → 系统 → 验收
• 黑盒看输入输出，白盒看内部结构
• 黑盒和白盒是测试方法，不是测试阶段
• 测试用例必须有输入、步骤和预期结果
• 需求跟踪连接需求、设计、代码和测试
• 软件测试最终形成测试报告