UML建模核心考点全解析：从图种地图到统一过程

简介：这份UML试题合集面向正在学习统一建模语言、准备课程考试或面试复习的软件工程学习者，围绕用例图、顺序图、协作图等核心图形组织题目与知识点解析，帮助读者在静态结构与动态交互之间建立清晰对应。压缩包内共1个doc文档，约62KB，以问答与选择题形式集中呈现交互图差异、高内聚度、对象可见性、领域模型、统一过程四阶段及增量开发等高频考点，并配有参考答案便于自测。已有11274人学习下载，说明其题目覆盖面与解析方式在备考人群中具有一定认可度。读者可借此梳理顺序图与协作图在时间顺序和空间组织上的取舍，理解用例图对系统行为的建模作用，并通过统一过程各阶段职责、领域建模步骤等条目查漏补缺，适合作为考前速览与知识点串联的练习材料。

1. 从一张“图种地图”切入：UML 到底在考什么

很多人复习 UML 的第一反应是背图符：小人、方框、箭头、虚线。真到做题才发现，考的不是画图，而是“什么场景该用哪张图、这张图强调什么、两张长得像的图差别在哪”。这份试题集合把用例图、顺序图、协作图、状态图、类图、部署图、组件图全串了一遍，还夹着统一过程、领域模型、高内聚度这些容易混的概念题。梳理下来会发现，它其实是一张“静态视图 + 动态视图 + 过程模型”的三层地图：静态看类图、对象图、包图、组件图、部署图；动态看用例图、顺序图、协作图、状态图、活动图；过程层看统一过程的四个阶段和核心工作流。复习时先认地图，再抠每张图的“强调点”，最后拿选择题查漏，比从头背定义高效得多。适合正在系统学面向对象分析与设计、或者临考要快速过一遍的人。

2. 交互图双雄：顺序图与协作图的取舍与易错点

2.1 两张图到底差在哪：时间轴 vs 空间组织

顺序图和协作图是这份试题里出现频率最高的一对，几乎每套题都要问差别。核心只有一句话：顺序图强调交互的时间顺序，协作图强调交互的语境和参与对象的整体组织。顺序图按时间顺序布图，消息从上往下排；协作图按空间组织布图，对象围绕消息连线摆放，靠消息编号体现先后。

这里最容易翻车的是“协作图是顺序图的一种特例”这种说法——试题里明确把它列为错误项。两者是并列的交互图，不是包含关系。另一个高频点：在协作图中通过消息编号表示消息的时间顺序，而不是靠上下位置。还有一道常考的工具题，说协作图可在顺序图基础上按某功能键自动生成，这类题记住“可转换”即可，别把方向记反。

2.2 顺序图的组成与 SSD 的画法边界

顺序图由类角色、生命线、激活期和消息四部分组成，这是选择题的固定考点，四个要素缺一不可。复习时把“消息”当成顺序图的灵魂：同步消息、异步消息、返回消息的画法不同，但试题层面更爱考“顺序图由哪几部分组成”这种识记题。

系统顺序图（SSD）是另一个易混点。题目问画 SSD 时该如何对待所涉及的系统，正确答案是“不对系统的内部结构与功能进行描述”。原因很直接：SSD 把系统当成一个黑匣子，只关心外部参与者与系统之间的消息往来，一旦画了内部结构就变成了设计阶段的图，越界了。这个点血泪经验是：看到“详细描述内部结构”的选项基本可以排除，SSD 的立场永远是外部视角。

2.3 交互图相关的易漏点

• 易漏点一：把协作图当成顺序图的子类。为什么漏：两张图都能画消息，长得像就默认有继承关系。怎么补：记住“并列的两种交互图”，一个管时间一个管空间，做题先问“这题强调的是顺序还是对象组织”。
• 易漏点二：以为协作图靠位置表示顺序。为什么漏：顺序图看惯了上下位置。怎么补：协作图认“消息编号”，编号才是时间顺序的唯一依据。
• 易漏点三：SSD 里画系统内部。为什么漏：平时画设计图习惯展开内部。怎么补：SSD 只画参与者和系统边界，系统内部一律不展开。
• 易漏点四：混淆交互图与行为图。为什么漏：状态图、活动图也描述动态行为。怎么补：交互图专指顺序图和协作图，状态图、活动图属于行为图，别混进“交互图”这个筐。

3. 用例图与需求建模：参与者、用况与三种描述粒度

3.1 用况的本质：定义责任而不是定义实现

用况是一个描述性的文档，描述一个参与者使用系统完成某个业务过程时的事件发生顺序。它描述的是系统的功能需求，不描述系统内部如何工作，只定义系统的责任，说明系统必须做什么。这句话是判断题和简答题的高频答案，关键词是“不描述内部如何工作”。

