简介：这份UML试题合集面向正在学习面向对象分析与设计、准备课程考试或面试复习的学生与开发者，围绕用例图、顺序图、协作图等核心图形，梳理交互图差异、高内聚度、对象可见性、领域模型、统一过程等高频考点。包内为1个doc文档，压缩包约62KB，以问答与选择题形式组织，便于按知识点逐条查阅和自测。内容涵盖顺序图与协作图在时间顺序和空间组织上的对比、类图与用例图等九种图形的职责划分、UP四阶段及各阶段主要工作、增量开发与用况描述方式等，题目后附参考答案与简要解析，适合用作考前速览和概念辨析。目前已有11269人学习，可作为UML知识体系查漏补缺的轻量练习材料。

1. 从一道“送分题”翻车说起：UML 笔试到底考什么

先看一道真题：UML 中交互图有哪两种，顺序图和协作图的主要差别是什么？很多人张口就答“一个按时间、一个按空间”，然后没了。阅卷人给分点其实有三层：两种图的名称、各自强调的维度、以及优缺点对比。只答第一层，选择题能蒙对，简答题直接丢一半分。

UML 这门课的考试有个特点：概念题占大头，图形题靠判断，简答题拼的是“说全”。从这份试题大集合的分布看，九种图的分工、统一过程的四个阶段、用例之间的关系、领域建模的步骤，是反复出现的四类高频考点。它适合正在准备软件工程期末、课程笔试，或者面试里被问到“你画过哪些 UML 图”的人。拿分的关键不是背图怎么画，而是把每个概念的边界说清楚——顺序图和协作图谁强调时间、谁强调组织，UP 四个阶段各自产出什么，这类对比一旦答反，就是硬伤。

2. 九种图的分工：静态视图、动态视图与交互图怎么区分

UML 的图是这份题库里出现频率最高的模块，选择题、填空题、简答题都在考。核心不是记住九种图的名字，而是能把它们塞进“静态/动态”“结构/行为”这两个坐标里，遇到“下列哪个不是静态视图”这种题能秒判。

2.1 五类图的归类与九种图的对应关系

标准建模语言的重要内容由五类图、共九种图形来定义：用例图、静态图（类图、对象图、包图）、行为图、交互图、实现图。这个“五类九种”的说法在简答题里几乎原样考过，答的时候要能把括号里的图名补全。

按这份题库的填空真题，几个关键对应关系必须背死：

• 类图给出系统的静态设计视图；
• 用例图对系统的行为进行组织和建模；
• 顺序图和协作图都是描述系统动态视图的交互图，其中顺序图描述以时间顺序组织的对象之间的交互活动，协作图强调收发消息的对象的组织结构；
• 部署图描述物理部署。

提示：这类填空题的坑在于“状态图”和“活动图”经常被塞进静态视图的选项里当干扰项。状态图是动态的，看到“静态视图”先排除状态图。

选择题里还有一道典型的：“下面哪个不是 UML 中的静态视图”，选项是状态图、用例图、对象图、类图，答案是状态图。判断逻辑很简单——状态图描述对象随时间变化的行为，属于动态建模，和静态视图不沾边。

2.2 顺序图与协作图：时间轴和对象组织的取舍

这是整份题库里被反复追问的一题，简答题原题就是“交互图有两种，分别是顺序图和协作图，请分析两者主要差别和各自优缺点”。答题要分三段走，缺一段就扣分。

第一段说共性：两者都是交互图，都展示对象之间的消息传递和交互关系。第二段说差别：顺序图强调交互的时间顺序，按时间顺序布图；协作图强调交互的语境和参与交互的对象的整体组织，按空间组织布图。第三段说优缺点：顺序图能清晰表示消息之间的顺序和时间关系，但需要较多水平方向的空间；协作图在增加对象时比较容易、分支也比较少，但消息一多就难以表示消息之间的顺序。

面试官或阅卷人最想听的是第三段。很多人只背了“时间 vs 空间”，一问优缺点就卡壳。记法可以这样：顺序图是“横向铺开换清晰”，协作图是“对象好加但顺序难读”。

配套的选择题也要会做：“关于协作图的描述，下列哪个不正确”，错误选项是“协作图是顺序图的一种特例”。协作图和顺序图是并列的两种交互图，不存在谁是谁的特例。另一道选择题问消息序列可用哪两种图表示，答案是顺序图和协作图，别选成状态图和活动图。

2.3 状态图、活动图与实现图：容易混的三组

状态图这块有一道反复出现的判断题：“下列关于状态图的说法中，正确的是”。正确选项是“活动图和状态图是对一个对象的生命周期进行建模，描述对象随时间变化的行为”。错误选项的套路很固定：说状态图是静态视图（错），说状态图是活动图的特例（错，反了），说状态图强调多对象、活动图强调单对象（也说反了）。

对反应型对象建模一般用状态图，这是选择题原题。活动图里把活动状态分组、每组对应特定类或部门负责完成组内活动的技术叫泳道，选项里的“分叉汇合”“分支”“转移”都是干扰项。

