S04 · 面向对象分析与 UML 建模

第 4 周｜主打科目：案例分析 + 综合知识｜对应知识域：系统分析与设计（OOA/OOD、UML）、软件工程｜主打基本问题：Q1（换一种语言再问一遍：需求真的被说清了吗？）｜本阶段产出：用例图 + 领域类图 + 关键时序图

项目宪法见 00-课程总纲.md；UML 与建模在综合知识中占比 18–22%，是权重最高的单一模块，见 02-考点地图.md。

一、情境开场（Hook）

你把 S03 画好的那套 DFD 交给 CIO，他翻了两页，问了一个让你当场语塞的问题：**”这图上说’生成追溯报告’，那追溯报告里到底有什么？”**

你说：”批次号、工序、检验值、设备参数、操作班组。”

他接着问：”那如果客户问’这批货用的是哪家供应商的钢’，你的报告里有吗？”你翻图——图上确实没有原材料供应商这一支数据流。你临时补一句：”这个可以加。”CIO 摇摇头：”我不是要你加一条线。我是问：你这张图上，’批次’到底是什么东西？它和’工单’什么关系？和’检验记录’呢？和’设备’呢？ 如果这些关系你现在说不清，加了供应商那条线，你下次还是会漏。”

那一刻你明白了：DFD 擅长回答”数据怎么流动”，却不擅长回答”世界是由什么构成的”。 数据流图画得再规范，也只是把流程画清楚了；而”批次”这个概念本身——它由哪些部分组成、和别的概念什么关系、有哪些行为——在 DFD 里是看不见的。

更棘手的是第三个问题。CIO 说：”生产部报工和质量部检验，这两个动作都能改’批次’的状态。谁有权改？改到一半系统崩了算谁的？ 你的图上完全没有’规则’这个东西。”

于是本周的问题是：如果同一件事既可以用”数据怎么流动”来描述，也可以用”谁是什么、谁对谁做了什么”来描述，第二种描述方式到底多给了你什么？ 答案是：它给了你结构——而结构能告诉你有哪些东西还没被考虑到。当 CIO 问”供应商在哪”的时候，一张合格的领域类图应当已经把”批次—物料—供应商”这条链画在那里了。

二、为什么学这一周（Where & Why）

1. UML 14 种图的分类与用途：综合知识每年 3–5 题，最稳定的送分点。核心陷阱是”结构图 vs 行为图”的归属，以及包图、部署图、组件图各自的辨识特征。
2. 用例图三种关系（include / extend / generalization）：综合知识 2–4 题，案例第 1 题”补用例图”必考。include 与 extend 的箭头方向是软考史上最经典的易错点，几乎年年有人栽。
3. 类图六种关系与多重度：综合知识 3–5 题，案例”补类图、标注关系与多重度”约 8–12 分。聚合 vs 组合每年必考，判定口诀必须背死。
4. 时序图的元素与组合片段：综合知识 2–3 题；案例常要求”补全时序图中的消息”或”指出消息类型（同步/异步）”。
5. 活动图与状态图的区别：综合知识 1–2 题，且是案例”应选哪一种图描述某流程”的固定问法；区分点是关注状态还是关注活动。
6. 用例规约的结构：案例”补充前置条件/备选流/异常流”约 6–8 分；它是把 S02 的 RTM 与 S04 的模型连起来的关键桥梁。

三、核心讲义（Equip）

3.1 面向对象的基本概念

定义：面向对象（Object-Oriented, OO）方法把系统看作一组对象的集合，对象通过消息交互完成功能。

概念	定义	本项目例子
对象（Object）	具有状态（属性）、行为（方法）与标识的实体，是类的实例	“批次 B20260315-07”这个具体批次
类（Class）	具有相同属性与行为的一组对象的抽象	批次 Batch 类
封装（Encapsulation）	隐藏内部实现细节，仅通过公开接口访问	外部只能调 batch.追溯()，不能直接改内部链表
继承 / 泛化（Generalization）	子类自动获得父类属性与方法，并可扩展或覆盖	检验记录 ← 尺寸检验记录、热处理检验记录
多态（Polymorphism）	同一消息作用于不同对象产生不同行为	对不同类型检验记录调 判定()，各执行不同规则
消息（Message）	对象之间交互的请求，是方法调用的抽象	追溯服务.查询(批次号)
接口（Interface）	一组操作的声明，不含实现，描述”能做什么”	可追溯接口 ITraceable
抽象（Abstraction）	抽取本质特征、忽略非本质细节	忽略”哪个厂区的批次”，只保留批次共同属性
重载 / 覆盖	重载：方法名同而参数不同（编译时多态）；覆盖：子类重定义父类虚方法（运行时多态）	查询(批次号) 与 查询(批次号, 深度)；热处理检验记录.判定() 覆盖父类实现

