ChoChoX/obsidian

Fork 0

Files

ChoChoX 9a3d58dd3b vault backup: 2026-06-13 20:13:56

2026-06-13 20:13:56 +08:00

16 KiB

Raw Permalink Blame History

期末重要知识点速记

课程：软件需求分析与设计 | 总分：选择30 + 填空15 + 解答25 + 案例30 = 100分 成绩构成：平时40% + 期末60%（平时作业和实验截止前还可补交）

🎯 一、试卷结构与分值分布

1.1 题型总览

题型	数量	分值	说明
选择题	15题 × 2分	30分	重点刷教材课后有答案的题目
填空题	15空 × 1分	15分	各章基本概念和理论知识
解答题	5题 × 5分	25分	⚠️ 只考读图分析，不考画图
案例大题	2~3题	30分	⚠️ 给出需求描述，动手画图

1.2 各章分值权重（按比例分配复习时间！）

章节	分值	权重	复习优先级
需求管理	13分	★★★★	选择填空为主，含一道解答简答题
用例图	22分	★★★★★	读图分析 + 画图大题必考
类图	23分	★★★★★	读图分析 + 画图大题必考
顺序图与协作图	19分	★★★★★	读图分析 + 画图大题必考
状态图与活动图	14分	★★★★	读图分析 + 选考画图
组件图与部署图	7分	★★	⚠️ 仅出选择题和填空题
RUP统一过程	2分	★	⚠️ 仅出1个选择或填空

📋 二、解答题 5 道详细拆解

第1题：用例图分析（5分）

考点：给一幅用例图，分析：

参与者之间是什么关系？（泛化关系）
用例之间的关系（包含 <<include>> / 扩展 <<extend>> / 泛化）
识别参与者类型、用例描述要素

第2题：类图分析（5分）

考点：给一幅类图，分析：

类之间的关系类型（依赖、关联、聚合、组合、泛化、实现）
识别类的类型（边界类/控制类/实体类）
多重性含义

第3题：交互图分析（5分）

考点：给时序图（顺序图）或协作图，分析：

消息类型（同步调用/异步/返回/简单消息）
消息传递流程
可能要求：协作图 ↔ 时序图互转

第4题：活动图或状态图分析（5分）

考点：给活动图或状态图，分析流程/状态转移

第5题：简答题（5分）—— 四选一，必考一道！

⚠️ 老师明确给了四道范围，现在就背！

Q1：需求的层次有哪些并简述

答案：

业务需求（最高层）
  → 用户需求（中间层）
    → 系统需求（底层）
        ├── 功能需求：系统必须提供的功能
        ├── 非功能需求：性能、可靠性、安全性等质量属性
        └── 领域需求：特定行业领域的规则和约束

业务需求：组织或客户的高层目标，回答"为什么要做这个系统"
用户需求：用户使用系统要完成的任务，从用户视角描述
系统需求：详细描述系统必须做什么，包括功能和非功能需求

Q2：如何判定优秀需求的特性

答案（7大特性）：

完整性：需求描述完整无遗漏
正确性：真实反映用户需要
无歧义性：不同人读理解一致
可行性：技术和资源上可实现
有优先级：明确需求的轻重缓急
必要性：是必须的，不是"锦上添花"
可验证性：能通过测试验证需求是否被满足

Q3：需求发生变更时的管理流程

答案：

提出变更请求 → 初步分析评估 → CCB（变更控制委员会）评审决策
  → 批准后更新需求文档 → 通知所有受影响的相关方
    → 调整项目计划和开发任务 → 执行变更 → 验证变更结果

关键点：CCB 评审是核心环节，决定变更是否接受；变更后必须重新确认需求。

Q4：需求管理应包含的内容

答案（三个核心模块）：

模块	内容
需求确认	需求评审 → 获得承诺 → 建立需求基线
需求跟踪	建立 RTM（需求跟踪矩阵），正向跟踪（需求→设计→代码→测试）和逆向跟踪
需求变更控制	变更申请 → 变更审批 → 执行更改 → 重新确认

