简介：这是一份《UML系统分析与设计复习试题详解》文档，面向软件工程、信息系统等专业准备相关课程考试或考研复习的读者。内容围绕关联多重度、类图与组合关系、顺序图与协作图对比、高内聚、UML图的作用与四种基本关系等核心考点，以题目+答案+解析的形式梳理，并包含客户与订单、电话用户用例、POS销售场景等典型实例，便于查漏补缺和考前强化。资源包含1个doc文档，整体仅132KB，内容精炼、重点集中，可直接打印或按章节浏览。该资料发布至今已有404人学习，适合希望在较短时间内系统回顾UML分析与设计要点、并对照经典试题巩固理解的初学者和备考者。

1. uml系统分析与设计复习试题，考的其实是“画图逻辑”不是“背图”

如果你正在搜“uml系统分析与设计复习试题”，多半和我当年一样，是期末周、软考报名之后，或者毕设文档写到“系统建模”那一章的前夜。这门课看着是画图，考起来却是另一回事：选择题考概念辨析，大题给一段文字需求，让你补出用例图、类图、时序图或状态图。很多同学背熟了十几种图的定义，一到考场上还是不知道先画哪张、关系线怎么连、箭头往哪指。问题不出在记忆力，而是没把UML图当成一种“表达需求的语法”来练。这篇笔记不按教材目录讲，按复习试题的题型拆：哪些图占分最重、怎么从题干里划词、哪几个细节最容易丢分，最后落到一套考前的自查流程，适合期末考生、软考考生，也适合毕业设计前临时补图的人。

2. 用例图与类图：占分最重的两张图，从题干划词开始练

翻过历年“uml期末考试试题”的人都会有同感：用例图和类图基本各占一道大题，外加一堆选择填空。这两张图画得好不好，直接决定试卷前半段的得分下限。而且它们之间有天然的承上启下关系——用例图描述“系统对外提供什么”，类图描述“系统内部用什么结构实现”，复习时把这两张图串成一条线来练，比单独背图效率高得多。

2.1 从题干划词到用例图：参与者、用例，以及include/extend的判别

用例图的大题通常给一段文字描述，让你补全参与者、用例和关系。我一般用“两步划词法”处理：

第一步，先划动词短语。“注册”“登录”“查询图书”“提交订单”“审核申请”这些都是用例的候选；第二步，再划名词。“用户”“管理员”“游客”这类和系统直接交互的角色，才是参与者候选。

划完之后做三个检查：第一，参与者是“角色”不是人名，写“普通用户”可以，写“张三”就是零分；第二，参与者必须和系统有直接交互，“数据库”“第三方支付接口”这种内部或外部依赖不算参与者；第三，用例名用“动词+名词”，不要写“数据管理”这种名词短语当用例。

关系判别是这里最值得花时间的地方。include和extend是历届考生血泪经验里的重灾区。include是主用例每次执行都要调用的子用例，比如“下单”必然包括“验证库存”；extend是满足条件才发生的可选扩展，比如“下单”在用户有优惠券时才执行“使用优惠券”。判别线索可以直接从题干里抓：出现“系统必须”“需要先”基本是include，出现“如果”“当……时”“可以”基本是extend。

箭头方向也要记死：include从主用例指向子用例，extend从扩展用例指向基础用例。很多人把extend的方向画反，得分点直接清零。下面这张表我复习时贴在书桌前，考试前再看一眼：

画图顺序上，我习惯先画参与者，再画用例，最后补关系线和系统边界框。边界框把用例圈在里面，参与者放在框外，这个细节看似小，批改时很多老师会按“是否理解系统边界”来给分。

2.2 类图画法与六条关系线：空心菱形和实心菱形到底谁“拥有”谁

类图是复习题里分值结构最稳定的题型，通常按类名、属性、方法、关系四块给分。类名的判定和用例划词法一样，高频且独立的名词成类；属性来自题干里“记录”“信息”“包含”后面的名词；方法则从动词短语里抽，比如“借书”对应 borrow()，“计算总价”对应 getTotalPrice()。

可见性符号是选择题和填空题的常客：+ 表示公有，- 表示私有，# 表示受保护，~ 表示包内可见。复习题默认的属性私有、方法公有，除非题干特别说明，否则不要乱改。

关系线是类图翻车最密集的地方。很多同学考前背得住“聚合是空心菱形、组合是实心菱形”，一上考场画出来的全是清一色实线箭头，看着挺整齐，实际上关系语义全丢了。我给自己编了个“三问判别法”，比硬背画法牢靠：