为什么需要它：这些概念是 UML 的语义基础。考题常辨析”多态”与”重载/覆盖”——多态强调”同一消息、不同行为”，重载是编译期静态绑定，覆盖是运行期动态绑定。**问”运行时多态通过什么实现” → 答”覆盖（动态绑定）”**。

真题级短例子：”系统设计了 图形 父类，圆形、矩形 子类各自实现 绘制()；运行时根据对象实际类型调用对应的 绘制()。这体现了（　　）” → 多态（通过覆盖实现的运行时多态）。

3.2 UML 的 14 种图：结构图与行为图

定义：统一建模语言（Unified Modeling Language, UML）是面向对象分析与设计的标准建模语言。UML 2.x 共 14 种图，分结构图（静态）7 种与行为图（动态）7 种。

分类	图名	用途	本项目落点
结构图	类图（Class）	类、接口及其关系	领域模型：批次、工单、检验记录、设备
	对象图（Object）	某一时刻对象及其链接的快照	说明某批次的实例关系
	包图（Package）	模型元素的分组与依赖关系	子系统划分（生产/质量/设备/基础）
	组件图（Component）	软件组件及其接口与依赖	采集服务、追溯服务的组件划分
	部署图（Deployment）	软硬件物理拓扑、节点与构件部署	3 厂区 + 边缘网关 + 中心机房
	组合结构图 / 制品图	类或组件的内部结构 / 物理文件（jar、dll、脚本）	采集服务内部结构 / 部署包清单
行为图	用例图（Use Case）	系统功能需求与参与者	一期范围的功能视图
	活动图（Activity）	活动的流程、并发与职责（泳道）	检验流程、不合格品处理流程
	状态图（State Machine）	对象状态在事件驱动下的变化	工单状态、批次状态
	时序图 / 顺序图（Sequence）	对象之间按时间顺序的消息交互	批次追溯查询的调用链
	通信图 / 协作图（Communication）	对象之间的链接与消息（强调结构）	同上，但强调对象拓扑
	交互概览图（Interaction Overview）	用活动图形式组织多个交互	复杂流程的交互总览
	定时图（Timing）	状态随时间与时间约束的变化	实时采集的时序约束

记忆方法：结构图 7 种口诀”类对包，组部制“（类、对象、包、组合结构、组件、部署、制品）；行为图 7 种 = 用例 + 活动 + 状态 + 4 种交互图（时序、通信、交互概览、定时）。判据：问”谁是什么、谁连谁” → 结构图；问”怎么动、按什么顺序动” → 行为图。用例图属于行为图（这是最常见的归属误判）。时序图与通信图语义等价可互换，时序图强调时间顺序，通信图强调对象结构。

3.3 用例图：参与者、用例与三种关系

定义：用例图（Use Case Diagram）从用户视角描述系统的功能需求，是需求阶段的”功能清单视图”。

三个基本元素：参与者（Actor）——系统之外与系统交互的人、组织或其他系统（小人符号），一定在系统边界之外；用例（Use Case）——系统为参与者提供的一个完整功能单元（椭圆），必须有可观测的价值结果；关系——关联（参与者与用例之间，实线）、include、extend、泛化。

三种关系（本节是全场最高频易错点）：

关系	表示法	箭头方向	语义	关键判定
包含 include	虚线 + «include»	基用例 → 被包含用例	被包含用例是基用例必然执行的一部分，用于抽取多个用例的公共行为	无条件、必须发生；基用例”不完整”，缺了被包含用例就不成立
扩展 extend	虚线 + «extend»	扩展用例 → 基用例（箭头指回基用例）	基用例在扩展点上，满足条件时才插入扩展用例	有条件、可选发生；基用例”独立完整”，去掉扩展照样成立
泛化 generalization	实线 + 空心三角	子用例 → 父用例（用例之间、参与者之间均可）	子用例继承父用例行为并可特化	is-a 关系

箭头方向的统一记忆法：箭头始终指向”被依赖”的一方——include 中基用例依赖被包含用例，箭头从基指向被包含；extend 中扩展用例依赖基用例，箭头从扩展指向基。