🔑 三、各章核心考点速记

需求管理 ★★★★★（约13分）

需求三层金字塔：

业务需求（老板视角：为什么要做）
  → 用户需求（用户视角：能干什么）
    → 系统需求 = 功能需求 + 非功能需求 + 领域需求

概念	一句话
业务需求	组织的高层目标
用户需求	用户使用系统完成的任务
功能需求	系统必须提供的功能
非功能需求	性能/可靠性/安全性等质量属性
领域需求	特定行业规则的约束

需求工程 = 需求开发 + 需求管理：

开发：获取 → 分析 → 定义（规格说明）
管理：验证 → 跟踪 → 变更控制

六大获取/验证技术：

联合分析小组（JAD）
用户访谈
问卷调查
观察工作流程
原型法
文档分析

📝 填空重点：需求三层 = 业务/用户/系统；获取技术6种；优秀需求7特性；需求变更流程步骤

用例图 ★★★★★（约22分，含大题）

四要素：参与者(火柴人) + 用例(椭圆) + 系统边界(方框) + 关联(连线)

三种关系对比（必考！）：

关系	UML标记	箭头方向	执行时机
包含 `<<include>>`	虚线+箭头	基本 → 包含	必然执行
扩展 `<<extend>>`	虚线+箭头	扩展 → 基本	条件触发时才执行
泛化	实线+空心三角	子 → 父	可单独执行

记忆：包含箭头指向被包含的（基→含），扩展箭头指向被扩展的（扩→基）

参与者三类型：人、外部系统、外部设备

用例描述6要素：用例名、参与者、前置条件、后置条件、主事件流、子事件流（备选流）

📝 重点：三种关系的箭头方向和区别、用例描述要素

类图 ★★★★★（约23分，含大题）

六大关系速判口诀：

关系	UML符号	口诀
依赖	虚线箭头 `---->`	"方法参数用了你"
关联	实线 `——`	"属性里放了你"
聚合	空心菱形 `◇——`	"整体-部分，部分可独立存活"
组合	实心菱形 `◆——`	"整体-部分，同生共死"
泛化	空心三角 `——▷`	"一般-特殊 / 父-子继承"
实现	虚线空心三角 `----▷`	"接口-实现类"

多重性速记：1 恰好1 | 0..1 可选 | */0..* 零到多个 | 1..* 至少1个

类三要素：名称、属性、操作 | 可见性：+public -private #protected

MVC版型（分析类三类型）：

<<boundary>> 边界类：与外部交互的界面
<<control>> 控制类：业务逻辑处理
<<entity>> 实体类：持久化数据

聚合 vs 组合：聚合整体端多重性可为*；组合整体端多重性必须=1

📝 选择高频：类间关系判断、多重性含义、版型识别、关联 vs 依赖

顺序图与协作图 ★★★★★（约19分，含大题）

顺序图核心元素：对象(矩形+下划线) + 生命线(虚线) + 控制焦点(矩形条) + 消息(箭头)

四种消息类型：

类型	箭头	特点
调用消息（同步）	实心箭头 →	发送后等待返回
异步消息	开放箭头 →	发送后不等待，继续执行
返回消息	虚线箭头 ⇢	返回值
简单消息	普通箭头	不区分同步/异步

消息编号嵌套规则：1 → 1.1 → 1.1.1（子消息必须在父消息完成前完成）

协作图 = 顺序图的另一种视角：

顺序图强调时间顺序（生命线+控制焦点）
协作图强调空间关系（对象间的链+消息序号）
两者可以互相转换

⚠️ 画图大题画顺序图的硬性要求：

不能画得太简单！必须完整区分并画出：

边界类（界面层，接收用户输入）

控制类（业务逻辑层，协调处理）

实体类（数据层，数据存取）

三个层次的对象之间的详细交互都要体现！

主动对象 vs 被动对象：主动对象拥有进程/线程可主动发起消息；被动对象须被消息触发

📝 重点：四种消息类型区分、消息编号规则、顺序图与协作图的区别、三层次交互画法