实现图这边，组件是系统中遵从一组接口且提供实现的一个物理部件，通常指开发和运行时类的物理实现。组件图用于对系统的静态实现视图建模，支持配置管理，通常有四种建模方式：对源代码建模、对事物建模、对物理数据库建模、对可适应的系统建模——题目问“哪种不是其中之一”，答案就是“对可适应的系统建模”。部署图则对应节点，节点是被节点执行的事物这类表述要能对上组件。

2.4 真题演练：图分类选择题的答题路径

拿一道综合选择题走一遍思路：“UML 中，对象行为是通过交互来实现的，是对象间为完成某一目的而进行的一系列消息交换。消息序列可用两种类来表示，分别是（ ）”，选项是状态图和顺序图、活动图和协作图、状态图和活动图、顺序图和协作图。

答题路径：先抓关键词“消息序列”，消息交换属于交互，交互图只有顺序图和协作图两种，直接锁定第四项。状态图和活动图虽然也是动态图，但不以“消息序列”为核心。这类题的通用套路是——看到“消息”“交互”“对象之间”，就往顺序图/协作图上靠；看到“生命周期”“状态变化”，往状态图上靠；看到“活动流程”“并发”，往活动图上靠。

3. 统一过程与需求建模：四个阶段、用况和领域模型的高频问法

统一过程（UP）和需求建模是简答题的富矿。这份题库里，UP 的四个阶段、各阶段主要工作、核心工作流、核心思想、增量开发，加上用况和领域建模，几乎每一块都出过题。这一章按“阶段—工作流—需求制品”的顺序拆，最后落到真题演练。

3.1 UP 四阶段与各阶段产出：初始、细化、构造、提交

四个阶段的标准答案是：初始阶段、细化阶段、构造阶段、提交阶段。光背名字不够，各阶段的主要工作才是给分点。

初始阶段：编制简要的愿景文档、业务案例、确定范围、粗略评估成本。细化阶段：细化愿景文档、迭代地实现核心构架、解决高风险的问题、定义大多数的需求和范围、进一步评估成本。构造阶段：迭代地实现系统的其余部分、准备部署。提交阶段：beta 测试、部署。

这里有一道高频陷阱题：“定义大多数的需求和范围的工作是在 UP 中的哪个阶段完成的”，答案是细化阶段，不是初始阶段。配套还有一道反向题：“下列哪个不在 UP 的初始阶段中完成”，选项里“定义大多数的需求”就是答案。两题考的是同一个点，说明出题人特别爱在“初始阶段只做粗略评估、细化阶段才定大多数需求”这个边界上设卡。

UP 的核心工作流有五个：业务建模、需求分析、设计、实现、测试。简答题问“核心工作流有哪些”时按这五个答，别把阶段名和工作流名混在一起——阶段是时间维度，工作流是活动维度，这是两个不同的切面。

3.2 UP 核心思想与增量开发：简答题怎么答全

“UP 的核心思想有哪些”是典型的列举型简答，答案要点包括：短时间盒的迭代式开发；开发过程中不断进行调整；在早期的迭代中解决高风险和高价值的主要问题；不断与用户衔接，及时得到反馈意见；早期注意构造核心的体系结构；早期进入实现和测试，不断进行质量检验；使用用况可视化建模；仔细地管理需求、控制变更。

答题时按“迭代—风险—反馈—架构—质量—建模—变更管理”这条线串起来，比零散罗列更容易记，也显得有逻辑。阅卷人看到“迭代”“高风险”“核心架构”“用况”这几个关键词基本就给分。

增量开发要答两层意思：一是对复杂的用况分多次迭代，一部分一部分地实现；二是将所有用况按其优先级分别安排在不同的迭代中实现。只答“分批做”太笼统，必须点出“按优先级分配到不同迭代”这一层。

3.3 用况与领域模型：概念类怎么找、用况怎么描述

用况的定义要答准：用况是一个描述性的文档，用来描述一个参与者使用系统完成某个业务过程时的事件发生顺序；它描述系统的功能需求，不描述系统内部如何工作，而是定义系统的责任，说明系统必须做什么。用况模型是需求工作的重要制品，用况一般有 Brief、Casual、Fully Dressed 三种描述方式。

领域模型这块，定义是“一组表示真实世界的概念类”，注意不是软件部件的模型——填空题原题就是“领域模型是一组表示真实世界的（概念类），不是（软件部件）的模型”。找概念类有两种方法：概念类类别表、标识名词短语。领域建模的步骤是：列出候选的概念类、画出领域模型图、必要时加入概念类间的关联、必要时加入概念类的属性。

还有一道 SSD 图的题值得注意：“在画 SSD 图时，应该如何对待所涉及的系统”，正确答案是不对系统的内部结构与功能进行描述。SSD 是系统顺序图，关注的是外部参与者与系统之间的消息，系统本身当黑匣子处理，这一点和“用况不描述内部如何工作”是同一个思路。

3.4 真题演练：UP 阶段判断题与用例关系题