语义判定问句（做题时套）：① 把这条关系去掉，基用例还完整吗？不完整 → include；完整 → extend。 ② 每次都发生还是满足条件才发生？每次 → include；条件 → extend。 ③ 是否用于多个基用例的公共行为复用？是 → include。

真题级短例子：”用户登录“与”查询追溯报告“——查询每次都必须先登录 → 查询追溯报告 --«include»--> 用户登录（箭头指向用户登录）；”导出 PDF 报告“与”查询追溯报告“——查询本身完整，只有点击导出时才发生 → 导出PDF报告 --«extend»--> 查询追溯报告（箭头指回查询追溯报告）。

用例规约（Use Case Specification）——用例图只画”有哪些功能”，用例规约写”这个功能怎么走”：

组成项	内容	本项目”批次追溯查询”示例
用例名 / 编号	唯一标识	UC-07 批次追溯查询
参与者	主参与者、辅助参与者	质检员（主）、质量监管平台（辅）
前置条件	执行前必须为真的条件	质检员已登录；批次号存在于批次档案中
后置条件	执行后保证为真的条件	已记录本次查询至审计日志；批次状态未改变
基本流	主成功场景，逐步骤编号	1 输入批次号 → 2 校验存在 → 3 检索链条 → 4 展示报告
备选流	常见分支，可回到基本流	3a. 用户选择仅看关键工序 → 过滤后回到步骤 4
异常流	出错处理	2a. 批次不存在 → 提示并结束；4a. 检索超时 → 建议缩小深度
特殊需求 / 扩展点	相关非功能需求；可被 extend 的位置	检索 ≤ 3 秒；报告带数字签名防篡改；扩展点在步骤 4 之后（导出 PDF）

3.4 类图：六种关系与多重度

定义：类图（Class Diagram）描述系统中类、接口及其静态关系，是面向对象建模的核心，也是领域模型的表达形式。

类的三层表示法：类名 / 属性（可见性 名称:类型 = 默认值）/ 方法（可见性 名称(参数):返回类型）。可见性：+ public、- private、# protected、~ package；静态成员加下划线。

六种关系（按耦合强度由低到高）：

关系	表示法	语义	本项目例子
依赖（Dependency）	虚线 + 开放箭头	一个类变化影响另一个，临时使用（局部变量、参数、返回值），耦合最弱	追溯服务 --> 批次（作方法参数）
关联（Association）	实线（可带导航箭头、角色名、多重度）	对象之间长期的结构化引用	质检员 —— 检验记录
聚合（Aggregation）	实线 + 空心菱形（菱形在整体端）	整体—部分，has-a；部分可脱离整体独立存在	批次 ◇—— 检验记录
组合（Composition）	实线 + 实心菱形（菱形在整体端）	整体—部分，contains-a；部分与整体同生共死且独占	追溯报告 ◆—— 追溯节点
实现（Realization）	虚线 + 空心三角（指向接口）	类实现接口	检验记录 ..▷ ITraceable
泛化（Generalization）	实线 + 空心三角（指向父类）	is-a，继承，耦合最强	检验记录 ◁—— 尺寸检验记录

聚合 vs 组合的判定口诀（必背，年年考）：① 问”整体没了，部分还在吗？“——在 → 聚合（空心菱形）；不在 → 组合（实心菱形）；② 问”部分能同时属于多个整体吗？“——能 → 聚合；不能（独占）→ 组合。

例子：公司 ◇—— 员工 是聚合（公司解散员工还在，员工可换公司）；订单 ◆—— 订单明细 是组合（订单删除明细必删，明细只属一个订单）；批次 ◇—— 检验记录——这是本项目最易判错的一处：检验记录虽有”属于批次”的语义，但它有独立的业务价值与法定存档要求（批次档案归档后仍须保留），故判为聚合更稳妥。判定必须结合业务语义，不能只看”是不是一部分”。

多重度（Multiplicity）：1 恰好一个；0..1 零或一个（可选）；0..* 或 * 零或多个；1..* 一个或多个；m..n m 到 n 个。
本项目一组多重度（照此核对）：批次 1 —— 1..* 报工记录；批次 1 —— 0..* 检验记录（可尚未检验）；工单 1 —— 1..* 批次；设备 1 —— 0..* 报工记录；追溯报告 1 —— 1..* 追溯节点。

判定步骤（案例”标注类之间的关系”）：① 是”结构关系”还是”临时使用”——临时用虚线箭头（依赖）；② 若是结构关系，是不是 is-a——是则泛化；③ 是不是整体—部分——是则用生命周期口诀分聚合/组合；④ 都不是 → 关联；⑤ 标两端多重度，双向各问一次“这边 1 个对应那边几个”。