第一问，两个类之间是不是长期持有的引用关系？是，走关联；只是某个方法里临时用一下，走依赖。第二问，是不是“整体-部分”结构？是，再看第三问：部分离开整体后还能不能独立存在？能，画聚合（空心菱形）；不能，画组合（实心菱形）。第三问，是“is-a”继承关系还是“接口实现”？继承画泛化（实线空心三角），实现接口画实现（虚线空心三角）。

复习到这一步，你会发现在“uml类图怎么画”这个问题底下，真正拉开分数差距的不是类找得全不全，而是菱形画得对不对。顺带说一句，设计模式相关的复习题本质也是在考这几条关系线：模式文档里的“面向接口编程”对应实现关系，“组合优于继承”对应聚合/组合关系。关系线画明白了，设计模式大题基本就拿下大半。

2.3 用例转类图的拆题顺序：从“系统需求”到“类、属性、方法、关系”

综合题最常见的考法，是给一段文字需求直接让你画类图。比如复习材料里常出现这样一段描述：“读者登录系统后可以检索图书、提交借阅申请，管理员审核申请后办理借出，系统记录借阅信息。”

我面对这种题的动作是固定六步走：

第一步，划名词，候选类就出来了：读者、图书、借阅申请、管理员、借阅记录。第二步，筛类：能独立表达业务语义的留下，“登录信息”这种被“系统记录”带出的名词先进属性池。第三步，定属性：从题干“记录借阅信息”里能抽出借书日期、应还日期、状态。第四步，补方法：把动词短语改写成方法名，比如“提交借阅申请”对应 submitApplication()，“办理借出”对应 confirmBorrow()。第五步，套关系判别表：读者和借阅记录之间是关联，图书和借阅记录也是关联，借阅申请被管理员处理是依赖。第六步，补可见性，默认私有属性、公有方法。

下面这个抽取结果表可以当作练习模板，做完一道题就照这个结构对照一遍：

如果你在做毕业设计，题目是“基于springboot+vue的非遗文化云展厅设计与实现”这类系统，前期文档里的类图也是这个拆法。先画实体类，再补控制类和边界类，关系线宁少勿错，比强行画一堆依赖要稳。

3. 时序图、活动图与状态图：行为题怎么选图才不会整题跑偏

行为图是选择题和大题的第二落点。很多人的复习策略是“每种图都背一遍定义”，结果题目问“描述订单从创建到完成的状态变化”选错了图。软考uml图试题尤其喜欢在这种地方设陷阱：题干本身不带“图”字，需要你自己判断该用哪张动态图。

3.1 时序图：消息箭头、生命线与激活条，三个最细的得分点

时序图大题通常给一段带明显先后顺序的描述，让你画出对象间的消息交互。画法规范有四条：生命线顶部放对象名，下面拉一条虚线到图底；激活条是生命线上的窄矩形，表示对象正在执行；消息用实线箭头从发送方指向接收方；返回消息用虚线箭头，从接收方回到发送方。

最容易丢分的是三个细节。

第一个是同步和异步的箭头：同步调用用实心箭头，异步消息用开放箭头，很多题里“用户点击登录”和“系统返回结果”就分属这两种，画反了直接扣分。第二个是激活条的长度：激活条从对象收到消息开始，到返回消息结束，而不是从生命线顶端画到底端。第三个是返回消息要不要画虚线箭头：只要题目明确给出了返回值，就要补一条返回虚线；但注意别把“返回结果”画成从发送方指向接收方，方向永远是从接收方回到发送方。

从题干抽取消息序列也有固定套路。圈出“先”“然后”“再”“最后”这些词，把它们连成一条有序消息链。比如“用户提交订单，系统验证库存，然后创建订单，最后返回结果”，对应消息就是 submitOrder() → checkStock() → createOrder() → returnResult()。这个链条就是时序图的时间轴骨架。

我复习时序图时用过最有效的笨办法：先不看题目要求，把对象名写在纸左边，然后从上到下写消息序号，最后才画箭头和激活条。先把先后顺序定死，再补细节，能避免因为图形问题导致整个时间轴错乱。

3.2 活动图与状态图：读懂题干里的“流程”“状态”再下笔

活动图描述的是“一件事怎么做”，状态图描述的是“一个对象处于什么状态、怎么变”。判别其实就一句话：题干里出现“流程”“步骤”“分支”“并发”，优先画活动图；出现“状态”“事件触发”“状态迁移”，优先画状态图。

