简介这份UML试题大集合围绕用例图、顺序图、协作图等高频考点展开适合正在复习面向对象分析与设计、准备期末考试或软考相关科目的学生和开发者。文档将零散的UML知识点整理成系统化问答题集覆盖交互图中顺序图与协作图的差别和优缺点、高内聚度的含义、对象间可见性、领域模型建模步骤、统一过程的阶段划分与核心工作流、增量开发、用况及用况模型、UML九种图形分类等内容多数题目附有参考答案或选项解析便于自测和查漏补缺。压缩包内为1个doc文档整体约62KB内容集中、重点突出适合考前快速浏览。目前已有11265人学习。借助这些典型问答与选择题读者可以加深对系统静态设计视图和动态交互视图的理解也为解答UML概念辨析题提供明确思路。1. 为什么说用例图和顺序图是 UML 试题里最值得先啃的两座山如果你手里攥着一份「uml 试题大集合」翻过几套卷子就会得出同一个结论用例图和顺序图几乎每套必考。选择判断里它们换着说法出现画图题里经常成对考——先根据需求描述画用例图再挑其中一个用例展开成顺序图。这两张图的分值通常能到 15 到 25 分基本决定这门课的命运。但很多人刷大集合的方式是无效的选择题做一遍就划掉画图题只看答案不动手顺序图抄一遍参考答案以为记住了。结果一到考场需求描述换个措辞就不知道怎么下手。这不是题目不够多而是没把题目按考点拆开。这篇文章就做一件事把「用例图 顺序图」这个考点组合在大集合里的出现规律、评分逻辑、刷题顺序和翻车点讲透。适合正在备战的在校生也适合准备补考或软件工程相关考试的人。从怎么读题目描述到怎么自我判卷一条线走完。2. 用例图考点拆解参与者、用例与 include/extend 判定2.1 阅卷人先看什么系统边界、参与者、用例三件套用例图看似简单——一个框、几个小人、几个椭圆、几条线。但阅卷时先扫的不是关系画没画对而是三件套齐不齐系统边界框有没有画、参与者是不是落在边界外、用例是不是都落在边界内。这三样缺一样哪怕用例找全了也要扣分。教务系统类题目是重灾区。题目描述里写着「学生可以选课、退课、查询成绩教师可以录入成绩」很多人上来就画三个椭圆加两个小人系统边界框直接省略。按常见评分标准边界框单独占一分丢了就是丢了。至于边界框里写什么一般写系统名称比如「学生选课系统」也可以直接照抄题目给的系统名。另一个容易忽略的点是参与者。参与者不只是人也可以是外部系统。比如在线购物题里「支付网关」就是一个参与者它不是系统内部模块而是和系统交互的外部角色。判断标准就一条这个角色是否直接与系统交互、且不受系统内部控制。如果是就画在边界外。大集合的参考答案里支付服务通常都画在边界外但新手第一次画总是把它塞进系统框里——这一笔就是两分。参与者的布局也有讲究。主参与者通常放图左侧辅助参与者比如外部系统放右侧。考试不强制但这样画的可读性高阅卷人第一眼就能看懂谁在发起主流程。我一般把这个习惯固定下来画图时不需要再想。2.2 从需求描述到用例图四步拆解法拿到一段需求描述别急着画。我按四步走找参与者、找用例、定边界、连关系。每一步对应一个检查点缺了任何一步回头检查时都会发现图是「飘」的——好像每样都画了但合起来不对。第一步找参与者。把描述里所有「谁」圈出来。名词性角色先全列出来再逐个判断是不是真参与者。考试里常见干扰项是「管理员」「系统维护人员」如果描述里没提就不要自己加。反过来如果描述里出现了「库存系统」「支付网关」这类外部系统名也归入参与者而且是绝对不能漏的那种。判断方法这个角色和系统之间有没有直接的消息交互没有交互就不是参与者。第二步找用例。把描述里所有动词短语圈出来。「选课」「退课」「查询成绩」「录入成绩」就是候选用例。这里有个关键判断用例必须能给参与者带来可观察的结果。一个用例是一个完整的功能单元不能拆成「输入用户名」「点击登录」「验证密码」这种步骤——这是新手画错的第一原因。把用例细化到操作步骤级别图就变成了流程图这是大集合里改错题最爱的考点。第三步定边界。用一个矩形把全部用例包进去参与者全部放在矩形外。名字写系统名称。注意边界框和用例之间不能有连线参与者绝不能画进框内。边界框的作用是把「系统的责任范围」可视化框内是系统承诺的功能框外是环境中的角色。第四步连关系。参与者和用例之间画实线方向从参与者指向用例。用例之间的关系include/extend单独用虚线箭头。这一步是失分重灾区具体细节放在 2.3 展开。[学生] —— (查询成绩) [学生] —— (选课) [教师] —— (录入成绩) ----------------------- | 课程管理系统 | | (查询成绩) | | (选课) | | (录入成绩) | -----------------------上面这个是最简结构先别管 include 和 extend把基础骨架搭对。实际考题的描述里会有条件分支和异常路径比如「选课人数已满时提示选课失败」——这个「提示选课失败」不是一个独立用例而是「选课」用例的异常分支。要不要画、怎么画取决于题目要求。如果题目没明确要求表达异常分支最安全的做法是只画主流程用例把异常留到顺序图环节体现。画多了反而会被扣「多画无关用例」的分。2.3 include 与 extend用语义判断而不是靠「可选」猜include包含和 extend扩展是用例图里最绕的两个考点。很多同学靠手感硬记带「必须」的是 include带「可选」的是 extend。这个记忆法能蒙对简单的题但一到综合题就翻车——因为命题人很清楚这个误区会把描述里的「可选」改写成「在特定条件下」让你无法靠关键词判断。include 的语义是基础用例在执行过程中一定会调用被包含用例。被包含用例是基础用例的公共步骤离开了它基础用例不完整。典型例子是「下单」包含「身份验证」任何下单都必须先验证身份。「身份验证」可以同时被「下单」「改密码」「查询订单」等多个用例包含这就是 include 的复用价值。extend 的语义是基础用例在特定条件下才执行扩展用例扩展用例是可选分支。典型例子是「查询订单」在「网络异常」条件下扩展出「显示错误提示」。没有这个扩展基础用例照样成立主流程不受影响。判断方法把「基础用例 候选用例」合在一起看。基础用例离开候选用例就不完整、无法正常工作就是 include去掉候选用例基础用例依然能完整走完主流程就是 extend。这个判断要在语义层做而不是看题干里有没有关键词。includeextend语义基础用例必选执行特定条件下才执行箭头方向基础用例 → 被包含用例扩展用例 → 基础用例判断标准去掉后基础用例不完整去掉后基础用例仍完整典型场景登录、鉴权等公共步骤异常处理、可选功能画的时候include 和 extend 都用带箭头的虚线但方向完全相反include 的箭头指向被包含用例extend 的箭头指向基础用例。箭头上分别标注《include》《extend》。方向画反是大集合里出现率最高的错误之一我一般画完读一遍include 读作「A 一定包含 B」箭头从 A 到 Bextend 读作「B 在特定条件下扩展 A」箭头从 B 到 A。这个读法熟了方向就不会错。3. 顺序图考点拆解消息、生命线与组合片段3.1 顺序图的三个核心元素对象、消息、激活顺序图sequence diagram在 UML 试题里通常是「第二问」前面先画用例图然后挑其中一个用例展开成顺序图。它考察的是对执行流程的理解而不只是静态结构。三个核心元素必须零错误对象生命线、消息、激活条。对象用矩形框表示矩形下面是垂直虚线这条虚线就是生命线。对象名写在矩形框里格式是「对象名:类名」比如「订单:Order」。很多题目会规定对象集合你只需要按题目给的对象画不要自己发明对象。新手最容易犯的错就是题目给了四个对象他硬画六个——多出来的对象既没有交互也没有消息纯粹凑数。凑数不加分只增加阅卷人发现流程混乱的概率。消息是对象之间的水平箭头表示一次方法调用或返回值。调用用实线实心箭头返回用虚线箭头。考试一般不严格要求区分同步异步更关键的是消息顺序和编号连续性。如果题目要求编号消息必须从 1 开始连续递增嵌套调用用 1.1、1.2 这种子编号。编号断号或者跳号是实打实的扣分点。激活条是对象生命线上覆盖的一段细矩形条表示对象正在执行某个操作。激活条的起点是消息箭头到达的位置终点是方法返回的位置。画错激活条是顺序图扣分的头号原因很多人干脆不画等于直接把送的分扔了。「激活条代表对象的执行周期」这个概念本身也是选择判断题的常见考点属于必须记牢的基础。顾客 系统 库存 | | | |--1 提交订单--| | | |--1.1 检查库存--| | |--1.2 库存充足--| |--2 下单成功---| |上面这个结构是典型的用例「下单」的顺序图骨架。注意消息编号的层级消息 1 是顾客到系统的调用1.1 是系统内部对库存子系统的调用1.2 是返回。返回消息要不要单独编号不同教材有分歧考试时按题目要求来。如果题目没要求编号你完全可以不写编号画清楚消息流向就好。最忌讳的是题目没说编号你自作主张编一套编号规则又和阅卷人手里的评分细则对不上反而被扣分。3.2 从用例到顺序图找对象、定消息、串流程从用例图到顺序图本质上是把用例的主成功场景翻译成对象间的消息序列。我习惯用三步法。第一步从题目描述里找对象。对象要么是参与者要么是系统内部的关键类。参与者一定出现在顺序图里通常放在最左侧。系统内部对象根据描述决定比如「库存系统」「数据库」「支付服务」。注意参与者在顺序图里也是对象同样要画矩形框和生命线不能只画一个无名小人。第二步把用例主流程拆成一条时间线。从参与者发出第一个动作开始一个动作对应一条消息。消息次序就是用例描述里的动作次序。题目描述里通常有明显时序词「首先」「然后」「最后」直接翻译成消息编号。如果没有时序词就按业务常识排序——先请求后响应先校验后操作。第三步检查消息的发送者和接收者是否合理。消息永远是从一个对象发向另一个对象不能自己发给自己题目要求自调用除外也不能跳过中间对象直接发到无关对象。比如「顾客直接给数据库发查询」这种跨越就不合理——顾客只能和系统交互不能直接碰到系统内部的数据库。错误示范 顾客 - 数据库: 查询订单 正确写法 顾客 - 系统: 查询订单 系统 - 数据库: 查询订单记录 数据库 -- 系统: 订单记录 系统 -- 顾客: 订单列表三步走完图的骨架就出来了。剩下的是补齐激活条和返回消息。很多同学顺序图丢分不是不懂建模而是画得太「省」——消息画了激活条漏了返回值也不画。阅卷人手里有一项叫「完整性」的评分维度缺一样就扣一项。画完消息线后从最后一条消息反向检查最后一条消息一定是返回给最初发起者的某个结果。如果流程画到支付服务就停了没有返回给顾客说明这段交互没说完。3.3 组合片段 alt/loop/opt考试里怎么画才不丢分组合片段combined fragment是顺序图里难度最高的考点。考试常考三种alt、loop、opt。alt替代表示 if-else 分支。画成一个矩形框用水平虚线分成上下几块每块左上角写条件表达式。比如「选课」用例「[人数未满] 选课成功」「[人数已满] 返回失败提示」。alt 的每一块都是互斥分支一次执行只能走其中一块。要注意条件写在方括号里这是 UML 规范写法写成圆括号会显得不专业。loop循环表示重复执行。框内写循环条件比如 loop(1..10) 或者 loop(库存为空)。题目描述里出现「反复」「直到」「多次尝试」之类的词就要用 loop 包起来。注意 loop 框里必须画完整的消息序列不能只画一条消息然后写「循环上述步骤」——这种偷懒写法在考试里会被扣分。opt可选表示只有条件满足才执行的步骤等价于没有 else 分支的 alt。题目描述里出现「如果/当…时/若…」且没有给出替代行为就是 opt。但如果描述同时给了条件和替代行为就要用 alt。这是判断边界也是常见的失分点。顾客 - 系统: 提交订单 系统 - 系统: 验证登录状态 opt [登录失败] 系统 - 顾客: 返回错误提示 系统 - 支付服务: 发起支付组合片段的框跨越哪些生命线取决于这段逻辑涉及哪些对象。只涉及两个对象的条件分支框就只包住这两条生命线不要为了画得整齐把整个图都包进去。这个细节做对了图会显得专业很多做错了阅卷人一眼看出你对组合片段语义理解不到位。还有一个高频考点alt 和 loop 可以嵌套。比如「循环尝试登录直到成功或次数超过 3若超时则提示错误」——外层是 loop内层是 alt。画的时候注意先画外层框再画内层框每个条件都标注在对应区域的左上角不要漏。大集合里的综合题经常这么考平时刷题遇到嵌套结构的题值得单独标记。4. 试题大集合的刷题法按题型分层不按数量硬刷4.1 三类题型应对方式完全不同时间分配跟着分值走「uml 试题大集合」这个名字容易让人产生一种错觉从头做到尾就是有效复习。但实际经验是大集合的价值在于题型结构而不是题目数量。按题型分三层刷效率高得多。第一层是选择题和判断题。这类题考的是概念边界include 和 extend 的区别、参与者怎么判断、顺序图消息编号的规范。刷这些题的目的不是记住具体题目而是把概念边界打磨清楚。每错一道回到教材对应小节复读一遍。为什么强调「回到教材」而不是「看答案」因为选择题的干扰项就是概念混淆点只看答案记住了「这题选 C」下次换个说法照样错。我在刷大集合时会把错题对应的教材页码写在题号旁边一轮下来错题集中的章节一目了然。第二层是简答题。考的是「什么是参与者」「什么是激活条」「组合片段有哪些类别」。这类题占比不小但背诵成本高、分值低。建议只做筛子能用自己的话讲清楚就过讲不清楚就标记考前突击背。不要在这一层花太多时间——简答题背得再好撑死 5 到 8 分不如一道画图题的分值。第三层是画图题。这是大集合的核心价值。画图题不能只看必须动手。每道题给自己限定时间用例图 8 分钟、顺序图 10 分钟画完对照参考答案逐项打勾参与者漏了吗用例全吗边界框有吗include/extend 方向对吗消息编号连贯吗激活条画了吗这些检查项不需要老师批改自己就能完成但没有动手画过的人永远不会意识到自己会漏。三层的时间分配建议概念层 30%画图层 60%简答层 10%。画图题才是分值大头投入产出比最高。如果只剩一周复习时间画图层要提到 70%概念层只刷错题就够了。4.2 画图题五维自测清单每次画完对一遍每次画完一张图对照下面的五维清单给自己打分。这张清单是我从不同考试的评分细则里提炼出来的通用版本适配大多数 UML 考试不挑教材。维度自检问题常见扣分点完整性图上所有元素是否齐全漏系统边界框、漏激活条、漏返回值正确性流程与需求描述是否一致消息顺序颠倒、用例多画或少画规范性命名、箭头方向、线型是否符合规范用例名写成名词、include/extend 箭头指反美观度手绘图是否清晰可读线条交叉、椭圆挤压、字迹潦草扩展性可选分支和异常分支是否正确表达该用 alt 的地方没用、extend 放错位置第一个维度是完整性。用例图的参与者、用例、边界框、关系箭头是否齐全顺序图的对象、生命线、消息、激活条是否齐全。这一维度最容易自查也最容易丢分——因为不是不会画是漏画。漏画的原因通常是时间紧张所以刷题初期就要养成「画完数一遍」的习惯数完再交。第二个维度是正确性。用例图和需求描述的对应关系是否正确有没有脑补出题目没提的功能顺序图的消息顺序是否符合业务逻辑有没有「先发货后付款」这种反常识流程。这一维度靠逆向读图来验证具体方法在最后一章展开。第三个维度是规范性。命名是否规范用例名用动词短语「查询成绩」而不是「成绩查询」参与者用名词对象用「对象名:类名」格式。关系箭头的方向、虚线和实线的区分都要符合教材约定。规范性的扣分最冤——流程全对但一个箭头方向错了整道题被扣 2 到 3 分。第四个维度是美观度。这个维度只在手绘题时被考察。线要直、椭圆不要挤成一团、箭头清晰、字写端正。不少人因为图太乱被扣「可读性」分很冤。手绘不要求美术水平只要做到元素不遮挡、连线尽量少交叉可读性分就能拿到。第五个维度是扩展性。如果题目要求「画出用例图并指出可扩展点」你要在图上用 extend 正确表达可扩展性而不是把功能平铺成一堆用例。这个维度一般出现在高分题或附加题里遇到值得单独标记考前重点看。4.3 综合题示范一道需求描述产出两张图大集合里最有价值的是综合题一段需求描述要求产出用例图和顺序图。拿一道典型题拆一遍模拟真实做题节奏。题目描述常见表述某在线购物系统支持顾客浏览商品、添加购物车、提交订单。提交订单时需要先登录若登录失败则提示错误。订单提交成功后系统调用支付服务完成支付若支付超时则订单进入待支付状态并提示。顾客可以取消待支付状态的订单。第一问画用例图。按四步法参与者有「顾客」和「支付服务」——支付服务是外部系统也是参与者。用例有「浏览商品」「添加购物车」「提交订单」「登录」「支付」「取消订单」。注意「登录」不是一个独立面向顾客的用例它在「提交订单」内部必选执行所以「提交订单」include「登录」。「支付」同样是「提交订单」的必选步骤「提交订单」include「支付」。而「订单进入待支付状态」是「支付」的异常路径用「待支付提示」extend「支付」来表达。这道题的坑在于很多人把「登录」画成独立用例并直接连上顾客但题目说的是「提交订单时需要先登录」登录并不是顾客可以单独发起的操作。第二问从「提交订单」用例展开顺序图。对象是顾客、系统、支付服务。消息序列顾客 - 系统: 提交订单 系统 - 系统: 验证登录状态 alt [登录失败] 系统 - 顾客: 返回错误提示 [登录成功] 系统 - 支付服务: 发起支付 支付服务 -- 系统: 支付结果 系统 - 顾客: 返回订单受理结果注意「验证登录状态」是一个自调用消息箭头从系统生命线出发回到同一条生命线激活条上会叠出第二段。alt 框把「登录失败」和「登录成功」两块包起来条件写在每块左上角。这道题如果你画了「顾客 - 系统: 登录」这一步反而错了——因为登录是系统内部校验不是顾客直接发起的动作。这段示范的意义在于大集合里的综合题不是拿来背答案的是拿来练习「拆解」的。不需要做一百道把二十道综合题按这个方式吃透考场上的变化基本都在射程内。见过考前刷了八十道题反而不如刷了二十道但每道复盘的同学差别就在有没有把「拆解」练成肌肉记忆。5. 避坑手册UML 试题里最常见的 5 个翻车现场5.1 翻车点一把系统内部操作画成用例现象画用例图时把「验证密码」「连接数据库」「计算价格」也画成用例整个图塞满动词看起来像流程图而不是用例图。原因没有区分「用例」和「系统内部步骤」。用例是从参与者视角看到的完整功能单元内部步骤是实现细节不应该出现在用例图上。解决返回需求描述只把参与者能直接发起、且能获得可观察结果的动作作为用例。「验证密码」不产生参与者可观察的结果而「登录」产生「成功/失败」的结果所以只有后者是用例。一个简易检查方法如果某个「用例」没有参与者箭头指向它它多半是被误当成用例混进来的内部步骤。5.2 翻车点二顺序图消息箭头画反现象调用消息画成虚线箭头返回消息画成实线箭头或者消息方向从被调用方指向调用方。原因混淆了「调用」和「返回」的表示法或者没有理解消息的方向代表「发送者到接收者」。解决记住约定——调用是实线实心箭头返回是虚线箭头。画的顺序是先画调用后画返回。返回消息一定晚于对应的调用消息出现这条规则比箭头样式更优先。如果发现自己画出的消息序列里有一条消息是从下往上走的先别急着当成「回传」检查一下是不是时序错了。正常顺序图的阅读方向是左上到右下。5.3 翻车点三激活条画错位置现象对象的激活条画到了消息到达之前或者消息已经返回但激活条还在延伸看起来像对象在「空转」。原因没有理解激活条的生命周期。激活从消息到达开始到返回消息发出结束。激活条的长度不是随便画的它对应着对象实际执行的时间段。解决每画一条消息检查发送方和接收方的激活条是否对应。接收方的激活条顶端恰好被消息线穿过底端在返回箭头的位置。如果画完发现激活条比消息线长出一截或者短了一截就是位置错了。手绘时可以先用铅笔画激活条确认消息线都对齐后再描实省得反复返工。5.4 翻车点四include 和 extend 方向画反现象include 的虚线箭头从被包含用例指向基础用例或者两个关系的箭头都指向同一个方向。原因只记了「都是虚线箭头」就动手画没有把方向规则刻进脑子里。解决固定记忆一个公式——include基础用例 → 被包含用例extend扩展用例 → 基础用例。两者都是虚线箭头方向完全相反。画完检查箭头的指向对象标注《include》的箭头指向被包含用例比如「身份验证」标注《extend》的箭头指向基础用例比如「提交订单」。可以借助直觉记忆include 是「大流程」指向「公共步骤」extend 是「可选分支」指回「主流程」。5.5 翻车点五参与者命名随意、遗漏外部系统现象参与者写「用户」「人」这种模糊名词或者「支付网关」「库存系统」这类明显的外部系统没有作为参与者画出来。原因命题描述里的角色词汇没有仔细析出命名也不按规范。很多同学看到「用户」就写「用户」没意识到上下文里的「用户」可能指「注册用户」或「游客」两者在权限上是不同角色画成同一个参与者会丢失关键语义。解决参与者的命名用具体角色名。「注册用户」「游客」「管理员」都行但不要用一个「用户」带过。外部系统的识别看交互边界凡是需要通过网络或接口与系统通信的都作为参与者画在边界外。一个实用的判断技巧把描述里所有动词前的主语名词列出来凡是直接对系统发起动作的角色都是参与者或候选参与者。6. 进阶技巧用逆向读图法给自己当阅卷人这一章介绍一个亲测有效的验证方法逆向读图法。它适合最后冲刺阶段也适合每画完一题立刻自检。什么是逆向读图法就是不看需求描述只看你画好的图把图的逻辑用自然语言读一遍。这像「反向编译」——如果读出来的故事和题目描述的流程一致图就是对的如果读出来的流程不通顺、有跳变问题就出在跳变处。以顺序图为例从第一条消息开始沿着消息箭头一条条读「顾客给系统发提交订单系统给自己发验证登录系统给支付服务发支付请求支付服务给系统返回支付结果系统给顾客返回订单受理结果」。这套叙述里如果有哪个环节读不顺——比如「支付服务直接给顾客返回结果」——说明消息的发送者和接收者关系画错了。如果读到某个环节发现「题目里好像没这一步」说明你多画了一条消息需要删掉。用例图的逆向读法稍有不同只根据图上的参与者和用例把系统功能讲一遍。如果讲到某个用例时需要脑补前置条件而这个条件没有通过 include 或 extend 表达出来那说明关系画漏了。比如你画的用例图里有「取消订单」却没有「提交订单」与它的关联那你无法从图上解释「取消订单」从哪来——这种漏洞正是阅卷人的扣分点。逆向读图法的进阶用法是「角色互换」读图时假设自己完全不熟悉这道题只看图的逻辑能不能自洽。这一步会把注意力从「我记得答案长什么样」拉回到「这张图本身成不成立」。我自己的习惯是每次刷完五道画图题选其中两道做逆向读图读完对着五维自测清单过一遍。整个过程不到十五分钟但正确率的提升比多刷十道题更明显。还有一个针对大集合的收尾习惯把所有做错的画图题标记出来一周后不看答案只看自己错题记录里的题号和题目描述重新拆解重画。这个「重画」的意义在于检验你到底是记住了答案还是真的会建模。说实话UML 的图不是画得越复杂越好而是越「自洽」越好——一张读图读不回到题目的的图画得再满也是白费。希望这套刷题判断方法对你有帮助。把大集合里的画图题按这个节奏吃透一轮考场上的用例图和顺序图基本就是送分题了。本文还有配套的精品资源点击获取