3.5 时序图：生命线、消息与组合片段

定义：时序图 / 顺序图（Sequence Diagram）按时间先后顺序描述对象之间的消息交互。

元素：生命线（Lifeline）——对象下方的垂直虚线，表示对象在一段时间内的存在；激活 / 控制焦点（Activation）——生命线上的窄长矩形，表示执行操作的时间段；消息——生命线之间的有向连线，自上而下代表时间递增。

消息类型	表示法	语义
同步消息	实线 + 实心三角箭头	发送者等待接收者处理完并返回（阻塞）
异步消息	实线 + 开放（V 形）箭头	发送者发出后继续，不等待（非阻塞）
返回消息	虚线 + 开放箭头	返回控制权与结果（可省略）
自身消息	指向自身的弧线	对象调用自己的方法
创建 / 销毁	«create» 指向头部 / «destroy» 指向末端 ×	创建或销毁对象

组合片段（Combined Fragment）——大框框住一段交互，左上角标类型：alt 多选一（分支，内部虚线分区，每区带监护条件 [条件]，有且仅有一个区域执行）；opt 可选（单分支，相当于 if 无 else）；loop 循环（可标 loop(1, n)）；par 并行（各区域并发）；break 中断；ref 引用另一张时序图。

判定步骤（案例”补全时序图消息”）：① 先看对象（生命线）是否齐全，缺少的对象往往是缺失的控制器或服务类；② 从上到下按时间轴读，每步问”谁发起、谁执行、是否需等待返回”；③ 需等待 → 同步消息，发起后不等 → 异步消息；④ 检查每个同步消息是否有对应返回、激活矩形是否自洽。

本项目骨架：质检员 → 追溯界面 → 追溯控制器 → 追溯服务 → 批次档案DAO → 数据库；”检索链条”若耗时较长，应设计为异步消息 + 回调，避免界面阻塞。

3.6 活动图、状态图与设计模式入门

活动图（Activity Diagram）：元素含起点（实心圆 ●）、终点（同心圆 ◎）、活动（圆角矩形）、判断/分支（菱形，带监护条件）、分叉与汇合（粗横线 Fork / Join，表示并发的开始与同步）、泳道（Swimlane）（按职责划分的竖向分区）。与程序流程图的三大区别：① 活动图支持并发（分叉/汇合），流程图只有单一控制流；② 活动图支持泳道，能表达”哪个角色/部门负责哪一步”；③ 活动图是面向对象的，可表达对象流。

状态图（State Machine Diagram）：元素含状态（圆角矩形）、初态（●）、终态（◎）、迁移（箭头，标注 事件[监护条件]/动作）。与活动图的核心区别（高频考点）：

维度	活动图	状态图
关注点	活动的流程（做什么、按什么顺序做）	对象的状态（处于什么状态、被什么事件改变）
主体	通常跨多个对象（泳道）	单个对象
驱动力	活动完成即流转	事件驱动
典型用途	业务流程建模、用例的实现流程	有明确生命周期的对象（订单、工单、批次、设备）

判定口诀：题目说”描述某个对象在其生命周期内的状态变化“ → 状态图；说”描述某个业务过程的活动步骤与并发“ → 活动图。本项目：批次状态（已创建 → 生产中 → 待检 → 合格/不合格 → 已入库/已报废）用状态图；不合格品处理流程（发现 → 隔离 → 评审 → 处置 → 记录）用活动图（跨质检、工艺、生产多部门，要用泳道）。

设计模式入门（点到为止，S07 详讲）：GoF 23 种模式分三类——创建型（工厂方法、抽象工厂、单例、建造者、原型）、结构型（适配器、装饰器、代理、外观、桥接、组合、享元）、行为型（策略、模板方法、观察者、责任链、命令、状态、迭代器、中介者、访问者、备忘录、解释器）。本周只要求记住分类与一两个典型名称，不要求会用。

四、典型考法

4.1 综合知识怎么考

题 1：下列关于 UML 图的说法，正确的是（　　）。　A. 用例图属于结构图　B. 部署图属于行为图　C. 时序图属于交互图，交互图是行为图的子集　D. 类图属于行为图
答案：C。解析：用例图属于行为图（A 错）；部署图属于结构图（B 错）；类图属于结构图（D 错）。交互图含时序图、通信图、交互概览图、定时图四种，是行为图的子集。

