简介：面向备考UML系统分析与设计课程的学生及刚接触面向对象建模的开发者，这份复习试题文档围绕统一建模语言在系统分析与设计中的应用组织内容，可用于课程复习、考前自测与知识点查漏补缺。压缩包共1个doc文件，约132KB，体积轻便，便于直接查阅、打印练习或整理成电子笔记；题目覆盖关联多重度、类关系、交互图区别、高内聚度、可见性、领域模型、用例图与GRASP职责分配等核心考点。文档以试题和答案解析为主线，穿插顺序图与协作图对比、客户订单关系分析、概念类识别、SSD图绘制等典型场景，能帮助读者在做题中理解建模思路、核对答案依据并识别常见陷阱。已有406人学习，适合需要快速梳理UML复习重点并巩固系统分析设计基础的读者使用。
1. 从多重度反读切入：UML系统分析与设计复习试题的得分结构
UML 系统分析与设计复习试题里，最容易翻车的不是图画得漂不漂亮，而是多重度读反、交互图张冠李戴。整场考试通常按三块给分：静态建模考类图、多重度和关系判定；动态建模考用例图、顺序图、协作图和 SSD；过程与原则考 UP 四阶段、GRASP、设计模式与领域模型。复习时先把“读题干—定元素—验关系—补说明”练成固定动作，再背高频结论，分数才稳。适合期末、专业课和面试前快速过一遍。
2. 静态建模必考：多重度、四种关系与类图题的判定顺序
静态建模题看起来零散，实际反复考的就几件事：多重度怎么读、关系怎么判、类图/对象图/构件图/部署图怎么选、领域模型里的概念类怎么找。题干通常不会直接写“这是组合关系”，而是用业务句子、数量词和“由……构成”来埋点。答题时别先画图，先把每个名词和数量词圈出来，再决定连线。
2.1 多重度读法：先读“订单对应客户”，再反读“客户对应订单”
多重度题不是看图猜数，而是把业务句子翻译成两端约束。比如客户订单题：①一个客户提交 0 个或多个订单；②一个订单由一个且仅由一个客户提交。先问“每个订单实例对应几个客户实例”——由②得 1 个，所以第（46）空选 B；再问“每个客户实例对应几个订单实例”——由①得 0 个或多个，所以第（47）空选 D。很多考生错在从图左向右顺着读，忽略题干问的是哪一端。
关联多重度的定义题也常考：UML 中关联的多重度是指一个类的实例能够与另一个类的多少个实例相关联。正确选项是“一个类的实类能够与另一个类的多个实类相关联”这一类表述；错误选项常把“方法被调用次数”“一个类有多个方法”混进来。多重度描述实例之间的数量约束，不描述方法调用频率。
| 题干数量词 | 图上写法 | 读法 | 常见陷阱 |
|---|---|---|---|
| 0 个或多个 | 0..* 或 * | 每个对方实例可对应零到多个本端实例 | 把“可没有”写成 1..* |
| 1 个且仅 1 个 | 1 | 每个对方实例必须对应一个本端实例 | 漏掉“且仅” |
| 1 个或多个 | 1..* | 至少一个，可多个 | 和 0..* 混用 |
| 0 个或 1 个 | 0..1 | 可选的一个 | 写成 1 |
| 多个 | * 或 0..* | 看题干是否允许零个 | 默认必须有一个 |
答题时用“每个 X 对应几个 Y”的句式逐端读一遍，再反向读一遍。客户订单题的反向校验是：订单端写 1，客户端写 0..；如果写成订单端 0..、客户端 1，业务含义立刻变成“一个订单可对应多个客户”，与题干冲突。
2.2 四种关系加聚集：依赖、关联、泛化、实现怎么一眼区分
UML 复习题里常问四种关系：依赖、关联、泛化、实现；聚集是特殊类型的关联，组合又是更强的整体部分关系。判断时看题干动词和生命周期，不要只看图形符号。
| 关系 | 语义 | 常见题干词 | 答题关键词 | 易错点 |
|---|---|---|---|---|
| 依赖 | 一个元素使用另一个元素，关系较弱 | 调用、使用、参数、临时 | 虚线箭头指向被依赖者 | 把普通关联写成依赖 |
| 关联 | 类与类之间的结构连接 | 拥有、提交、关联、成员 | 实线，标多重度 | 漏标数量 |
| 泛化 | 一般与特殊，子类是一种父类 | 是一种、继承、扩展 | 空心三角实线 | 和实现混淆 |
| 实现 | 类实现接口或规格 | 实现、遵循、接口 | 虚线空心三角 | 把泛化写成实现 |
| 聚集 | 整体与部分，部分可独立 | 包含、由……组成、可分离 | 空心菱形 | 和组合混用 |
| 组合 | 强整体部分，部分随整体生命周期 | 构成、不可共享、同生共死 | 实心菱形 | 只看到“由……构成”就乱选 |
关系判定题给的分步骤答案通常是：先看是不是“使用”关系，是就选依赖；再看是不是“整体部分”，是就选聚集或组合；再看是不是“一般特殊”，是就选泛化；最后看是不是“接口实现”，是就选实现。题目 9 的对应关系是：（1）依赖，（2）关联，（3）聚集，（4）泛化，（5）实现。
类 A 由类 B 的一个实例和类 C 的一个或多个实例构成这类题，按复习题解析应优先往组合方向答：A 是整体，B、C 是部分，A 端为 1，B 端为 1，C 端为 1..*。如果题干强调部分可以脱离整体共享，才改答聚集。答题纸上写一句“此处按组合理解，B、C 生命周期依附 A”比只画菱形更稳。
2.3 类图、对象图、构件图、部署图：静态视图题怎么选
静态视图题的高频问法是：哪张图给出系统的静态设计视图？哪张图说明静态实现视图？哪张图说明体系结构的静态实施视图？标准对应关系要背熟：类图用于静态设计视图；构件图用于静态实现视图；部署图用于体系结构的静态实施视图。题目 39 的答案就是类图、构件图、部署图。
对象图展示一组对象及它们之间的关系，是类图实例的静态快照；包图用于把模型元素分组；用例图描述系统与外部用户和外部系统之间的交互；状态图描述一个特定对象的状态与事件转移；活动图描述活动、执行顺序和工作流。复习题里常把“静态设计视图”和“静态实现视图”放在一起考，看到“代码、构件、发布”选构件图，看到“节点、网络、物理部署”选部署图。
| 图 | 主要用途 | 高频题干词 |
|---|---|---|
| 类图 | 静态设计视图，类和关系 | 类、属性、操作、关联 |
| 对象图 | 对象实例的静态快照 | 一组对象、快照 |
| 包图 | 模型元素分组 | 分组、命名空间 |
| 构件图 | 静态实现视图 | 构件、代码、发布 |
| 部署图 | 物理节点和构件分布 | 节点、网络、部署 |
题目 7 和题目 16 的答案要能直接写：类图给出静态设计视图；用例图对系统行为组织和建模很重要；序列图按时间顺序描述对象交互；协作图强调收发消息的对象组织结构。题目 38 也一样：用例图描述系统与外部系统及用户交互，序列图按时间顺序描述对象间交互。
2.4 领域模型与概念类识别：名词短语法和类别表怎么落到答题纸上
领域模型是一组表示真实世界概念类的模型，不是软件部件模型。题目 15 选“真实世界的概念类”，题目 44 填“概念类”和“软件部件”，题目 50 里领域模型又称为概念模型。这个结论必须记牢，因为选择题常把“业务流程模型”“用例模型”“设计模型”放进来做干扰。
识别概念类有两个常用策略：使用概念类类别表；标识名词短语。领域建模步骤是：列出候选概念类，画出领域模型图，必要时加入概念类之间的关联，必要时加入概念类属性。落到答题纸上，先把业务句子里的名词圈出来，去掉同义词和纯动作词，再把明显属于属性的词降级为属性描述。
某销售场景里，顾客带着商品或服务来到 POS 收款台，收款员启动一次销售，输入商品标识，系统记录商品并显示说明、价格、计算总金额。按这份复习题的参考答案，候选概念类包括：顾客、POS 收款台、收款员、销售、商品标识、商品、商品说明。答题时如果要求精简，可以把“商品标识”并入“商品”作为标识属性，但题干若强调标识独立业务含义，就保留。概念类不是越多越好，关键看它是否在业务里有独立身份和职责。
对象间的可见性也要会答：可见性指一个对象能够看到或引用另一个对象的能力，是封装和访问控制的一部分。封装是一种信息隐藏技术，目的是使对象的定义和实现分离。题目 46 的答案就是信息隐藏、定义和实现。别把可见性写成继承或多态。
2.5 真题演练：关联多重度、类关系、领域模型三连
第一题：UML 中关联的多重度是指什么。答题思路是先排除“方法调用次数”“一个类有多个方法”，再选“一个类的实例能够与另一个类的多个实例相关联”。答案 B。这里的关键词是“实例”和“关联”，不是“方法”。
第二题：客户提交 0 个或多个订单，一个订单由一个且仅由一个客户提交。对应每个订单实例，存在几个客户实例；对应每个客户实例，存在几个订单实例。答题时先读订单端：一个订单必须有一个客户，所以第（46）空选 1 个；再读客户端：一个客户可以没有订单，也可以有多个订单，所以第（47）空选 0 个或多个。答案 B、D。
第三题：类 A 由类 B 的一个实例和类 C 的一个或多个实例构成，画类图。答题时先定整体与部分，A 端标 1，B 端标 1，C 端标 1..*，关系线用组合菱形。若时间允许，在图下补一句“B、C 为 A 的组成部分，C 可多个”，避免只画图被扣说明分。
第四题：销售实例中 a、b、c、d 的多重度。按给定答案，a 为 1，b 为 1..，c 为 1，d 为 1..。这类题不要凭图形位置猜，回到业务句：“一个销售对应一个收款员”“一个销售包含多个销售明细”“一个商品标识对应一个商品”。每一条都写成“每个 X 对应几个 Y”，再填数。
3. 动态建模高频：用例、顺序图、协作图与SSD的答法
动态建模是第二大得分区，题型集中在“图种选择”和“图间区别”。顺序图和协作图几乎每年都会被拿出来对比，SSD 则常考“系统边界”和“黑盒”意识。答这类题时，先判断题目问的是时间顺序、对象组织，还是系统与外部参与者的交互，再套对应模板。
3.1 用例图：actor、scenario、用例关系与电话卡案例
用例是一个描述性文档，描述一个参与者使用系统完成某个业务过程时的事件发生顺序。用例描述系统使用过程，描述功能需求，不描述系统内部如何工作，而是定义系统责任，说明系统必须做什么。用例模型是需求工作的重要制品。用例描述一般有 Brief、Casual、Fully dressed 三种类型，考试问“如何描述用例”时，把这三档写出来，再补一句“按项目需要选择详细程度”。
参与者是 actor，是系统外部与系统交互的人、外部系统或外部设备。场景 scenario 是一次具体的事件流实例，可以理解为用例的一条路径。题目 48 问 use case、scenario、actor，答题时用“用例是业务过程的事件顺序，场景是用例的一次具体执行路径，活动者是系统外部与系统交互的角色”三句话分开，不要混成一个定义。
电话卡用例图题里，活动者是电话用户；两个用例是“使用电话卡”和“对方付款”。图上画电话用户与两个用例之间的关联线，表示用户可以发起这两个业务。若题目要求写用例关系，可以补“两个用例都是打电话场景下的不同支付方式，按题干不强行加包含或扩展”。答题时先写活动者，再写用例，最后连线，顺序清楚就不容易漏。
3.2 顺序图 vs 协作图：时间顺序和对象组织怎么答满
顺序图强调交互的时间顺序，按时间顺序布图，能清晰表示消息之间的顺序和时间关系，但需要较多水平方向空间。协作图强调交互的语境和参与交互对象的整体组织，按空间组织布图，除了展示对象之间的关联，还显示对象之间的消息传递。协作图在增加对象时比较容易，分支也比较少，但消息比较多时难以表示消息之间的顺序。
| 对比项 | 顺序图 | 协作图 |
|---|---|---|
| 侧重点 | 时间顺序 | 对象组织和语境 |
| 布局 | 按时间从上到下 | 按空间组织对象 |
| 消息顺序 | 位置直接体现 | 依赖消息编号 |
| 优点 | 时间关系清晰 | 对象关系清晰，增对象方便 |
| 缺点 | 水平空间占用大 | 消息多时顺序不直观 |
| 常见转换 | 可与协作图转换 | 可与顺序图转换 |
题目 4 和题目 72 都问两者差别，答题模板可以固定为：“顺序图以时间顺序组织对象交互，适合表达方案和事件流；协作图强调收发消息的对象组织结构，适合表达对象关系，时间顺序靠消息编号体现。顺序图时间清晰但占空间，协作图增删对象方便但消息多时顺序弱。”题目 45 填“消息编号”，这是协作图题的高频填空。
3.3 SSD与操作契约：系统黑盒边界不能越
SSD 是系统顺序图，描述外部参与者与系统之间按时间顺序发生的交互。画 SSD 时，系统要当成黑盒，不描述系统内部结构与功能。题目 51 问画 SSD 时如何对待所涉及的系统，正确选项是“不对系统的内部结构与功能进行描述”，答案 D。很多考生把 SSD 画成内部对象交互图，这是典型越界。
某销售场景的 SSD 事件顺序是：收款员启动一次销售 makeNewSale()；收款员输入商品标识 enterItem(itemID, quantity)；销售结束，系统计算并显示总金额 endSale()；顾客付款，系统处理支付 makePayment(amount)。图上只画参与者到系统边界的消息，系统用一个框表示，不展开内部对象。
操作契约把系统看成一个提供公共接口的黑盒，公共接口处理输入的系统事件，发现系统事件后定义系统操作，操作契约描述一个系统操作执行后领域模型中对象状态的变化。答题时写“系统事件—系统操作—领域对象状态变化”三段，别写成类的方法实现。
3.4 五类图九图定位：用例图、静态图、行为图、交互图、实现图
按复习题的 classification，UML 重要内容可分为用例图、静态图、行为图、交互图和实现图。静态图包括类图、对象图和包图；行为图包括状态图和活动图；交互图包括顺序图和协作图；实现图包括构件图和部署图。题目 68 问五类图，答题时按这个层级写，不要把所有图平铺成一条线。
| 类别 | 包含图 | 主要用途 |
|---|---|---|
| 用例图 | 用例图 | 系统与外部用户、外部系统交互 |
| 静态图 | 类图、对象图、包图 | 静态设计视图、快照、分组 |
| 行为图 | 状态图、活动图 | 对象状态转移、工作流和活动顺序 |
| 交互图 | 顺序图、协作图 | 对象间消息交互 |
| 实现图 | 构件图、部署图 | 静态实现视图、物理部署 |
对象图展示一组对象及它们间的关系，用来说明类图中事物实例的数据结构和静态快照；用例图展现一组用例、参与者及关系；交互图由对象及交互消息组成；状态图展示特定对象的所有可能状态及事件引起的转移；活动图描述活动、执行顺序和工作流；构件图展现构件之间的组织和依赖；部署图展现运行时处理节点及构件配置。题目 7 的填空答案要能默写：类图、用例图、序列图、协作图。
3.5 真题演练：交互图选择、消息编号、SSD画法
第一题：哪张图描述系统与外部系统及用户之间的交互；哪张图按时间顺序描述对象间交互。答案分别是用例图、序列图。判断词是“外部交互”和“时间顺序”，不要被“协作图也描述交互”带偏。
第二题：协作图中通过什么表示消息的时间顺序。答案：消息编号。协作图没有顺序图那样的纵向时间轴，靠编号体现先后。
第三题：SSD 图是否要详细描述系统内部结构。答案：不描述。SSD 只表现外部参与者与系统边界之间的消息顺序，系统内部结构属于设计图的内容。
第四题：状态图、活动图、交互图分别怎么选。状态图看“一个对象的状态和事件转移”；活动图看“活动、工作流、并行顺序”；交互图看“对象之间消息交互”。题干出现“生命周期”“状态转移”选状态图，出现“业务流程、步骤、并行”选活动图。
第五题：顺序图和协作图能否转换。答案：可以相互转换，但转换后侧重点变化。顺序图转协作图要补对象连接和消息编号；协作图转顺序图要把编号还原成时间顺序。答题时把“可转换”和“侧重点不同”一起写，得分更完整。
4. 过程与职责分配：UP四阶段、GRASP与设计模式的串联
过程题和模式题容易背成散点，考试一混就错。UP 四阶段记“每阶段产出什么”，GRASP 记“分配职责时解决什么问题”，设计模式记“问题—方案—结构”。题目 41、42、52、60 到 63 基本都在这个范围里转。
4.1 UP四阶段与核心工作流：初始、细化、构造、提交各答什么
统一过程有四个阶段：初始阶段 Inception、细化阶段 Elaboration、构造阶段 Construction、提交阶段 Transition。初始阶段做简要愿景文档、业务案例、确定范围、粗略评估成本；细化阶段细化愿景文档、迭代实现核心架构、解决高风险问题、定义大多数需求和范围、进一步评估成本；构造阶段迭代实现系统其余部分、准备部署；提交阶段做 beta 测试、部署。
题目 41 问定义大多数需求和范围的工作在哪个阶段完成，答案细化阶段。题目 42 问哪个不在初始阶段完成，答案“定义大多数需求”。初始阶段只做粗略范围，不把大多数需求定死，这是高频陷阱。
UP 核心工作流包括业务建模、需求分析、设计、实现、测试。核心思想包括短时间盒的迭代式开发、开发过程中不断调整、在早期迭代中解决高风险和高价值问题、不断与用户衔接并及时得到反馈、早期关注核心体系结构、早期进入实现和测试并不断质量检验、用用例和 UML 可视化建模、仔细管理需求和变更。题目 62 问核心思想，答题时按“迭代、风险、反馈、架构、质量、建模、变更”七个关键词展开。
增量开发包括两层意思：对复杂用例分多次迭代，一部分一部分实现；把所有用例按优先级分别安排在不同迭代中实现。题目 63 要写全两层，只写“分批做”会丢分。愿景文档主要内容包括问题说明、主要高层目标和风险承担者需解决的问题、简要功能需求、除功能需求外的其他需求。
软件开发生命期是软件产品从概念开始到交付使用为止的整个时期，一般包括概念、需求、设计、实现、测试、安装、交付阶段，这些阶段可以重复，执行时可以迭代。题目 80 的答题关键词是“整个时期”和“可迭代”。
4.2 高内聚低耦合与开闭原则：简答题的“定义+判断+例子”三段式
高内聚度是对一个类中各个职责之间相关程度和集中程度的度量。一个类具有高度相关职责，并且完成的工作量不是特别巨大，就具有高内聚度。它包括两层意思：不要给一个类分派太多职责，履行职责时尽量把部分职责分派给有能力完成的类；不相关的职责不要分派给同一个类。题目 6 和题目 83 都问高内聚，答题时先给定义，再写两层意思，最后补一句“职责单一、易理解、易维护”。
低耦合解决如何支持低依赖关系和增加重用。耦合不是越低越好，而是要控制在合理范围；该依赖的接口要依赖，不该知道的实现细节不要依赖。开闭原则是设计过程中的重要原则：对扩展开放，对修改关闭。答题时用“新增功能尽量通过扩展而不是改旧代码”来解释，再举策略模式替换算法、适配器模式兼容接口这类例子。
封装是一种信息隐藏技术，目的是使对象的定义和实现分离。对象可看成属性及对这些属性的专用服务的封装体。题目 46 的答案就是信息隐藏、定义和实现。高内聚、低耦合、封装、开闭原则经常放在一道简答里，先分层写定义，再写判断标准。
4.3 GRASP五个模式：信息专家、创建者、低耦合、高内聚、控制器
GRASP 是分配职责中通用原则的模式。复习题里重点列五个：信息专家、创建者、低耦合、高内聚、控制器。答题时按“模式名—解决什么问题—怎么分配”三列写，不要只写模式名。
| 模式 | 解决的问题 | 答题落点 |
|---|---|---|
| 信息专家 | 分配职责给对象的基本原则 | 谁拥有完成任务所需信息，就把职责分配给谁 |
| 创建者 | 谁负责创建某个类的新实例 | 谁包含、聚合或记录创建信息，谁适合创建 |
| 低耦合 | 如何支持低依赖和增加重用 | 减少不必要依赖，依赖稳定接口 |
| 高内聚 | 如何把复杂性控制在可控制范围 | 职责相关且集中，不堆不相关职责 |
| 控制器 | 谁负责处理一个输入系统事件 | 用控制器对象接收系统事件并分派 |
题目 24 问 GRASP 及各解决什么问题，按上表写就能覆盖。题目 52 问哪个不属于 GRASP，选项里“GoF”不属于 GRASP，答案 D。这里容易踩坑：单例、策略、适配器是 GoF 设计模式，不是 GRASP 职责分配模式。GRASP 里虽然还有多态、纯虚构、间接性等扩展模式，但这份复习题聚焦五个基础模式，答题以题干范围为准。
4.4 设计模式：单例、策略、组合、观察者、适配器、工厂方法、抽象工厂
设计模式是富有经验的面向对象专家设计的、作为通用原则和惯用法的解决方案，用于指导软件设计。按问题和解决方案描述结构编篡并命名，就是设计模式。题目 27 的关键词是“通用原则和惯用法”“问题与解决方案”“命名”。
| 模式 | 问题 | 解决方案 |
|---|---|---|
| 单例 Singleton | 如何使一个类严格只有一个实例 | 定义静态方法返回唯一实例 |
| 策略 Strategy | 如何适应算法或规则频繁变更 | 定义算法族，封装起来并可互相替换 |
| 组合 Composite | 希望按处理原子对象的方式处理组合对象 | 组合对象和原子对象实现相同接口 |
| 观察者 Observer | 如何维护对象之间的一致性 | 状态变化时通知依赖对象并自动更新 |
| 适配器 Adapter | 如何解决不兼容接口 | 用适配器对象转换原有接口 |
| 工厂方法 Factory Method | 如何让子类决定创建哪个对象 | 定义创建接口，由子类决定实例化 |
| 抽象工厂 Abstract Factory | 如何创建一系列相关对象 | 提供创建产品族的接口 |
题目 35 常把模式和场景配对：算法频繁替换选策略；整体部分且统一处理选组合；状态变化通知选观察者；旧接口兼容选适配器；全局唯一配置选单例。工厂方法和抽象工厂容易混：工厂方法聚焦一个产品创建，抽象工厂聚焦产品族创建。答题时先写问题，再写方案，最后写结构关键词，分数更稳。
4.5 真题演练：UP阶段、GRASP归属、模式匹配
第一题：大多数需求和范围在 UP 哪个阶段完成。答案：细化阶段。判断句是“大多数需求”，不是“粗略范围”。
第二题：哪个不在 UP 初始阶段完成。答案：定义大多数需求。初始阶段做愿景、业务案例、范围、粗略成本，细化阶段才把大多数需求定下来。
第三题：哪个不属于 GRASP。答案：GoF。GRASP 是职责分配原则，GoF 是设计模式分类，两者不能混。
第四题：UP 四个阶段及主要工作。答题按初始、细化、构造、提交逐条写。初始写愿景、业务案例、范围、粗略成本；细化写细化愿景、核心架构、高风险、大多数需求、进一步成本；构造写其余实现、准备部署；提交写 beta 测试、部署。
第五题：UP 核心工作流有哪些。答案：业务建模、需求分析、设计、实现、测试。题目 61 直接按这五项写，不要展开成阶段名。
第六题：什么是增量开发。答案写两层：复杂用例分多次迭代实现；所有用例按优先级安排在不同迭代实现。只写“分批开发”不够。
第七题：愿景文档主要内容。答案写问题说明、高层目标与风险承担者问题、简要功能需求、其他非功能需求。题目 74 按这四块答。
5. 常见失分点：多重度、交互图、SSD、GRASP与UP的五类错题
这一章专挑最容易丢分的地方。很多题不是不会，而是读题方向、图种定位和概念边界出了问题。下面五类错题按“错在哪—为什么错—怎么答对”拆开，考前过一遍，比盲目刷十套图更有效。
5.1 多重度反读：客户订单题把 0..* 填到订单端
错在哪：题目问“对应每个订单实例，存在几个客户实例”，考生看到“客户提交多个订单”，就把 0..* 填到订单端。为什么错：题干有两句话，第一句描述客户到订单，第二句描述订单到客户；填空顺序和句子顺序不一定一致。怎么答对：先把填空问句改写成“每个 X 实例对应几个 Y 实例”，再回到题干找对应句子。订单对应客户由“一个订单由一个且仅由一个客户提交”得出 1；客户对应订单由“一个客户提交 0 个或多个订单”得出 0..*。答案 B、D，写完再反向读一遍。
5.2 顺序图与协作图混答：只写“都表示交互”，不写侧重点
错在哪：问两者主要差别，答案只写“顺序图强调顺序，协作图强调协作”，没有写时间顺序、对象组织结构、消息编号和优缺点。为什么错：这类题按点给分，图名解释不算分，侧重点和优缺点才是得分点。怎么答对：固定四句话——顺序图按时间顺序组织交互，适合表达方案和事件流；协作图强调对象组织和语境，时间顺序靠消息编号；顺序图时间清晰但占水平空间；协作图增对象方便但消息多时顺序弱。题目 45 的“消息编号”要单独记住。
5.3 SSD越界：把系统内部对象和功能画进系统顺序图
错在哪：画 SSD 时把系统内部控制器、数据库、界面组件都画出来，还写内部处理步骤。为什么错：SSD 描述外部参与者与系统边界之间的消息顺序，系统是黑盒；内部结构属于设计图。怎么答对：只画 actor、系统框和消息箭头；消息名用系统操作，如 makeNewSale()、enterItem()、endSale()、makePayment()；图下补一句“系统内部结构不在 SSD 中展开”。题目 51 选“不对系统的内部结构与功能进行描述”，答案 D。
5.4 GRASP与GoF混答：把单例、策略当成 GRASP 模式
错在哪：题目问“哪个不属于 GRASP”，考生看到“单例”觉得也是模式就犹豫；或者把 GoF 当成 GRASP 的一种。为什么错：GRASP 是职责分配原则，重点在“谁负责”；GoF 是设计模式分类，重点在“问题和解决方案结构”。怎么答对：先背 GRASP 五个基础模式：信息专家、创建者、低耦合、高内聚、控制器；再记单例、策略、组合、观察者、适配器属于 GoF。题目 52 答案 D，GoF 不属于 GRASP。
5.5 UP阶段错位：把“定义大多数需求”放进初始阶段
错在哪：看到初始阶段就以为所有需求都在这里定，把“定义大多数需求和范围”选成初始阶段工作。为什么错：初始阶段只做愿景、业务案例、范围和粗略成本；细化阶段才解决高风险、核心架构和大多数需求。怎么答对：记一张阶段产出表——初始“愿景、案例、范围、粗成本”；细化“核心架构、高风险、大多数需求、进一步成本”；构造“其余实现、准备部署”；提交“beta 测试、部署”。题目 41 选细化，题目 42 选“定义大多数需求”不在初始阶段。
6. 最后30分钟抢分：从题干到UML图的五步答题路线
考场上时间紧，图题不要一上来就画。我习惯先走五步：第一步圈三类词，业务名词、数量词、触发事件；第二步定图种，问静态结构和多重度选类图，问外部交互选用例图，问时间顺序选顺序图，问对象组织选协作图，问系统边界消息选 SSD；第三步搭骨架，先画类/对象/参与者/系统框，再连线；第四步填细节，多重度、消息编号、关系符号、用例名逐项补；第五步反读校验，用“每个 X 对应几个 Y”检查多重度，用“消息编号是否连续”检查协作图，用“有没有画内部结构”检查 SSD。
押题优先级按得分效率排：多重度与客户订单题、顺序图和协作图区别、UP 四阶段产出、GRASP 五模式与 GoF 归属、SSD 黑盒边界、领域模型概念类识别。这几块几乎覆盖选择、填空和简答的大部分。简答题别只写结论，按“定义—判断—例子”三层写；模式题别只写模式名，按“问题—方案—结构”三列写；图题别只画图，图下补一句关系说明。
我以前做协作图题也爱先摆对象框，后来每次强制先写一行“消息编号=时间顺序”，再画连接，顺序题就很少再翻车。拿到这份 UML 系统分析与设计复习试题后，先做静态建模和交互图两块，再回头补 UP、GRASP 和设计模式，最后用易错点清单反查一遍。希望帮到你。
本文还有配套的精品资源，点击获取
