UML试题刷题攻略：用例图与顺序图核心考点与答题模板

简介这是一份UML知识点梳理与典型试题合集主要面向计算机专业学生、软件工程学习者及相关技术人员用于考前冲刺或日常复习中对知识体系的快速查漏补缺。文档从交互图入手详细辨析了顺序图与协作图在时间顺序、空间组织、消息表示等方面的差异和优缺点并延伸至高内聚度、对象间可见性、领域模型、统一过程的阶段划分、增量开发、用况模型等UML重要考点每题均附参考答案与解析便于对照学习。资源共1个doc文件容量仅62KB内容精炼集中适合碎片化时间反复翻阅。截至目前已有11265人学习下载体现出较高的参考价值。通过这套试题读者既能巩固UML各类图表的适用场景也能理解统一建模语言在面向对象分析与设计中的实际应用从而更从容地应对相关考试与面试。1. 刷 UML 试题大集合为什么先从用例图和顺序图下手把 UML 试题大集合这类题目刷透之前先分清主次用例图和顺序图几乎占掉主观题的一半以上而且都是手绘题、改错题、代码补全题的重灾区。身边好几个人在期末考试和面试里把符号背得滚瓜烂熟一看到题目文字还是不会画不是不会 UML而是不会“读题”。这两张图的共同点在于答案不是靠背是靠从文字场景里提取参与者、消息和关系。先把这两个图练熟等于拿下了 UML 试题里性价比最高的一块。这一篇我来把常见考法、答题步骤和判分习惯拆开讲。适合正在准备期末考、软考或开发岗面试的人也适合做课程设计答辩前想快速自查的同学。用例图考的是“系统给谁用、能干什么”顺序图考的是“一次交互里消息怎么走”两题往往共用一段背景描述一道题练熟两图都能通。2. 用例图试题从读题到画图的四个固定步骤拿到一道用例图大题先别急着画椭圆。我一般按四步走第一步圈出所有“人”和“外部系统”第二步圈出所有动词短语第三步判断这些动词短语是独立用例还是某个用例的内部步骤第四步把用例之间的关系用 include、extend、泛化标好。顺序反过来也能画但很容易漏用例或多画伪用例。这套顺序的价值在于参与者决定用例的边界动词决定用例的名字关系决定图的逻辑。只要把前两步做干净后两步就不容易翻车。下面用三道常见考法把每一步展开。2.1 用例图必考关系include、extend 与泛化怎么区分用例图常考的关系只有三种判分点基本都在箭头的虚实和方向。include包含表示主用例每次都必然执行某个公共步骤箭头从主用例指向被包含用例虚线箭头带 标记。extend扩展表示用例在特定条件或异常情况下才触发的可选行为箭头从扩展用例指向基础用例也是虚线带 标记方向经常被画反。泛化是父子关系实线加空心三角参与者之间和用例之间都可以用。常见题面是“下单时必须先登录下单时可使用优惠券”。登录是每次下单都走的公共逻辑所以是 include优惠券是用户可选的追加行为不是每次下单都走所以是 extend。我见过大量答案把这两处画反扣掉一半分。区分时抓住两个信号题面里出现“每次”“必须”“先要”基本是 include出现“可选”“如果”“当……时”“还可以”基本是 extend。另外扩展用例本身依赖基础用例存在但它被触发时基础用例的主流程已经走得差不多了比如支付时突然发现余额不足弹出充值页面这种情况更贴近 extend 的异常分支语义画的时候箭头方向千万不能反。2.2 “图书管理系统”用例图完整答题模板某高校图书馆管理系统需要支持学生和教师借书、还书、续借、预约、查询馆藏。管理员负责录入新书、处理超期罚款。系统在每次借书时先校验读者身份校验失败则拒绝借书。读者还可以在线提交购书建议。这是一道典型的用例图题题面里密集埋了参与者、用例和关系。第一遍读题我习惯在纸上分三栏记参与者栏记学生、教师、管理员用例栏记借书、还书、续借、预约、查询馆藏、录入新书、处理超期罚款、提交购书建议关系栏记“每次借书时先校验身份”这一句。学生和教师都能借还书所以在参与者层面先画一个父参与者“读者”学生、教师分别泛化到它。借书用例要带一个被包含用例“身份校验”因为“每次借书时先校验”是硬性条件。校验失败拒绝借书属于异常分支一般不在用例图上单独画成一个用例因为用例图主要表达功能目标不表达流程细节。如果把“拒绝借书”画成独立用例会被判成粒度错误。答题时除了画图还要附文字说明。常见判分点包括参与者是否漏掉泛化关系是否画到参与者而不是用例include 箭头是否指向“身份校验”是否有画蛇添足的“数据库”“管理员登录”这类伪用例。文字部分我习惯写成“本系统共有读者、管理员两类主要参与者其中读者泛化了学生和教师借书用例包含身份校验其余用例为独立用例”。2.3 用例粒度怎么定才不会丢分一个用例要有“独立交付价值”很多人在同一次考试里一会儿把“登录”画成用例一会儿把“预约图书”整个流程拆成“选择图书”“确认预约”“生成凭证”三个用例粒度忽大忽小。判分时老师看的是一个用例是否对参与者产生了可观察、有意义的完整结果。“登录”对读者来说不是一个业务目标只是进入系统前的门槛所以通常不画成独立用例。“选择图书”也不能单独构成读者借书的目标它只是借书流程里的中间操作所以也不该拆出来。反过来“处理超期罚款”对管理员来说有独立业务价值可以单独成用例。判断粒度我常用一句话删除这个用例后参与者是否还能在系统里完成一件完整的事如果不能说明它更适合作为某个用例的内部步骤或 include 公共步骤。同一道题里不要求粒度完全一致但每个用例都得是“参与者视角下的一件事”而不是系统内部的一个函数。另外用例命名用“动词宾语”比如“查询馆藏”“录入新书”不要用“馆藏查询模块”这种名词短语。3. 顺序图试题消息、生命线与组合片段是判分主战场顺序图大题的判分比用例图更细因为它多了一个时间维。常见评分表里生命线画对给基础分消息顺序每画错一跳扣一项分组合片段用错再扣一项激活条画错续扣。也就是说顺序图不是“大致对就行”而是每一步都对得上题面才能拿高分。很多初学者对顺序图的理解停留在“两个方框之间画箭头”忽略了三个细节每个箭头代表一次消息箭头必须带返回或触发动作生命线上要画激活条表示处理过程占用时间分支和循环必须用组合片段包起来不能靠多个孤立的箭头表达。下面从读题方法开始。3.1 顺序图读题先找“三个点”发起者、接收者、返回路径接到顺序图题我先从题面里圈出三种信息发起交互的外部对象、被调用的内部对象或系统边界、每个动作的接收方。比如“患者选择科室后系统返回医生列表患者再选择医生”这里发起者是患者接收者是系统返回路径是“系统→患者”。顺序图先把生命线竖着排开再进行消息编号。判断生命线时容易犯一个错把题面里的每个名词都画成生命线。常见说法是“系统”只有一条不要拆成“前端系统”“后端系统”“数据库”多条除非题目明确描述了多个独立组件。比如“系统检查号源”只是内部处理直接在系统生命线上画一条自消息就行如果题目说“系统访问数据库中的号源表”那才需要再画一条数据库生命线。返回路径画法的标准在于同步消息用实心三角箭头返回消息用虚线箭头异步消息用开放箭头。这三个箭头的区分在判分表里几乎必有。如果题目描述是“A 调用 BB 返回结果给 A”得画两条消息一条同步调用一条虚线返回如果把返回也画成实线就会被当成新的同步调用直接扣分。3.2 “网上预约挂号”顺序图从场景文本到消息序列患者在网上预约挂号选择科室系统显示医生列表患者选择医生和时间段系统检查号源是否充足若充足系统生成预约记录并向患者发送确认短信若不充足系统返回号源不足提示。这道题的文字本身就带分支适合练 alt 片段。先把参与者“患者”和系统生命线摆好再逐句翻译成消息序列患者→系统选择科室系统→患者返回医生列表患者→系统选择医生和时间段系统→系统检查号源之后进入分支判断。分支画法是用 alt 组合片段包住后续消息片段标题写“号源充足/号源不足”和方括号布尔条件。号源充足这个分支里画“系统→系统生成预约记录”和“系统→患者发送确认短信”号源不足分支里只画“系统→患者返回号源不足提示”。注意三个细节分支条件要写清楚表达式两个分支的返回消息不能画在线条交叉的位置自消息的激活条要额外加高表示处理耗时。如果题目要求体现循环比如“患者可以依次预约多个科室”就在系统生命线外部用一个 loop 组合片段包住整段交互方括号里写“还有科室未选择”。loop 片段里不要再拆出多余的 alt否则图面会很乱。顺序图的阅读顺序是自上而下判分时也会按时间轴逐条对题面文字所以每条消息的序号或顺序本身很重要。3.3 alt、loop、opt 在判分时的边界组合片段是顺序图主观题的送分点也是失分点。alt 表示多分支互斥必须有至少两个分区每个分区带一个条件比如“号源充足/号源不足”。loop 表示循环方括号里写循环条件或最大次数比如“[记录数0]”或“[i5]”。opt 表示可选项只有一个区域条件不满足时整段消息不发生。判分时常见问题有两个。一个是把用户“可看可不看”的操作画成 alt正确做法是画 opt另一个是循环里的条件写不完整只写“循环”两个字没有布尔表达式。条件写法我习惯参考编程语言里的 if 表达式尽量用题面里的原词。判分时老师通常拿题面文字逐句对照片段类型所以描述里出现“如果/否则”至少该用 alt出现“可以”优先用 opt出现“重复”就用 loop。最怕的是这几个片段一个都不画把所有消息平铺在一条时间轴上分支逻辑在图上完全看不出来。4. 从“用例题”到“顺序图题”的推导方法一个三列表格搞定考试和面试里经常出现同一段背景文字先让画用例图再让画顺序图。很多人在两个图之间画出来的功能都对不上用例图里有“还书”顺序图里的消息却叫“确认归还”“更新库存”判分时对不上号。其实这两个图不是孤立知识点用例图的用例名可以逐字变成顺序图的消息名用例之间的关系能够指示顺序图的分支位置。这一章的思路是把顺序图的阅读顺序反过来先列出参与者能触发的事件再列出系统为完成事件所做的每一步动作最后按时间排成消息序列。这套方法本质是把“用例描述”转译成“场景脚本”我的做法是先用三列草稿纸做转译再画图。4.1 用例名是顺序图消息的“动词库”顺序图每条消息都来自某个用例的执行路径。比如用例“借书”在顺序图里必然出现“借书请求”“身份校验”“记录借阅信息”等消息前一个来自参与者视角后两个来自系统处理细节。如果用例图里没有“身份校验”这个 include 用例顺序图里出现“身份校验”消息就属于越级操作会被判成消息来源不明。反向推导也成立如果一道题要求从顺序图反向补全用例图把顺序图每条同步消息的动词提取出来去重后再按参与者视角合并就得到候选用例集。比如顺序图里有“选择医生”“查看排班”“生成预约”合并到用例层就是“预约挂号”一个用例拆成三个反而粒度太碎。用这个思路两个图的答案能保持逻辑一致也方便检查漏项。4.2 “三列场景脚本法”把用例的路径拆成消息表我画顺序图前一定先在草稿纸上画一个三列表列一是步骤序号列二是发送方列三是消息与关键参数。形式如下步骤发送方消息含参数1读者还书请求(读者ID, 图书ID)2系统校验借阅记录(读者ID)3系统计算应还日期与罚款(图书ID)4系统更新库存状态(图书ID)5系统返回还书结果(是否成功)表里的每一行几乎都会变成顺序图里的一条消息或自消息。第 2、3、4 行发送方都是系统表示这些是系统内部处理在顺序图上画成系统生命线上的自消息。只要把这三列表和用例图中的用例对应上顺序图的骨架就已经完成了七成。三列表还有一个好处能提前暴露遗漏的返回消息。比如第 5 行如果漏掉顺序图里“读者”这条生命线就收不到任何反馈判分时一眼就能看出流程没有闭环。我一般写完表后反向再读一遍把每一行按顺序读成一句连贯的话如果读到某个地方逻辑中断就说明那里少了一条消息或一个分支。4.3 异常路径什么时候值得画出分支不是每个异常都要在顺序图里画分支画多了反而把主流程淹没。常见做法是主流程消息画完再用 alt/opt 表达一到两个对业务结果有实质影响的异常分支。比如还书时超期罚款会影响是否生成罚款单这个异常必须画如果只是查询时点击了空白区域这种无关业务结果的交互就不用画。判断异常路径是否值得画我一般用两个标准该异常是否终止或改变了主流程该异常是否会产生新的数据或新的消息。满足其中一条就值得画否则留在文字说明里即可。顺序图的空间有限把 alt 片段用来表达“号源不足”“超期罚款”这类判分点比画一堆碎分支有效得多。5. 刷 UML 题最常翻车的 5 个地方都有对应得分点这一章专门讲我见过的、以及别人反复问我的高频错误。每条都按现象、原因、解决三步写方便刷题时对照自查。如果一道题做错了先别急着看标准答案按这五条逐一排查通常能自己发现扣分点。5.1 把“优惠券”画成 include扩展方向被扣一半分现象题面写“下单时可使用优惠券”答案里基础用例“下单”画了一条虚线箭头指向“使用优惠券”并标 。看起来关系很完整但判分时被扣掉一半。原因把“条件触发”误当成“每次必经”。优惠券只有在用户选择时才会执行不是下单主流程的公共步骤。解决看到“可”“可选”“当用户选择”这类词默认画 箭头从扩展用例“使用优惠券”指向基础用例“下单”。判断口诀include 是“每次都跑”extend 是“看情况跑”。5.2 顺序图返回消息被画成实线箭头现象题目要求“系统返回结果给用户”顺序图里画了一条从系统指向用户的实心三角箭头消息名“返回结果”。看起来没什么问题但标准答案是虚线箭头。原因把调用消息和返回消息混为一谈。实线箭头表示一次新的同步调用虚线箭头表示对之前调用的返回结果传递。解决记住一个对应关系发起调用是一条实心三角箭头接收方处理后的反馈是一条虚线箭头。如果题目明确写“返回”或“响应”一律画虚线。实在分不清就数生命线返回消息不应该导致接收方再产生新的激活条。5.3 激活条长度画错消息还没走完激活条就先断了现象顺序图中系统生命线上的激活条长度只覆盖了第一条消息后续自消息和返回消息都画在激活条之外。这样图面依然能看懂但判分时被判为“处理时序错误”。原因把激活条理解成方框装饰没有意识到它表示接收方处理消息的持续时间。每一段连续处理消息都应该落在同一条激活条内自消息会让激活条延长。解决画完之后做一次检查从每条消息的接收方开始到该消息生成的最后一条返回消息结束中间所有相关消息都要在激活条的可视范围内。自消息的处理时间会额外加高很多标准答案里因此画出台阶状。5.4 用例图里画“登录”“保存”把内部动作用成了用例现象一张用例图里除了“借书”“还书”还列了一排“登录”“身份证校验”“保存借阅记录”“数据库连接”。图看上去信息量很足但被判为伪用例堆积。原因没有区分参与者可见的业务目标与系统内部实现步骤。用例必须对参与者产生可观察的结果“保存记录”是系统内部动作不是参与者的业务目标。解决画出用例前先加一道筛子把每个候选动词短语放到参与者视角去读一次。参与者能直接说出来“我要保存记录”吗基本不会他会说“我要借书”。因此“保存记录”“校验身份”“连接数据库”这类只配当 include 用例或直接不画。5.5 把“数据库”和“订单中心”画成参与者现象题面描述“系统将订单数据写入数据库”答案在用例图左侧把“数据库”画成参与者给它关联了“保存订单”用例右侧把“订单中心”也画成参与者。参与者和外部系统边界全乱了。原因混淆外部系统与内部组件的边界。数据库、消息队列、第三方支付网关中只有题面明确说“外部系统”才算参与者数据库通常是系统内部组件不需要出现在用例图中。解决读题时给“参与者”圈定一个标准它是否独立于系统之外发起交互数据库不会主动发起交互所以不能当参与者一个外部认证中心如果主动发起身份核验那它就可以画成参与者。如果只是系统内部访问最多在顺序图里画一条数据库生命线用例图不画。6. 用 PlantUML 把答案写成文本脚本快速自查用例图和顺序图手绘题做完后往往没有自动判分工具但有一个很实用的自查办法把你的答案改写成 PlantUML 脚本让它生成图。脚本化之后有两个好处一是语法错误会直接报出来相当于逼你把符号关系写严谨二是生成图和你预想的不一致时可以快速定位是关系方向错了还是消息序号错了。6.1 用例图和顺序图的最小脚本模板用例图的最小脚本很简洁适合快速验证 include 和 extend 的箭头方向startuml actor 读者 actor 管理员 读者 -- (借书) 管理员 -- (录入新书) (借书) .. (身份校验) : include (借书) .. (使用优惠券) : extend enduml脚本里..表示虚线箭头用例图 include 和 extend 都靠虚线表达。(借书) .. (身份校验)读作“借书包含身份校验”方向从主用例指向被包含用例(借书) .. (使用优惠券)读作“优惠券扩展借书”方向从扩展用例指向基础用例。两行代码只要方向写错生成出的图马上就能看出来比盯着手绘图找错快得多。顺序图自查用下面的模板把三列表的行直接翻译成消息startuml actor 患者 控制 系统 患者 - 系统 : 选择科室 系统 - 患者 : 返回医生列表 患者 - 系统 : 选择医生和时间段 系统 - 系统 : 检查号源 alt 号源充足 系统 - 系统 : 生成预约记录 系统 - 患者 : 发送确认短信 else 号源不足 系统 - 患者 : 返回号源不足提示 end endumlactor声明参与者“控制”之后接的是普通生命线-是同步消息系统 - 系统是自消息alt/else/end组成分支片段。这个脚本和前面三列表一一对应检查时只需要对着脚本读一遍看有没有消息顺序和题面不一致的地方。6.2 自己给自己出题的三个自检问题如果你暂时没有大量题目可练可以用三个自检问题拿旧题反复验证。第一用例图中的每个用例是否都能回答“参与者用它完成了什么”这个问题回答不出来的就是伪用例。第二顺序图的每条消息是否能从用例描述中找到原文依据找不出的就是编造消息。第三把顺序图从最后一条消息倒着往上读是否能还原出完整的业务场景读不通的地方往往就是漏了分支或返回路径。这套自检方法本身就是变相做题。我习惯每画完一组图就把 PlantUML 脚本存档过几天再生成图重新审一遍而不是画完就忘。以前做模拟项目X的时候我就是靠这个自查习惯在答辩前发现顺序图里少画了一条超期罚款的返回消息现场才没有翻车。多做一道题、多验一次图比背什么标准答案都靠谱希望帮到你。本文还有配套的精品资源点击获取