题 2：用例 A”查询追溯报告”执行时必须先执行用例 B”用户登录”；用例 C”导出 PDF 报告”仅在用户点击导出按钮时才执行。B 与 A、C 与 A 之间的关系分别是（　　）。　A. include、extend　B. extend、include　C. include、include　D. extend、extend
答案：A。解析：B 是 A 必然执行的一部分且去掉后 A 不完整 → A --«include»--> B；C 是条件性可选的，去掉 C 后 A 依然完整 → C --«extend»--> A。注意箭头方向相反：include 从基指向被包含，extend 从扩展指向基。

题 3：关于聚合与组合，下列说法正确的是（　　）。　A. 聚合关系中部分与整体生命周期相同　B. 组合关系中整体消失后部分仍可独立存在　C. 组合用实心菱形表示，菱形在整体一端，部分与整体同生共死　D. 聚合与组合语义完全相同，仅画法不同
答案：C。解析：组合 = 实心菱形 + 同生共死 + 独占；聚合 = 空心菱形 + 部分可独立 + 可共享。这是每年必考的镜像陷阱。

题 4：UML 时序图中，表示”发送消息后不等待返回、继续执行”的消息类型是（　　）。　A. 同步消息　B. 异步消息　C. 返回消息　D. 自身消息
答案：B。解析：同步消息（实线实心三角）会阻塞等待；异步消息（实线开放箭头）不等待；返回消息是虚线开放箭头；自身消息指向自身。

题 5：需描述”某订单对象从’已下单’’已支付’’已发货’到’已完成’的变化过程及触发变化的事件”，最适宜采用（　　）。　A. 活动图　B. 状态图　C. 时序图　D. 通信图
答案：B。解析：单个对象的状态变化 + 事件驱动 → 状态图。活动图关注跨对象的活动流程与并发；时序图关注对象间消息时序；通信图关注对象间链接结构。

4.2 案例分析怎么考

【案例题】（共 25 分）

承接本项目。系统分析师正在建立用例模型与领域模型，已知：参与者——操作工（报工）、质检员（检验与追溯查询）、生产部（下发工单、查看看板）、设备部（维护设备台账）、ERP 系统（接收入库信息）。已识别用例：UC-01 用户登录、UC-02 报工录入、UC-03 检验结果录入、UC-04 批次追溯查询、UC-05 不合格品处理、UC-06 设备台账维护、UC-07 生产看板查看。业务规则：① 所有用例执行前均需用户登录；② 在追溯查询结果界面，用户可选择”导出 PDF 报告”；③ 检验结果录入时若判定为不合格，必须走”不合格品处理”流程；④ 设备台账维护仅设备部有权限。已知领域类：批次 Batch、报工记录 WorkReport、检验记录 InspectRecord、追溯报告 TraceReport、追溯节点 TraceNode、设备 Equipment、工单 WorkOrder。

【问题 1】（9 分） 指出 UC-01 与 UC-04、”导出 PDF 报告”与 UC-04 之间分别是什么关系并画出箭头方向；说明 include 与 extend 在语义和箭头方向上的区别。
【问题 2】（8 分） 确定 追溯报告 与 追溯节点、批次 与 检验记录、批次 与 工单 三组类之间的关系类型，说明理由，并标注两端多重度。
【问题 3】（8 分） 编写”UC-04 批次追溯查询”的用例规约（含前置条件、后置条件、基本流、备选流、异常流），并说明用例规约与用例图的关系。

采分点拆解：问题 1——两组关系各 2 分（类型 1 + 箭头方向 1），语义区别 3 分，箭头方向区别 2 分，箭头方向画反则该组 0 分。问题 2——三组各 2 分（类型 1 + 理由 1），多重度 2 分（三组共六端，答对 4 处以上给满），只写关系不写理由扣一半。问题 3——前置条件 1 分、后置条件 1 分、基本流 2 分（步骤完整且编号）、备选流 2 分、异常流 1 分、二者关系 1 分。

标准作答范例