用况模型是需求工作的重要制品，用况一般有 Brief、Casual、Fully Dressed 三种描述方式，从简到繁。复习时按粒度记：Brief 一两句话概括，Casual 用松散格式写主流程，Fully Dressed 把前置条件、主成功场景、扩展场景全写全。试题爱考“用况有哪三种描述方式”，答全三个英文词即可。

用例之间的关系也是必考项。试题里给了一个典型场景：创建新订单和更新订单都需要检查用户帐号是否正确，问“创建新订单”“更新订单”与“检查用户帐号”是什么关系，答案是包含（include）。判断口诀：多个用例共同复用的公共行为用 include；只在特定条件下才插入的附加行为用 extend。前者是“必须做”，后者是“可能做”，方向别搞反。

3.2 用例图在九种图中的定位

UML 的重要内容由五类图共九种图形定义：用例图、静态图（类图、对象图、包图）、行为图、交互图、实现图。用例图的定位是“对系统的行为进行组织和建模”，它给出系统的静态设计视图之外的另一个视角——从外部看系统能做什么。

这里有个反复出现的陷阱：题目问“哪个不是 UML 中的静态视图”，选项里混进状态图，正确答案就是状态图。静态视图包括用例图、类图、对象图，状态图是动态的。另一道题问“类图应该画在哪种视图”，答案是逻辑视图（Logic View），不是用例视图也不是组件视图。把“图”和“视图”分开记：图是画出来的东西，视图是工具里的组织容器，两者不是一一对应。

3.3 用例建模的易错点

• 易错点一：include 和 extend 方向反了。为什么错：两个词都表示“用到”。怎么错补：include 是基础用例指向被包含用例，箭头朝被包含方；extend 是扩展用例指向基础用例，箭头朝基础方。记“包含是必须，扩展是可选”。
• 易错点二：把用例图当静态视图排除在外。为什么错：用例图看起来像“功能列表”，容易归到动态。怎么补：试题明确用例图属于静态视图范畴，状态图才是动态。
• 易错点三：用况描述里写实现细节。为什么错：写需求时顺手写了“系统调用某接口”。怎么补：用况只写参与者与系统的交互事件顺序，内部实现留给设计阶段。

4. 静态结构建模：类、领域模型与高内聚度

4.1 领域模型：找概念类的两条路

领域模型是一组表示真实世界概念类的模型，不是软件部件的模型。这个“不是软件部件”是选择题的固定干扰项，题目会把“真实世界的概念类”和“软件部件的模型”摆在一起让你选。领域模型在设计工作中广泛用来启发设计软件对象，它的立场是问题域，不是解域。

找概念类有两种方法：概念类类别表和标识名词短语。前者按常见类别（人、地点、事物、事件等）去套，后者从需求文本里把名词圈出来再筛选。领域建模的步骤是四步：列出候选概念类、画出领域模型图、必要时加入概念类间的关联、必要时加入概念类的属性。注意“必要时”三个字，属性和关联不是越多越好，只加对理解问题域有用的。

4.2 高内聚度：两个“不要”和一个度量

高内聚度是对一个类中各个职责之间相关程度和集中程度的度量。一个类职责高度相关、且完成的工作量不是特别巨大，就具有高内聚度。它包含两层意思：一是不要给一个类分派太多职责，履行职责时尽量把部分职责分派给有能力完成的其它类；二是不相关的职责不要分派到同一个类。

复习时把它和“单一职责”对照记：高内聚说的是“类内部职责的相关程度”，不是“类越小越好”。试题常把“给一个类分派尽可能多的职责”作为错误选项，正确方向是职责相关且工作量适中。这里有个容易忽略的细节：高内聚度同时约束“相关性”和“工作量”，只强调相关不控制体量，也会走向 god class。

4.3 类、组件与部署：静态视图的三层落点

类通常分为实体类、控制类和边界类，这是类图题的固定三分类。实体类承载数据，边界类处理系统与外部交互，控制类协调业务逻辑。组件是系统中遵从一组接口且提供实现的物理部件，通常指开发和运行时类的物理实现；组件图用于对系统静态实现视图建模，支持配置管理。部署图描述物理部署，节点是被节点执行的事物的宿主。

组件图的四种建模方式里，试题问“哪种不是其中之一”，答案是“对可适应的系统建模”——组件图建模的是源代码、可执行体、物理数据库这类实体，不是抽象的系统适应性。这类题靠排除法：凡是听起来很虚、不像“物理部件”的选项，基本就是错误项。