活动图的画法细节集中在三处：初始节点用实心圆，活动节点用圆角矩形，决策节点用空心菱形；并发分叉和汇合用粗黑线；如果题目里出现多个角色，还要加泳道，把不同角色负责的活动放到各自的泳道里。批改时常见的要求是“活动图必须体现并发”，题干里有“同时”“并行”但没有粗黑线的图，基本不算完整。

状态图的画法规范和活动图刚好形成对照：初始状态是实心圆，终止状态是实心圆外套一个空心圆，这个符号经常被人漏掉；状态用圆角矩形表示，迁移箭头上的标注格式是“事件[条件]/动作”，比如“审核通过[库存>0]/扣减库存”。复习题里让你补全状态图时，往往故意挖掉终止状态或者某个迁移条件，这两处就是得分点。

我见过最典型的翻车案例：题目说“一个订单从创建到完成经历哪些状态”，有人画了一张从上到下的活动图，把“创建订单”“支付”“发货”“完成”排成一串流程。但订单这个对象的状态迁移（待支付、已支付、已发货、已完成）用状态图描述才准确，活动图更适合描述“订单处理流程”这种跨角色的完整业务动作。选图选错了，整道题再规范也拿不到分。

3.3 软考UML图试题的审题顺序：一道题可能同时考两张图

软考风格的题目和期末题差别很大。期末大题通常直接告诉你“请画类图”，软考往往只给一段业务描述，让你判断最适合用什么图描述，甚至一道大题的几个小问分别对应不同图。比如先问“该系统有哪些参与者”，再问“根据描述画出订单相关的类图”，最后问“用时序图描述下单过程”。这种综合题考的不是单图记忆，而是你能不能从同一段文字里抽出不同视图需要的信息。

我的审题顺序就三步。第一步，通读题干，先圈出“流程”“状态”“交互”“顺序”“并发”“事件”这些标签，给题目定性。第二步，看小问数量，单问大概率考选图判断，多问则按用例图、类图、时序图的顺序逐步展开。第三步，留个心眼确认有没有“部署”“接口依赖”相关词，出现这些词才考虑组件图或部署图，没有就绝对不要额外画。

这里的复习优先级我也排过：用例图、类图、时序图、活动图、状态图是绝对主力，组件图（也叫构件图）和部署图属于“了解级”。组件图常考的是接口符号和依赖关系——组件提供接口画小球，依赖接口画半圆，两个组件之间用虚线箭头表示依赖；部署图则关注节点和物理设备。放到毕设文档里，这类图通常是“系统部署架构”那一节的需求，但考试占比远不如前五张。

4. 高频避坑：复习题里反复出现的五个失分点

刷题刷到一定量就会发现，UML复习题的失分点高度集中，翻来覆去就那么几个。下面这五条是我从期末卷子和软考练习题里总结出来的高频坑，每一条都是“现象、原因、解决”三段式，考前对着检查一遍，能少踩一大半雷。

4.1 include和extend画反：可选关系当成必选关系

现象：题干写“用户下单时可以使用优惠券”，你把它画成“下单”include“使用优惠券”，箭头方向也从下单指向优惠券。批改结果：关系类型错误，整条连线不得分。

原因：判断关系时只看到“下单和优惠券有关系”，没判断“是不是每次下单都必须执行”。include的本质是“主用例执行流程中必然包含的子步骤”，比如“下单”必然“验证库存”；而“使用优惠券”只是用户在下单过程里“可以”触发的一个可选分支，语义上属于扩展。

解决：看到“如果”“当……时”“可以”“可选”这些词，一律先考虑extend；看到“必须”“需要先”“每次都”再考虑include。方向也别混：include箭头从主用例指向子用例，extend箭头从扩展用例指向基础用例。把这两条刻进脑子里，比多刷十道题都管用。

4.2 类图关系线只用一种画法：看起来全对，得分全丢

现象：一张类图画了七八条连线，全部是普通实线箭头，没有一条虚线、没有空心菱形也没有实心菱形。乍一看类都找全了，但每一组关系都没表达对。

原因：考前背了六种关系的名字，但没背对应的图形画法，到了考场一紧张，“聚合是空心菱形、组合是实心菱形”这种记忆直接失效，于是统一用“箭头实线”糊弄过去。