【问题 1】 ① UC-01 与 UC-04：关系为 «include»（包含），方向为 UC-04 批次追溯查询 --«include»--> UC-01 用户登录（从基用例指向被包含用例）。理由：业务规则①明确”所有用例执行前均需用户登录”，登录是查询必然执行的组成部分，去掉登录后查询用例不完整。② “导出 PDF 报告”与 UC-04：关系为 «extend»（扩展），方向为 导出 PDF 报告 --«extend»--> UC-04 批次追溯查询（从扩展用例指向基用例）。理由：业务规则②指出导出”仅在用户选择时才执行”，属条件性、可选行为；去掉后 UC-04 依然完整可用。③ 语义区别：include 表示被包含用例是基用例必然执行的一部分，常用于抽取多用例共享的公共行为，基用例离开被包含用例就不完整；extend 表示基用例在扩展点上满足条件时才插入扩展行为，基用例本身独立完整。箭头方向区别：include 由基指向被包含，extend 由扩展指向基，二者相反，可用”箭头始终指向被依赖方“统一记忆。判定方法：删掉该关系，基用例是否仍完整——不完整为 include，完整为 extend。

【问题 2】

类组	关系类型	理由	多重度
追溯报告—追溯节点	组合，实心菱形在报告端	节点是报告的构成单元，报告删除则节点必然一并删除；一个节点只属于一份报告，不可共享	追溯报告 1 —— 1..* 追溯节点
批次—检验记录	聚合，空心菱形在批次端	检验记录具有独立的业务价值与法定存档要求，批次档案归档后检验记录仍须保留并可独立查询；部分不随整体消亡	批次 1 —— 0..* 检验记录
批次—工单	关联	二者是长期的结构化引用，但不存在整体—部分的构成关系，也不是 is-a	工单 1 —— 1..* 批次

追溯报告 与 追溯节点 若误判为聚合，会丢失”节点随报告销毁”的语义；批次 与 检验记录 若误判为组合，则意味着批次删除后检验记录也被删除，违反质量追溯的存档要求。判定必须落到业务语义，不能只凭”是不是一部分”。

【问题 3】UC-04 批次追溯查询 —— 用例规约

• 参与者：质检员（主）；质量监管平台（辅助）。
• 前置条件：① 质检员已通过身份认证并登录系统；② 待查询批次号已存在于批次档案中。
• 后置条件：① 系统已展示该批次完整追溯链条；② 系统已将该次查询的批次号、操作人、时间、查询范围写入查询审计日志；③ 批次自身状态与数据未被本次查询修改。
• 基本流：1 质检员输入批次号并选择追溯方向（正向/反向/双向）与追溯深度；2 系统校验批次号是否存在；3 系统按方向与深度依次检索该批次关联的工单、报工记录、检验记录、设备参数与原材料信息；4 系统组装追溯链条，生成追溯报告（含各节点时间戳与数字签名）；5 系统展示追溯报告并将本次查询写入审计日志，用例结束。
• 备选流：3a 质检员选择”仅查看关键工序”，系统过滤非关键工序节点后继续步骤 4；3b 质检员选择”包含原材料供应商信息”，系统追加检索原材料与供应商数据后继续步骤 4；5a 质检员选择”导出 PDF 报告”（扩展用例），系统生成并下载 PDF 后返回步骤 5。
• 异常流：2a 批次号不存在或格式非法 → 系统提示并结束用例；3a’ 检索超时（超过 3 秒）→ 系统提示并建议缩小追溯深度后重试；3b’ 部分历史数据缺失（来自老 MES 或老设备的采集记录不完整）→ 系统在链条中显式标注”数据缺失”节点，不得静默省略，以保证追溯链条完整性可验证。
• 特殊需求：检索响应 ≤ 3 秒（峰值 300 并发下 99% 请求满足）；报告须带数字签名防篡改；审计日志保留不少于 3 年。

用例规约与用例图的关系：用例图是图形化的功能清单，只回答”系统有哪些功能、谁使用、功能间什么关系”；用例规约是文字化的功能细节，回答”这个功能怎么走、前置条件是什么、出错怎么办”。二者是同一用例的两种视图，缺一不可——只有图没有规约，开发人员无法设计与测试；只有规约没有图，干系人无法快速理解系统范围。用例图中 UC-04 --«include»--> 用户登录 这类关系，正是由用例规约的前置条件与基本流推导出来的。

五、易错点（Rethink）