状态图与活动图 ★★★★（约14分）

状态图（管一个对象的状态变化）：

元素	符号
状态	圆角矩形（简单/复合/子状态）
转移	箭头：`事件[条件]/动作`
初始状态	● 实心圆
终态	⊙ 圆圈+实心圆
历史状态	Hⓗ 圆圈+H
并发	同步并发转移符号（粗线分叉）

四种事件类型：调用事件、信号事件、变化事件、时间事件

活动图（管多对象参与的流程）：

元素	符号	用途
活动	圆角矩形	流程步骤
分支	◇ 菱形	条件选择（只走一条）
分叉/汇合	≡ 粗横线	并发执行（多条同时走）
泳道	纵向分区	按职责/参与者分组
对象流	虚线箭头	数据传输/传递

⚠️ 核心区分：

状态图 → 一个对象的状态变化
活动图 → 多个对象参与的流程
分支 → 单路条件选一
分叉 → 多路并发
活动图的状态转移不需要事件触发，上一个活动完成自动进入下一个

📝 选择高频：状态图vs活动图区分、分支vs分叉、泳道功能

组件图与部署图 ★★（约7分，仅选填）

组件图 = 代码层面：

三种组件：源代码组件、二进制代码组件、可执行代码组件
正向工程：类图→代码 | 逆向工程：代码→类图

部署图 = 硬件层面：

结点（3D立方体）分两种：处理器(有计算能力) / 设备(无计算能力)
结点可驻留组件实例

📝 填空重点：组件3种类型；两种物理图名称

包图 ★★（选择题）

四大包设计原则：

缩写	原则	一句话
REP	重用等价原则	一起复用的放一起
CCP	共同闭包原则	一起改的放一起
CRP	共同重用原则	不一起用的分开
ADP	非循环依赖原则	包间不能环状依赖

RUP统一软件开发过程 ★（约2分，仅1个选填）

RUP三维特点：用例驱动 + 以体系结构为中心 + 迭代和增量

⚠️ 四阶段顺序（易错！）：

初始(Inception) → 细化(Elaboration) → 构造(Construction) → 移交(Transition)

❌ 不是"初始→构造→细化→移交"！

9个核心工作流 = 6过程 + 3支持：

6过程：业务建模、需求、分析与设计、实现、测试、部署
3支持：配置管理、项目管理、环境

六大最佳实践：迭代增量开发、管理需求、基于构件架构、可视化建模、持续质量验证、控制变更

RUP的4W：角色(Who) + 活动(How) + 制品(What) + 工作流(When)

📝 选择/填空：RUP三大特点、四阶段顺序、九个工作流、六大最佳实践

⚠️ 四、高频易错易混点

易混概念	区分
包含 vs 扩展	包含箭头基→含（必然执行）；扩展箭头扩→基（条件执行）
聚合 vs 组合	聚合空心◇（部分可独立）；组合实心◆（同生共死）
关联 vs 依赖	关联=属性里放了；依赖=方法参数用了
泛化 vs 实现	泛化=父类-子类继承；实现=接口-实现类
调用消息 vs 异步消息	调用=同步等待返回；异步=发出后继续
状态图 vs 活动图	状态图=一个对象；活动图=多个对象
分支 vs 分叉	分支◇=单选一路；分叉≡=多路并发
功能需求 vs 非功能需求	功能=做什么；非功能=做多好
RUP四阶段顺序	初始→细化→构造→移交（别写反细化/构造！）
顺序图 vs 协作图	顺序图强调时间；协作图强调空间

🛠️ 五、案例大题画图模板

⚠️ 不考的图

组件图、包图、部署图 — 案例大题明确不考！

1. 用例图（必考）

4步法：

找参与者：从文字中找名词——人、外部系统、设备
找用例：动宾短语（用户能做的操作）
画包含：A 必然触发 B → A ---<<include>>--→ B
画扩展：条件触发 C 插入 A → C ---<<extend>>--→ A

2. 类图（必考，尤其实体类图）