解决：考试进场后的前两分钟，如果允许，在草稿纸角落默画一遍六种关系图例：泛化是实线空心三角，实现是虚线空心三角，依赖是虚线箭头，关联是实线箭头，聚合是实线加空心菱形，组合是实线加实心菱形。画完再开始做题，后面所有的类图关系都照这个图例填。这个方法我用了两年，没有再在关系线上丢过分。

4.3 时序图把激活条画满整条生命线：对象“存活”不等于“激活”

现象：一张时序图里，每个对象名下都有一条从头到尾的粗矩形，消息箭头直接指向这条粗矩形。直觉上“对象一直在工作”，实际上完全看不出消息触发的执行区间。

原因：把“对象在整个交互过程中存在”和“对象在某段时间内被激活执行”混为一谈。生命线表示对象存活，激活条表示对象正在执行某个操作，两者不是一个维度。

解决：激活条只覆盖“对象收到消息开始，到返回消息为止”的时间段。画的时候先画消息链，再用窄矩形框住执行区间。复习时给自己设一个检查项：每一条激活条都必须有明确的起点消息和终点返回消息，做不到就说明时间轴理解错了。

4.4 活动图画成流程图：泳道和并发分叉没体现

现象：活动图画出来和程序流程图长得一样，方框从上到下串成一串，没有泳道，没有粗黑分叉汇合线，也没有决策节点。内容没错，但不像UML活动图。

原因：把UML活动图的语义降级成了普通流程图，只关注步骤先后，忽略了活动图最强的两个表达力：泳道表达角色职责边界，粗黑线表达并发分叉与汇合。

解决：题干一旦出现“并行”“同时”“可以由不同角色分别处理”，必须画粗黑分叉和汇合；一旦出现两个以上角色，就得用泳道把活动划分到对应角色下面。日常练习时可以拿一段“订单处理流程”反复画三遍：第一遍画无泳道版本，第二遍加泳道，第三遍把“支付通知”和“库存扣减”改成并发分叉。画到第三遍，活动图基本就过关了。

4.5 状态图漏画初始状态与终止状态：一张图直接判不完整

现象：状态图里只有一排圆角矩形和箭头，既没有实心圆起始点，也没有“实心圆套空心圆”的终止点。问就是“忘了”。

原因：状态图的主要精力放在状态迁移逻辑上，起始点和终止点属于“结构性符号”，画图时天然容易被忽略。但正是这两个符号，让状态图成为有边界的状态机，而不是一张无头无尾的跳转图。

解决：每次画完状态图，按顺序检查三件事：第一，左上角有没有初始状态实心圆；第二，右下角有没有终止状态符号；第三，每个分支状态的迁移箭头是否都有出口。漏掉任何一个，直接按“图不完整”处理。这个检查习惯我后来带到了工作里的状态机设计评审中，依然管用。

5. 验证一套图是否完整：考前三天我最常用的自查顺序

复习到最后一轮，不是继续刷题，而是练“看图找残缺”的能力。我考前三天会做一件事：把手边做过的每一道复习题答案当作“残缺图”来检查——故意涂掉关系线或某个状态，然后自己补回来。这个过程比重复做题更能暴露盲区，因为它逼着你从“画得出来”升级到“看得出哪里不对”。

自查时就按五步走：审题划词，先圈出动词名词和“流程/状态/交互”标记；选图，对照题目标签决定用例图、类图还是行为图；画骨架，先搭类、生命线或活动节点，不碰细节；补关系，把include/extend、六种关系线、消息箭头逐项补全；查规范，最后检查可见性符号、菱形实心空心、激活条区间、起始和终止状态。这个顺序固定下来，每张图不超过十分钟就能完成一轮完整校验。

下面这张清单是我进考场前最后背的一页纸，也送给正在复习的你：

说句掏心窝的话，我当年期末考就吃过“选错图”的亏：题干描述订单从待支付到已完成的变化过程，我条件反射画了时序图，因为满脑子都是“先发生什么、后发生什么”。交卷后翻书才反应过来，“状态”两个字明晃晃摆在那里，该用状态图。那次之后我养成了个习惯，拿到任何场景描述先强迫自己写出图名再动笔画，写不出来的宁可先空着。这个习惯让我后来做项目设计文档也少走了很多弯路。

UML复习题说到底是“需求到图”的翻译训练，图例和符号是语法，题干里的每个名词、动词、条件词才是语义来源。把划词、选图、补关系这三件事练成肌肉记忆，各类题型都不会太慌。希望帮到你。

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