4.4 静态建模的易漏点

• 易漏点一：领域模型里塞软件类。为什么漏：画着画着就想到实现。怎么补：领域模型只放真实世界概念类，软件部件留给设计类图。
• 易漏点二：高内聚理解成“职责越少越好”。为什么漏：只记住“不要太多职责”。怎么补：高内聚是相关性和工作量的平衡，不是单纯减职责。
• 易漏点三：组件图建模对象搞错。为什么漏：组件和类都叫“部件”。怎么补：组件是物理实现，建模对象是源代码、可执行体、物理数据库，不是抽象适应能力。
• 易漏点四：类图画在错误视图。为什么漏：工具视图名不熟。怎么补：类图放逻辑视图，用例图放用例视图，组件图放组件视图，部署图放部署视图。

5. 动态行为与过程模型：状态图、活动图与统一过程

5.1 状态图与活动图：一个对象 vs 多个对象

状态图和活动图都描述对象随时间变化的行为，但侧重点不同。状态图对单个反应型对象建模，强调一个对象在生命周期中的状态迁移；活动图强调对有几个对象参与的活动过程建模，用泳道把活动按负责的类、人或部门分组。试题里那道“状态图强调对几个对象建模、活动图强调单个对象”的选项是反的，正确说法正好颠倒。

泳道是活动图的高频考点：把活动状态分组，每组表示一个特定的类、人或部门，负责完成组内活动。分叉汇合、分支、转移是活动图的控制节点，别和泳道混。对反应型对象建模一般用状态图，这是“反应型对象—状态图”的固定搭配。

5.2 统一过程：四阶段与核心工作流

统一过程（UP）分四个阶段：初始、细化、构造、提交。各阶段主要工作要能对上号：

两道经典题：定义大多数需求和范围在哪个阶段完成？答细化阶段。哪个不在初始阶段完成？答定义大多数需求。这两题其实是一体两面，记住“细化阶段才定大多数需求”就能同时拿下。UP 的核心工作流有五个：业务建模、需求分析、设计、实现、测试。

UP 的核心思想可以压缩成几条：短时间盒的迭代式开发、开发过程中不断调整、早期迭代解决高风险高价值问题、不断与用户衔接获取反馈、早期构造核心体系结构、早期进入实现和测试、用况驱动、UML 可视化建模、仔细管理需求控制变更。增量开发则有两层意思：复杂用况分多次迭代一部分一部分实现；所有用况按优先级安排在不同迭代中实现。

5.3 过程与行为建模的易错点

• 易错点一：状态图和活动图的建模对象记反。为什么错：两张图都画“状态”和“活动”，名字接近。怎么补：状态图对单个反应型对象，活动图对多对象参与的过程，泳道是活动图的标志。
• 易错点二：把“定义大多数需求”放到初始阶段。为什么错：初始阶段听起来像“定需求”。怎么补：初始只做愿景、范围、粗略成本，细化阶段才定义大多数需求和范围。
• 易错点三：UP 核心工作流漏项。为什么错：只记设计实现测试。怎么补：五个工作流从业务建模起头，需求分析、设计、实现、测试收尾。
• 易错点四：增量开发只记“分多次”。为什么错：漏了按优先级排迭代。怎么补：增量开发两层含义，分次实现 + 按优先级分配迭代。

6. 查漏补缺：一份可执行的复习清单

复习到这一步，最有效的动作不是再刷一遍定义，而是拿一张空白纸把“图—强调点—易错项”三列默写出来，写不出的就是漏洞。下面这份清单按“先地图后细节”排，照着过一遍，基本能把这份试题集合里的高频点全覆盖。

具体操作上，我习惯分三轮。第一轮只过地图，把九种图和四阶段画成一张关系草图，不抠细节；第二轮按上表逐行自检，凡是卡壳的模块回到对应章节重读，重点看“为什么错”而不是“正确答案是什么”；第三轮只做错题，把每道错题归到“记混了”“没记住”“理解反了”三类，前两类靠重复，第三类必须回到概念本身重新推一遍。

最容易忽略的是“图”和“视图”的对应关系，以及 SSD 的边界。这两块题量不大但几乎每次都出现，属于典型的低投入高回报点。另一个后悔药是统一过程阶段题，很多人背了四阶段名字却记不住“定义大多数需求在细化阶段”，结果两道题一起丢分。

从那以后我每次复习这类建模题，都强制先默写一遍“图种地图”再动笔做题，地图写不全就不碰细节题。希望这份梳理能帮到你，把散落的试题收成一张能随时调出来的网。

本文还有配套的精品资源，点击获取