先看用例关系题：“在一个订单输入子系统中，创建新订单和更新订单都需要检查用户帐号是否正确，那么用例‘创建新订单’‘更新订单’与用例‘检查用户帐号’之间是什么关系”，选项是包含、扩展、分类、聚集。答题路径：两个用例都“必须”执行检查帐号这个公共行为，属于包含关系（include）；扩展是可选行为插入，聚集是整体部分，都不符合。判断口诀——公共的、必做的抽出来，用包含；可选的、条件触发的，用扩展。

再看一道 UP 阶段题：“定义大多数的需求和范围的工作是在 UP 中的哪个阶段完成”，前面已经拆过，答案是细化阶段。这类题的答题习惯是先在草稿上写出四阶段和各自关键词，再对照题干里的动作词去匹配，“定义大多数需求”只可能落在细化阶段。

4. 易错点：五类最容易丢分的题和纠正方法

这一章专挑这份题库里反复出现、且考生反复答错的点。每条按“错在哪—为什么错—怎么答对”走，考前过一遍比刷十套新题管用。

4.1 易错点一：把协作图说成顺序图的特例

错在哪：选择题里“协作图是顺序图的一种特例”被当成正确描述选上去。为什么错：两者是并列的交互图，只是侧重点不同，没有派生关系。怎么答对：记住“并列不派生”，顺序图管时间、协作图管组织，谁也不是谁的特例；协作图里通过消息编号表示消息的时间顺序，这是它补足顺序信息的手段，不是它从顺序图派生的证据。

4.2 易错点二：初始阶段和细化阶段的工作张冠李戴

错在哪：把“定义大多数的需求和范围”算到初始阶段。为什么错：初始阶段只做愿景、业务案例、范围确定和粗略成本评估，细化阶段才细化愿景、定义大多数需求和范围、进一步评估成本。怎么答对：记一条分界线——初始阶段“粗略”，细化阶段“大多数需求 + 核心架构 + 高风险问题”。凡是题干出现“大多数需求”“核心构架”，一律往细化阶段靠。

4.3 易错点三：状态图和活动图的强调对象说反

错在哪：认为状态图强调多对象参与、活动图强调单个反应型对象。为什么错：正好相反，状态图对单个反应型对象的生命周期建模，活动图更适合描述多个对象参与的活动流程。怎么答对：抓“反应型对象”这个词，它和状态图绑定；看到“流程、并发、泳道”，往活动图上靠。判断题里凡是把两者强调对象对调的选项，直接判错。

4.4 易错点四：领域模型答成软件部件模型

错在哪：填空题把领域模型说成“表示软件部件的模型”。为什么错：领域模型是真实世界概念类的集合，用于启发设计，不是软件实现层面的东西。怎么答对：领域模型 = 真实世界 + 概念类，两个关键词缺一不可；找概念类用类别表和名词短语两种方法，别答成“画类图”。

4.5 易错点五：正向工程和逆向工程方向搞反

错在哪：把“正向工程”描述成“从实现语言映射把代码转换为模型”。为什么错：正向工程是模型到代码，逆向工程才是代码到模型。怎么答对：正向 = 往前走到代码，逆向 = 往回退到模型，方向词本身就是提示。这类题选项往往只改一个方向词，读题时把“模型→代码”和“代码→模型”写在旁边对照，基本不会错。

5. 考场答题节奏：从选择题秒判到简答分点拿分的实操方法

到了考场上，UML 这类题的失分往往不是不会，而是答不全、答偏、时间分配失衡。下面这套方法是我自己踩过坑之后固定下来的流程，按题型分三段走。

选择题控制在每题四十秒内。先抓题干关键词做归类：出现“消息、交互、对象之间”归到顺序图/协作图；出现“生命周期、状态变化、反应型对象”归到状态图；出现“流程、并发、泳道”归到活动图；出现“静态视图”先排除状态图和活动图。归类完再看选项，通常能直接排除两个。遇到“下列哪个不正确”这种反向题，先在题干上圈出“不正确”三个字，避免按正向思维选错。

填空题靠的是精确记忆，答题时宁可用词保守也不要自创说法。比如“顺序图描述以时间顺序组织的对象之间的交互活动”，把“时间顺序”“对象之间”“交互活动”三个词写全；领域模型就写“真实世界的概念类”，别加“软件”二字。填空题的评分是按关键词给的，多写不扣分，漏关键词才丢分。

简答题按“定义—展开—对比/举例”三段式组织。以顺序图和协作图那道题为例：第一段给共性（都是交互图、都展示消息传递），第二段给差别（时间顺序 vs 空间组织），第三段给优缺点（清晰但占空间 vs 好加对象但顺序难读）。UP 核心思想这类列举题，按“迭代—风险—反馈—架构—质量—建模—变更”七个词打头，每个词后面补半句解释，既全又有层次。

下面这张表是我考前最后一遍过知识点时用的对照表，把最容易混的几组放在一起看：

最后说一个习惯。我以前做简答题喜欢想到哪写到哪，结果顺序图和协作图的优缺点经常漏掉第三段，白白丢分。后来每次遇到对比类简答，我都强制先在草稿纸上写“共性、差别、优缺点”三个词，再往里填内容，填不满三个词就不动笔写正文。这个笨办法让我在这类题上再没翻过车。希望帮到你。

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