简介这是一份《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的方向画反得分点直接清零。下面这张表我复习时贴在书桌前考试前再看一眼题干关键词UML判别箭头方向必须、需要先、每次include主用例 → 子用例如果、可选、当…时extend扩展用例 → 基础用例是…的一种、继承generalize子用例 → 父用例画图顺序上我习惯先画参与者再画用例最后补关系线和系统边界框。边界框把用例圈在里面参与者放在框外这个细节看似小批改时很多老师会按“是否理解系统边界”来给分。2.2 类图画法与六条关系线空心菱形和实心菱形到底谁“拥有”谁类图是复习题里分值结构最稳定的题型通常按类名、属性、方法、关系四块给分。类名的判定和用例划词法一样高频且独立的名词成类属性来自题干里“记录”“信息”“包含”后面的名词方法则从动词短语里抽比如“借书”对应 borrow()“计算总价”对应 getTotalPrice()。可见性符号是选择题和填空题的常客 表示公有- 表示私有# 表示受保护~ 表示包内可见。复习题默认的属性私有、方法公有除非题干特别说明否则不要乱改。关系线是类图翻车最密集的地方。很多同学考前背得住“聚合是空心菱形、组合是实心菱形”一上考场画出来的全是清一色实线箭头看着挺整齐实际上关系语义全丢了。我给自己编了个“三问判别法”比硬背画法牢靠第一问两个类之间是不是长期持有的引用关系是走关联只是某个方法里临时用一下走依赖。第二问是不是“整体-部分”结构是再看第三问部分离开整体后还能不能独立存在能画聚合空心菱形不能画组合实心菱形。第三问是“is-a”继承关系还是“接口实现”继承画泛化实线空心三角实现接口画实现虚线空心三角。关系画法典型例子依赖虚线箭头控制器临时调用服务类关联实线可带方向用户持有订单列表聚合实线 空心菱形班级与学生班级解散学生还在组合实线 实心菱形订单与订单项订单删除订单项无意义泛化实线 空心三角Student 继承 User实现虚线 空心三角OrderService 实现 IOrderService复习到这一步你会发现在“uml类图怎么画”这个问题底下真正拉开分数差距的不是类找得全不全而是菱形画得对不对。顺带说一句设计模式相关的复习题本质也是在考这几条关系线模式文档里的“面向接口编程”对应实现关系“组合优于继承”对应聚合/组合关系。关系线画明白了设计模式大题基本就拿下大半。2.3 用例转类图的拆题顺序从“系统需求”到“类、属性、方法、关系”综合题最常见的考法是给一段文字需求直接让你画类图。比如复习材料里常出现这样一段描述“读者登录系统后可以检索图书、提交借阅申请管理员审核申请后办理借出系统记录借阅信息。”我面对这种题的动作是固定六步走第一步划名词候选类就出来了读者、图书、借阅申请、管理员、借阅记录。第二步筛类能独立表达业务语义的留下“登录信息”这种被“系统记录”带出的名词先进属性池。第三步定属性从题干“记录借阅信息”里能抽出借书日期、应还日期、状态。第四步补方法把动词短语改写成方法名比如“提交借阅申请”对应 submitApplication()“办理借出”对应 confirmBorrow()。第五步套关系判别表读者和借阅记录之间是关联图书和借阅记录也是关联借阅申请被管理员处理是依赖。第六步补可见性默认私有属性、公有方法。下面这个抽取结果表可以当作练习模板做完一道题就照这个结构对照一遍类名关键属性关键方法关系读者姓名、读者证号login()、submitApplication()关联借阅记录图书书名、ISBN、馆藏量search()关联借阅记录借阅记录借书日期、应还日期、状态create()、update()关联读者与图书管理员工号、权限级别review()、confirmBorrow()依赖借阅申请如果你在做毕业设计题目是“基于springbootvue的非遗文化云展厅设计与实现”这类系统前期文档里的类图也是这个拆法。先画实体类再补控制类和边界类关系线宁少勿错比强行画一堆依赖要稳。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、六种关系线、消息箭头逐项补全查规范最后检查可见性符号、菱形实心空心、激活条区间、起始和终止状态。这个顺序固定下来每张图不超过十分钟就能完成一轮完整校验。下面这张清单是我进考场前最后背的一页纸也送给正在复习的你图类型必查元素用例图参与者是否在框外、include/extend方向、用例是否为动词短语类图可见性符号、菱形实心/空心、泛化三角朝向、属性方法完整时序图激活条区间、返回消息虚线、同步消息实心箭头活动图初始/终止节点、并发分叉粗黑线、泳道角色划分状态图初始状态、终止状态、迁移事件标注、分支出口说句掏心窝的话我当年期末考就吃过“选错图”的亏题干描述订单从待支付到已完成的变化过程我条件反射画了时序图因为满脑子都是“先发生什么、后发生什么”。交卷后翻书才反应过来“状态”两个字明晃晃摆在那里该用状态图。那次之后我养成了个习惯拿到任何场景描述先强迫自己写出图名再动笔画写不出来的宁可先空着。这个习惯让我后来做项目设计文档也少走了很多弯路。UML复习题说到底是“需求到图”的翻译训练图例和符号是语法题干里的每个名词、动词、条件词才是语义来源。把划词、选图、补关系这三件事练成肌肉记忆各类题型都不会太慌。希望帮到你。本文还有配套的精品资源点击获取