错误认知	为什么错	正确理解
“用例图属于结构图”	它描述系统对外提供的行为	用例图属于行为图；结构图是类、对象、包、组件、部署等
“include 的箭头从被包含用例指向基用例”	方向记反，最高频失分点	include：基 → 被包含；extend：扩展 → 基；统一记忆：箭头指向被依赖方
“extend 的基用例必须知道扩展用例存在 / 用 include 表达可选附加功能”	恰恰相反：扩展的意义就是不侵入基用例；include 是必然执行	基用例独立完整；可选行为必须用 extend。判定问句：”去掉它基用例还完整吗？”
“聚合与组合只是菱形空心实心的区别 / 整体—部分一定画组合”	语义差异与生命周期被忽略	整体消失部分还在 → 聚合；同生共死且独占 → 组合；先问”部分能否脱离整体独立存在”
“多重度只需标一端”	关联是双向的	两端各问一次：”这边 1 个，对应那边几个？”
“时序图里所有消息都用实线实心三角 / alt 与 opt 分不清”	混淆同步异步与分支类型	同步 = 实线实心三角（阻塞）；异步 = 实线开放箭头；返回 = 虚线开放箭头；alt 多选一、opt 可选单分支
“活动图就是流程图”	忽略并发与泳道	活动图支持分叉/汇合（并发）与泳道（职责），流程图不支持
“状态图和活动图可以互换”	关注点不同	状态图 = 单个对象的状态 + 事件驱动；活动图 = 跨对象的活动流程 + 并发
“参与者一定是人”	参与者是系统外一切交互方	可以是人、组织、外部系统（如 ERP 系统、质量监管平台）
“用例就是功能点，越细越好”	用例须有完整价值结果	用例是能为参与者产生可观测价值的完整单元；把”点击按钮”当用例是典型错误

六、GRASPS 推进（Experience）

本周五前，往交付物「业务需求规格说明书」里加三块内容，总计 1200–1500 字 + 三张图：

1. 用例图一张：参与者不少于 6 个（操作工、质检员、生产部、设备部、ERP 系统、质量监管平台），至少 1 个是外部系统；用例不少于 12 个，编号 UC-01 起，与 S02 用例清单编号严格一致；至少 2 组 include + 2 组 extend，图下用文字逐一说明箭头方向与判定理由（各 1 句）。
2. 领域类图一张：不少于 8 个类（批次、报工记录、检验记录、追溯报告、追溯节点、设备、工单、物料）；至少用上 4 种关系（关联、聚合、组合、泛化各至少一处，聚合与组合必须各出现至少一次）；所有关系两端都标多重度；至少 1 个类实现 1 个接口（如 ITraceable）。
3. 关键时序图一张 + 2 份用例规约：时序图画”批次追溯查询”调用链，不少于 5 条生命线（界面、控制器、服务、DAO、数据库），至少 1 条异步消息和 1 个 loop 或 alt 组合片段；用例规约写 UC-04 批次追溯查询与 UC-05 不合格品处理各一份，每份含前置条件、后置条件、基本流（≥4 步）、备选流（≥1 条）、异常流（≥1 条）。

验收标准：用例图编号能与 S02 的 RTM 逐行对上，没有孤儿用例、也没有无图的需求；任一条 include 你都能说出”去掉它基用例就不完整”，任一条 extend 你都能说出”去掉它基用例照样能跑”；类图里每个聚合/组合都能答出生命周期口诀的两问；时序图上每个同步消息都有返回消息，激活矩形无悬空；把用例规约给质检员看，他能指出至少一处”这里不是我们这么做的”——能被业务方纠正的规约，才是活的规约。

七、自测

1. UML 中属于结构图的是（　　）。　A. 用例图　B. 活动图　C. 部署图　D. 时序图
2. UML 2.x 的交互图不包括（　　）。　A. 时序图　B. 通信图　C. 定时图　D. 状态图
3. 用例 A 必然执行用例 B，去掉 B 后 A 不完整，则 A 与 B 之间是（　　）。　A. «include»，箭头 A 指向 B　B. «include»，箭头 B 指向 A　C. «extend»，箭头 A 指向 B　D. «extend»，箭头 B 指向 A
4. 类图中，空心菱形表示（　　）。　A. 组合　B. 聚合　C. 依赖　D. 泛化
5. “订单”与”订单明细”之间最适宜的关系是（　　）。　A. 关联　B. 聚合　C. 组合　D. 依赖
6. 时序图中，虚线加开放箭头表示（　　）。　A. 同步消息　B. 异步消息　C. 返回消息　D. 创建消息
7. 时序图中，表示”满足条件时执行多个分支中的一个且仅一个”的组合片段是（　　）。　A. opt　B. alt　C. loop　D. par
8. 活动图中，用于表示并发开始的图形元素是（　　）。　A. 菱形　B. 粗横线（分叉）　C. 圆角矩形　D. 泳道
9. 描述”设备对象在运行、停机、检修、报废之间的状态变化”，宜采用（　　）。　A. 活动图　B. 状态图　C. 通信图　D. 包图
10. 关于参与者（Actor），正确的是（　　）。　A. 参与者只能是具体的人　B. 参与者一定位于系统边界之内　C. 参与者可以是与系统交互的外部系统　D. 一个用例只能有一个参与者

题号	1	2	3	4	5
答案	C	D	A	B	C
一句话解析	结构图含类、对象、包、组件、部署等；用例图/活动图/时序图均为行为图	交互图 4 种：时序、通信、交互概览、定时；状态图不属交互图	必然执行且去掉不完整 → include，箭头从基 A 指向被包含 B	空心菱形 = 聚合；实心菱形 = 组合；虚线箭头 = 依赖；实线空心三角 = 泛化	订单删除明细必删、明细独占 → 组合；关键在”同生共死 + 独占”

题号	6	7	8	9	10
答案	C	B	B	B	C
一句话解析	返回消息 = 虚线开放箭头；同步实线实心三角；异步实线开放箭头	alt 多选一（带监护条件）；opt 可选单分支；loop 循环；par 并行	分叉/汇合用粗横线表示并发开始与同步；菱形是判断分支	单个对象的状态变化 + 事件驱动 → 状态图	参与者可以是人、组织或外部系统；一定在系统边界之外

八、分档任务（Tailor）

• 保底 45：背熟 3.2 的 14 种图归属表（结构 7 / 行为 7，用例图归行为）、3.3 的 include/extend 箭头方向、3.4 的关系强度排序与聚合组合口诀；完成 4.1 五题与自测十题。
• 冲 60：完成 GRASPS 三图两规约；案例 4.2 的【问题 1】【问题 2】手写完整作答并对照采分点自评；把”去掉它基用例还完整吗”练成条件反射。
• 冲 70：把本项目换为医疗场景（患者/医生/护士/医保系统）重画用例图与类图；为”不合格品处理”画一张带 3 条泳道的活动图（质检、工艺、生产），与 S03 的状态图对照，用 200 字说明二者分工；自命题一道”补类图关系与多重度”的案例题并写出采分点。

九、本阶段回答基本问题

Q1（第三次追问）：换一种语言再问一遍——需求真的被说清了吗？

第一，DFD 描述”数据怎么流动”，类图描述”世界由什么构成”，二者不是重复，是互补校验。 同一个需求用两套语言各说一遍，说法对不上的地方就是需求漏洞——这正是 S04 不可替代的价值。CIO 问”供应商在哪”，DFD 答不上来，但一张合格的领域类图里，批次 — 物料 — 供应商 这条链早就该在那里。能被模型发现的需求漏洞，比被用户在验收时发现的便宜一百倍。

第二，面向对象给的不是”另一种画法”，而是”结构先于流程”的思考顺序。 结构化方法从流程出发，流程跑通就以为没问题；面向对象先问”有哪些概念、它们什么关系”，结构一立起来，没被考虑到的东西自己会暴露。本项目中”批次与检验记录”到底是聚合还是组合——这个看似画图细节的问题，逼你回答的其实是**”批次归档后检验记录还要不要保留”，而这从来没有人需求访谈时说清过。建模的产出不是图，是被逼出来的那些问题。**

第三，用例规约才是需求真正的落点，用例图只是目录。 图告诉你”有 12 个功能”，规约告诉你”第 3 步会超时、3b 的原材料数据可能缺失、异常时链条必须显式标注数据缺失而不是静默省略”。凡是写不进规约的异常流，都会在上线后变成生产事故。 这也回应了 S02 的可验证性标准：一条需求能不能写出验收用例，看的正是它的规约有没有写清前置条件、后置条件与异常流。

第四，选模型不是审美问题，是”这个模型能不能回答眼下那个问题”。 问”有哪些功能、谁用”→ 用例图；问”概念之间什么关系”→ 类图；问”这一步谁调谁、要不要等返回”→ 时序图；问”哪个部门负责哪一步、哪里能并行”→ 带泳道的活动图；问”这个对象处于什么状态、被什么事件改变”→ 状态图。用错图不是画错图，是问错了问题。

Q1 到此已有三层答案：S02 说”需求是被构造的、靠可验证性与可追溯性检验”，S03 说”靠 DFD 硬规则与数据守恒做一致性检验”，S04 说”再用面向对象的结构视角重问一遍，让没被考虑到的东西自己暴露”。三种语言、三次检验，这才敢说需求”说清了”。 至于这些类最终落成什么表结构与范式，是 S05 要正面回答的 Q3。