简介面向软件工程与UML建模学习者的试题归纳包聚焦用例图、顺序图、协作图等核心考点适合备考复习、考前自测与知识点梳理。内容涵盖交互图对比、高内聚度、UML各类图的作用、对象可见性、领域模型、统一过程阶段、用况与增量开发等问答与选择题帮助读者在刷题中巩固建模概念。整套资料为单份doc文档压缩包大小62KB文件结构简洁便于直接打开阅读或打印练习。目前已有一万一千余人学习下载属于高频使用的UML复习材料。文档以问答题和选择题形式编排答案附于题后既有概念辨析也有实际设计方法例如顺序图与协作图的时间/空间组织差异、UP各阶段任务等可直接作为UML课程期末或自学自测的手册。1. 这个“uml试题大集合”到底解决什么问题备考者最缺的不是题是踩分框架备考软考中级、系统分析师或者研究生专业课很多人一翻开“uml试题大集合”就被用例图和顺序图劝退用例图里 extension、include 箭头分不清顺序图里消息箭头画反一条就白丢分。做过这类题的人都知道它考的不是“会不会画图”而是能不能在有限时间里把题干里的业务动作翻译成规范建模元素并且和评分点的关键词一一对上。我习惯把这类题叫作“带约束的翻译题”需求文本是输入UML 规范是语法答案就是你能拿到的分数。这篇文章不打算给你几百道题堆着刷而是把用例图和顺序图背后最常考的考点拆开给你一套能直接用的答题路径外加我这些年带学员踩过的真实坑。适合三类人软考中级临时抱佛脚的、系统分析师需要书面建模的、以及面试前刷 UMI 建模题的技术人。2. 用例图考点怎么拆从“看图说话”到“按题画图”的答题路径2.1 用例图四个必拿分要素参与者、用例、关系、边界一张用例图阅卷老师眼里只有四个得分块。第一是参与者Actor它一定是系统外部的角色可以是人、外部系统或硬件设备。第二是用例Use Case描述的是参与者通过系统完成的一个“可识别的业务目标”不是系统内部的一个功能步骤。第三是关系包括关联、include、extend、泛化四种。第四是系统边界用一个矩形框把系统内部用例圈起来参与者永远在框外。很多新手把“保存文件”“打印报表”写成一个用例这就是粒度错了。我一般会让学员先问一句“这个动作参与者能直接向系统发起并且得到一个完整业务结果吗”能才能用例不能只是用例内部的一步。比如“删除文件”是一个完整操作可以作用例“验证登录信息”通常不是独立用例因为用户并没有“验证信息”这个业务目标它更像是访问其他用例前的一个公共步骤。边界问题也同样关键参与者若被画进系统框里等于告诉阅卷老师你没搞懂内外部概念这一题基本就告别高分了。2.2 题干里哪句话对应哪种关系include/extend/泛化的判定口诀include 和 extend 是考生丢分的重灾区。我的判定口诀很简单include 是“不做完这件事主用例就没法收场”extend 是“做完主用例之后偶尔还想再加点戏”。举例来说“下单”用例必须包含“库存扣减”吗不一定有些系统先下单后扣库存。但如果业务规则要求“下单时必须校验库存”那“库存校验”就是“下单”的 include。反过来“下单”完成后如果用户有会员身份系统额外赠送积分这个“赠积分”是 extension不是每次下单都发生而且它不影响主流程成功与否。泛化关系则容易和 include 混淆。泛化是“父用例/子用例”的关系子用例继承父用例的行为并可以覆盖它比如“支付”是父用例“扫码支付”和“余额支付”就是子用例。注意子用例本身必须是完整的业务目标而不是父用例的可选步骤。另外参与者之间也能有泛化比如“管理员”是“普通用户”的子类那么管理员能做的用例普通用户不一定能做。做题时凡是看到“有管理员和普通用户两种角色”先考虑参与者泛化看到“必须调用”“总是需要”这类词优先 include看到“当……时”“如果……则额外”这类词优先 extend。2.3 按题画用例图的五步操作法含示例答案结构我把画用例图的答题过程固定成五步照着走不容易漏分。假设题干是“某在线商城支持普通用户注册、登录、浏览商品、下单、取消订单、使用优惠券支付管理员可以上架商品、处理退款。用户下单时必须经过身份验证付款时如果使用优惠券则自动计算折扣。”我们拆解一遍。第一步圈参与者。题目里的角色名词就是候选参与者普通用户、管理员。如果出现“微信支付系统”“物流系统”这类外部系统它们也是参与者。第二步圈动词短语找业务目标。用户侧注册、登录、浏览商品、下单、取消订单、使用优惠券支付管理员侧上架商品、处理退款。第三步判定关系。题干明确说了“下单时必须经过身份验证”所以“身份验证”是“下单”的 include当然这里更合理的建模是登录为前置条件但题目既然强调必须就按 include 写。“使用优惠券支付”是在支付时“如果使用”所以它是“下单”或“支付”的 extend。第四步画边界。把所有用例放进一个矩形框框左上角写系统名“在线商城系统”参与者全部放框外用直线连接关联。第五步写关系箭头。include 是虚线箭头指向被包含用例箭头处标includeextend 也是虚线箭头由扩展用例指向基础用例标extend。下面是一个可以照抄的文字版答案结构方便你在答题卷上排版用例图答案要点 - 参与者普通用户、管理员 - 系统边界在线商城系统框内为用例 - 用例列表 普通用户注册、登录、浏览商品、下单、取消订单、使用优惠券支付 管理员上架商品、处理退款 - 关系 「下单」--include--「身份验证」 「使用优惠券支付」--extend--「下单」 - 加分项若管理员是普通用户的泛化角色可画参与者泛化箭头。注意如果题干没有显式说明“必须”“总是”不要自己乱加 include。阅卷标准通常会写“关系类型正确给 2 分错误一处扣 1 分”这行字是血泪教训。3. 顺序图考点怎么拆把“谁在什么时候调谁”写成可打分的时间线3.1 顺序图的五个标准件对象、生命线、激活、消息、返回顺序图是动态图里考得最频繁的。一个标准顺序图必须有五样东西对象框Object、生命线Lifeline、激活条Activation、消息箭头Message、返回箭头Return。对象框写在图最顶部格式是对象名:类名比如user:User如果不知道对象名至少写:User但只写“用户”不写类名会扣分。生命线是从对象向下延伸的一条虚线表示对象在时间上的存活。激活条是生命线上覆盖的细长矩形表示对象正在执行某个操作它得有明确的起点和终点。消息箭头分为实线实心箭头请求/调用消息、实线空心箭头异步消息、虚线箭头返回消息。很多人在顺序图里把返回消息画成实线这是最常见的翻车点。还有一个考点激活条必须对应消息的接收和处理时间如果你发送一个同步消息那么接收方激活条从收到消息开始一直持续到它发出返回消息为止。自调用对象给自己发消息时激活条会在自身生命线上嵌套一个小激活条切勿漏画。3.2 从用例到顺序图场景描述转消息序列的映射技巧考试最常见的材料是一段文字描述比如“用户登录后系统校验用户信息读取用户购物车然后生成订单。”拿到这种描述先别急着画按三个步骤处理。第一步找出参与对象。句子里的名词用户、系统、购物车、订单。这里要区分边界系统是一个大对象还是拆成“登录校验器”“订单服务”原则上按题干出现的业务组件拆别拍脑袋过度拆。第二步按时间顺序把动词排成消息。登录消息user 请求登录系统回校验用户信息然后系统读取购物车最后系统创建订单。注意一条消息必须有发送方和接收方不能凭空出现一个“校验用户信息”横跨在图纸中央。第三步画返回消息。每次同步调用之后接收方要返回结果比如校验结果、购物车数据、订单创建成功。很多学员把返回消息全画在同一时间点忽略了每个操作持续的时间。我给学员的映射技巧把文字描述改成“谁 做什么 告诉谁”的句式。例如“系统校验用户信息”不是一条消息而是“用户 发送 登录请求 给 系统”后系统内部执行校验校验完成后返回结果给用户。这样改写后消息顺序自然就清晰了。这个环节不能省直接对着原文画十条消息漏三条是常事。3.3 顺序图答题的边界问题要不要画循环/分支/异步很多试题要求“画出关键消息即可不用覆盖所有异常分支”。但题目往往会有一句“如果库存不足则拒绝下单”这时候就需要分支表示。顺序题里的分支推荐标准做法是使用组合片段Combined Fragment常见的有alt表示互斥分支loop表示循环opt表示可选。答题时在生命线旁边画一根虚线框左上角写alt虚线把两条分支隔开每条分支里写各自的消息序列。那么到底画不画异步消息判断标准只有一个发送方发出消息后是否需要等待响应才能继续。如果不需要等待用实线空心箭头表示异步。软考级别的题目里异步消息很少作为主考点但如果题干出现“消息队列”“异步通知”这些词你就要主动把对应消息画成异步箭头。另外循环片段不要滥用。题目说“用户多次输入密码”才画 loop别把普通消息排列也包进循环里这会画蛇添足扣卷面分。我的做法是先用文字列出消息清单再判断哪些消息存在循环/分支关系最后才上图这个过程能避免“画到一半发现少一层激活”的尴尬。4. 软考与系统分析师真题的常见出题套路题型分类与答题模板4.1 试题的三种典型问法补全、改错、从需求建模刷过历年真题你就会发现用例图和顺序图的题目翻来覆去就三种问法。第一种是“补全”给出一个残缺的图让你补充用例关系、消息序号或缺失的对象。这种题最容易拿分因为空白处有限你要做的就是先看周边元素推断被遮挡的关系类型。比如某个用例上已经有 include 箭头指向“身份验证”同时旁边还有一个空白箭头那多半是另一个 include 或 extend直接用我的口诀去套。第二种是“改错”题中故意画错几处让你指出并改正。改错题考的是规范细节常见错误包括参与者画在边界框内、include 与 extend 箭头方向画反、顺序图中返回消息用实线箭头、对象只写类名没写实例名等等。改错时不需要重画整图写出“第几处错原因是什么改成什么”就能得分。我见过很多考生把改错题当成重画题来答浪费时间还容易引入新错误。第三种是“从需求建模”给一段业务描述要求绘制完整的用例图或顺序图。这是综合题占分最多需要你把前面两章的五步法完整跑一遍。注意这类题目给出的文字通常包含冗余信息例如“系统采用 B/S 架构”这种描述不影响画图别误把它当成参与者和消息。4.2 可照抄的答题模板用例描述表关系说明顺序图要点这张答题模板是我自己整理出来的适合综合题收尾阶段的检查和答题排版。遇到“请根据需求绘制用例图”时先在草稿纸上列出下面这个表格再去画图能有效防止漏点。用例名参与者前置条件基本事件流备选事件流关系说明下单普通用户用户已登录1.用户提交购买清单2.系统校验库存3.系统生成订单1a.库存不足则提示并终止包含身份验证优惠券支付扩展身份验证普通用户无1.用户输入账号密码2.系统核对2a.失败则重新输入被下单包含顺序图答题则按下面这个模板展开你可以直接把文字版写在试卷空白处阅卷老师能一眼看到得分点。顺序图消息序列 1. 普通用户 - 商城界面 提交订单请求 2. 商城界面 - 订单服务 创建订单(用户ID, 商品清单) 3. 订单服务 - 库存服务 校验库存(商品ID, 数量) 4. 库存服务 -- 订单服务 库存充足 5. 订单服务 - 订单数据库 保存订单 6. 订单数据库 -- 订单服务 保存成功 7. 订单服务 -- 普通用户 下单成功 激活说明商城界面在收到提交请求后进入激活态持续到返回“订单请求已提交”订单服务在第 2 条消息后激活直到返回成功消息。写模板时注意消息序列里的“--”表示返回虚线箭头“-”表示请求实线箭头。如果你手绘务必在箭头上标清消息名和参数参数可以不写全但消息名一定要写。阅卷时消息名每缺一个关键词扣一分这是最冤的丢分方式。4.3 如何用“题感”刷题给自己出一套以题带练的清单刷题不是比数量而是比“题感”。所谓题感就是看到一段需求描述时能快速判断“这里会挖什么考点”。我建议你用下面这个方法自建一个迷你题库把身边熟悉的业务场景写成一句话需求比如“自助咖啡机支持扫码支付支付时如果余额不足则跳转充值”然后要求自己在一分钟内完成两件事列出用例图里的参与者和关系列出顺序图里的消息序列。坚持每天练三个场景一周后你会发现自己对 include/extend 的判断速度明显变快。这个方法的原理是刻意变式训练同一套业务规则今天改成“支付必须调用风控系统”明天改成“支付完成后可发送电子发票”训练的就是关系变化。比你闭眼乱做五十道题更可靠。我在备考软考时用这个方法把历年高频业务场景电商、订票、仓库管理全部自己改写过一遍最后拿到案例分析题时拆需求的速度快很多。5. 避坑用例图和顺序图做题时最常踩的 5 个坑现象→原因→解决5.1 用例粒度写成“系统内部动作”导致用例数目爆炸现象一张用例图里出现“连接数据库”“校验输入”“显示弹窗”这些用例图密密麻麻得分却很低。原因把实现步骤误当成业务目标本质是对“参与者可感知价值”理解不到位。解决每个用例必须回答“参与者通过系统获得了什么完整结果”。连接数据库是“登录”的一个技术步骤参与者感知不到必须合并进主用例。你可以用反推法如果删掉这个用例参与者的业务目标是否依然成立成立就删掉它或者作为 include 子步骤处理。5.2 include 和 extend 方向搞反规范上叫“依赖方向错误”现象题干说“下单时可以使用优惠券”你画成下单 include 使用优惠券或画成使用优惠券 extend 下单的分支方向不对。原因把“可选”当成“必有”或没弄明白 extend 箭头指向谁。解决记住箭头方向——include 箭头由基础用例指向被包含用例下单→身份验证extend 箭头由扩展用例指向基础用例使用优惠券→下单。判断口诀“必须做的事用 include可选加戏用 extend箭头指向被扩展的基准点。”如果题目出现“支付时若使用优惠券则计算折扣”那么“计算折扣”是扩展用例箭头从“计算折扣”指向“支付”。5.3 顺序图里把返回消息画成实线箭头现象消息序列里所有的交互都画成实线箭头阅卷老师看不出哪些是请求哪些是返回。原因很多教材的简化画法会把返回值省略于是考生干脆全部用实线反而丢掉规范分。解决同步请求用实线实心箭头返回结果用带return或消息名加前缀“返回”的虚线箭头。我自己改卷时发现只要出现一条返回消息画成实线整个图的消息逻辑就会混乱直接扣 2 分以上。画完后用笔尖指着每条箭头检查一遍看到从右向左连的箭头默认是返回必须改成虚线。5.4 顺序图对象名称只写“用户”“订单”没有类名现象对象框里写“用户”“系统”没有冒号类名。原因很多人在 break 到备注时只图快忽略了对象框的标准格式是实例名:类名。解决按规范写若实例名不重要也至少写:User表示该对象的类型。顺序图得分点里“对象命名规范”占 12 分这个分白给不拿白不拿。另外如果对象是参与者的代表比如“普通用户”建议写成user:User避免和“用户对象”混淆。5.5 顺序图激活条没有起止消息悬空现象某对象收到消息后激活条一根到底覆盖了所有后续消息或者根本没有激活条。原因对“激活表示对象执行操作的时间段”理解不到位把每个消息当成独立事件没有连贯性。解决每次同步请求到达某对象时该对象生命线上开始一个激活条直到这条消息的返回消息发出激活条才结束。自调用、回调时激活条要嵌套。检查方法从图中自上而下找每一条消息若消息有接收方且无返回则接收方激活至少持续到消息序列末尾。悬空消息等于告诉阅卷老师你还没理解生命周期。6. 最后再教你一手用“事件流走查法”验证你的顺序图顺便把答案变成面试谈资顺序图画完后我最推荐做一件看似多余实则救命的事把消息序列用自然语言复述成一段连贯的用户故事我称之为“事件流走查法”。你不需要在任何工具里画直接在草稿纸上顺着消息序号往下念“用户提交订单请求商城界面收到后调用订单服务订单服务再调用库存服务库存服务返回充足订单服务保存订单并返回成功……”念到哪卡住哪有问题。卡住的地方通常是三种情况之一某个消息没有接收方某个对象收到消息却没有后续动作返回消息和请求消息对不上。我每次带学员模拟测试凡是用这个方法走查过一遍的人正确率能提高两成因为很多规范问题不是画图时发现的而是在“讲故事”时逻辑漏洞自己就跳出来了。这个方法还有一个额外收益系统分析师有面试或论文答辩环节时你随时能把一张静态顺序图讲成一条清晰的业务事件流。比背概念更有说服力。我自己的习惯是每画完一张图至少用两分钟做这个走查坚持二十张图之后你基本能做到“落笔前先在脑子里跑一遍事件流”。说到底UML 试题考的是你有没有用模型思考业务的能力这个能力不是靠背箭头含义得来的是靠一遍遍把模型翻译成语言练出来的。希望帮到你。本文还有配套的精品资源点击获取 UML试题高分攻略：用例图与顺序图考点拆解与避坑指南
简介面向软件工程与UML建模学习者的试题归纳包聚焦用例图、顺序图、协作图等核心考点适合备考复习、考前自测与知识点梳理。内容涵盖交互图对比、高内聚度、UML各类图的作用、对象可见性、领域模型、统一过程阶段、用况与增量开发等问答与选择题帮助读者在刷题中巩固建模概念。整套资料为单份doc文档压缩包大小62KB文件结构简洁便于直接打开阅读或打印练习。目前已有一万一千余人学习下载属于高频使用的UML复习材料。文档以问答题和选择题形式编排答案附于题后既有概念辨析也有实际设计方法例如顺序图与协作图的时间/空间组织差异、UP各阶段任务等可直接作为UML课程期末或自学自测的手册。1. 这个“uml试题大集合”到底解决什么问题备考者最缺的不是题是踩分框架备考软考中级、系统分析师或者研究生专业课很多人一翻开“uml试题大集合”就被用例图和顺序图劝退用例图里 extension、include 箭头分不清顺序图里消息箭头画反一条就白丢分。做过这类题的人都知道它考的不是“会不会画图”而是能不能在有限时间里把题干里的业务动作翻译成规范建模元素并且和评分点的关键词一一对上。我习惯把这类题叫作“带约束的翻译题”需求文本是输入UML 规范是语法答案就是你能拿到的分数。这篇文章不打算给你几百道题堆着刷而是把用例图和顺序图背后最常考的考点拆开给你一套能直接用的答题路径外加我这些年带学员踩过的真实坑。适合三类人软考中级临时抱佛脚的、系统分析师需要书面建模的、以及面试前刷 UMI 建模题的技术人。2. 用例图考点怎么拆从“看图说话”到“按题画图”的答题路径2.1 用例图四个必拿分要素参与者、用例、关系、边界一张用例图阅卷老师眼里只有四个得分块。第一是参与者Actor它一定是系统外部的角色可以是人、外部系统或硬件设备。第二是用例Use Case描述的是参与者通过系统完成的一个“可识别的业务目标”不是系统内部的一个功能步骤。第三是关系包括关联、include、extend、泛化四种。第四是系统边界用一个矩形框把系统内部用例圈起来参与者永远在框外。很多新手把“保存文件”“打印报表”写成一个用例这就是粒度错了。我一般会让学员先问一句“这个动作参与者能直接向系统发起并且得到一个完整业务结果吗”能才能用例不能只是用例内部的一步。比如“删除文件”是一个完整操作可以作用例“验证登录信息”通常不是独立用例因为用户并没有“验证信息”这个业务目标它更像是访问其他用例前的一个公共步骤。边界问题也同样关键参与者若被画进系统框里等于告诉阅卷老师你没搞懂内外部概念这一题基本就告别高分了。2.2 题干里哪句话对应哪种关系include/extend/泛化的判定口诀include 和 extend 是考生丢分的重灾区。我的判定口诀很简单include 是“不做完这件事主用例就没法收场”extend 是“做完主用例之后偶尔还想再加点戏”。举例来说“下单”用例必须包含“库存扣减”吗不一定有些系统先下单后扣库存。但如果业务规则要求“下单时必须校验库存”那“库存校验”就是“下单”的 include。反过来“下单”完成后如果用户有会员身份系统额外赠送积分这个“赠积分”是 extension不是每次下单都发生而且它不影响主流程成功与否。泛化关系则容易和 include 混淆。泛化是“父用例/子用例”的关系子用例继承父用例的行为并可以覆盖它比如“支付”是父用例“扫码支付”和“余额支付”就是子用例。注意子用例本身必须是完整的业务目标而不是父用例的可选步骤。另外参与者之间也能有泛化比如“管理员”是“普通用户”的子类那么管理员能做的用例普通用户不一定能做。做题时凡是看到“有管理员和普通用户两种角色”先考虑参与者泛化看到“必须调用”“总是需要”这类词优先 include看到“当……时”“如果……则额外”这类词优先 extend。2.3 按题画用例图的五步操作法含示例答案结构我把画用例图的答题过程固定成五步照着走不容易漏分。假设题干是“某在线商城支持普通用户注册、登录、浏览商品、下单、取消订单、使用优惠券支付管理员可以上架商品、处理退款。用户下单时必须经过身份验证付款时如果使用优惠券则自动计算折扣。”我们拆解一遍。第一步圈参与者。题目里的角色名词就是候选参与者普通用户、管理员。如果出现“微信支付系统”“物流系统”这类外部系统它们也是参与者。第二步圈动词短语找业务目标。用户侧注册、登录、浏览商品、下单、取消订单、使用优惠券支付管理员侧上架商品、处理退款。第三步判定关系。题干明确说了“下单时必须经过身份验证”所以“身份验证”是“下单”的 include当然这里更合理的建模是登录为前置条件但题目既然强调必须就按 include 写。“使用优惠券支付”是在支付时“如果使用”所以它是“下单”或“支付”的 extend。第四步画边界。把所有用例放进一个矩形框框左上角写系统名“在线商城系统”参与者全部放框外用直线连接关联。第五步写关系箭头。include 是虚线箭头指向被包含用例箭头处标includeextend 也是虚线箭头由扩展用例指向基础用例标extend。下面是一个可以照抄的文字版答案结构方便你在答题卷上排版用例图答案要点 - 参与者普通用户、管理员 - 系统边界在线商城系统框内为用例 - 用例列表 普通用户注册、登录、浏览商品、下单、取消订单、使用优惠券支付 管理员上架商品、处理退款 - 关系 「下单」--include--「身份验证」 「使用优惠券支付」--extend--「下单」 - 加分项若管理员是普通用户的泛化角色可画参与者泛化箭头。注意如果题干没有显式说明“必须”“总是”不要自己乱加 include。阅卷标准通常会写“关系类型正确给 2 分错误一处扣 1 分”这行字是血泪教训。3. 顺序图考点怎么拆把“谁在什么时候调谁”写成可打分的时间线3.1 顺序图的五个标准件对象、生命线、激活、消息、返回顺序图是动态图里考得最频繁的。一个标准顺序图必须有五样东西对象框Object、生命线Lifeline、激活条Activation、消息箭头Message、返回箭头Return。对象框写在图最顶部格式是对象名:类名比如user:User如果不知道对象名至少写:User但只写“用户”不写类名会扣分。生命线是从对象向下延伸的一条虚线表示对象在时间上的存活。激活条是生命线上覆盖的细长矩形表示对象正在执行某个操作它得有明确的起点和终点。消息箭头分为实线实心箭头请求/调用消息、实线空心箭头异步消息、虚线箭头返回消息。很多人在顺序图里把返回消息画成实线这是最常见的翻车点。还有一个考点激活条必须对应消息的接收和处理时间如果你发送一个同步消息那么接收方激活条从收到消息开始一直持续到它发出返回消息为止。自调用对象给自己发消息时激活条会在自身生命线上嵌套一个小激活条切勿漏画。3.2 从用例到顺序图场景描述转消息序列的映射技巧考试最常见的材料是一段文字描述比如“用户登录后系统校验用户信息读取用户购物车然后生成订单。”拿到这种描述先别急着画按三个步骤处理。第一步找出参与对象。句子里的名词用户、系统、购物车、订单。这里要区分边界系统是一个大对象还是拆成“登录校验器”“订单服务”原则上按题干出现的业务组件拆别拍脑袋过度拆。第二步按时间顺序把动词排成消息。登录消息user 请求登录系统回校验用户信息然后系统读取购物车最后系统创建订单。注意一条消息必须有发送方和接收方不能凭空出现一个“校验用户信息”横跨在图纸中央。第三步画返回消息。每次同步调用之后接收方要返回结果比如校验结果、购物车数据、订单创建成功。很多学员把返回消息全画在同一时间点忽略了每个操作持续的时间。我给学员的映射技巧把文字描述改成“谁 做什么 告诉谁”的句式。例如“系统校验用户信息”不是一条消息而是“用户 发送 登录请求 给 系统”后系统内部执行校验校验完成后返回结果给用户。这样改写后消息顺序自然就清晰了。这个环节不能省直接对着原文画十条消息漏三条是常事。3.3 顺序图答题的边界问题要不要画循环/分支/异步很多试题要求“画出关键消息即可不用覆盖所有异常分支”。但题目往往会有一句“如果库存不足则拒绝下单”这时候就需要分支表示。顺序题里的分支推荐标准做法是使用组合片段Combined Fragment常见的有alt表示互斥分支loop表示循环opt表示可选。答题时在生命线旁边画一根虚线框左上角写alt虚线把两条分支隔开每条分支里写各自的消息序列。那么到底画不画异步消息判断标准只有一个发送方发出消息后是否需要等待响应才能继续。如果不需要等待用实线空心箭头表示异步。软考级别的题目里异步消息很少作为主考点但如果题干出现“消息队列”“异步通知”这些词你就要主动把对应消息画成异步箭头。另外循环片段不要滥用。题目说“用户多次输入密码”才画 loop别把普通消息排列也包进循环里这会画蛇添足扣卷面分。我的做法是先用文字列出消息清单再判断哪些消息存在循环/分支关系最后才上图这个过程能避免“画到一半发现少一层激活”的尴尬。4. 软考与系统分析师真题的常见出题套路题型分类与答题模板4.1 试题的三种典型问法补全、改错、从需求建模刷过历年真题你就会发现用例图和顺序图的题目翻来覆去就三种问法。第一种是“补全”给出一个残缺的图让你补充用例关系、消息序号或缺失的对象。这种题最容易拿分因为空白处有限你要做的就是先看周边元素推断被遮挡的关系类型。比如某个用例上已经有 include 箭头指向“身份验证”同时旁边还有一个空白箭头那多半是另一个 include 或 extend直接用我的口诀去套。第二种是“改错”题中故意画错几处让你指出并改正。改错题考的是规范细节常见错误包括参与者画在边界框内、include 与 extend 箭头方向画反、顺序图中返回消息用实线箭头、对象只写类名没写实例名等等。改错时不需要重画整图写出“第几处错原因是什么改成什么”就能得分。我见过很多考生把改错题当成重画题来答浪费时间还容易引入新错误。第三种是“从需求建模”给一段业务描述要求绘制完整的用例图或顺序图。这是综合题占分最多需要你把前面两章的五步法完整跑一遍。注意这类题目给出的文字通常包含冗余信息例如“系统采用 B/S 架构”这种描述不影响画图别误把它当成参与者和消息。4.2 可照抄的答题模板用例描述表关系说明顺序图要点这张答题模板是我自己整理出来的适合综合题收尾阶段的检查和答题排版。遇到“请根据需求绘制用例图”时先在草稿纸上列出下面这个表格再去画图能有效防止漏点。用例名参与者前置条件基本事件流备选事件流关系说明下单普通用户用户已登录1.用户提交购买清单2.系统校验库存3.系统生成订单1a.库存不足则提示并终止包含身份验证优惠券支付扩展身份验证普通用户无1.用户输入账号密码2.系统核对2a.失败则重新输入被下单包含顺序图答题则按下面这个模板展开你可以直接把文字版写在试卷空白处阅卷老师能一眼看到得分点。顺序图消息序列 1. 普通用户 - 商城界面 提交订单请求 2. 商城界面 - 订单服务 创建订单(用户ID, 商品清单) 3. 订单服务 - 库存服务 校验库存(商品ID, 数量) 4. 库存服务 -- 订单服务 库存充足 5. 订单服务 - 订单数据库 保存订单 6. 订单数据库 -- 订单服务 保存成功 7. 订单服务 -- 普通用户 下单成功 激活说明商城界面在收到提交请求后进入激活态持续到返回“订单请求已提交”订单服务在第 2 条消息后激活直到返回成功消息。写模板时注意消息序列里的“--”表示返回虚线箭头“-”表示请求实线箭头。如果你手绘务必在箭头上标清消息名和参数参数可以不写全但消息名一定要写。阅卷时消息名每缺一个关键词扣一分这是最冤的丢分方式。4.3 如何用“题感”刷题给自己出一套以题带练的清单刷题不是比数量而是比“题感”。所谓题感就是看到一段需求描述时能快速判断“这里会挖什么考点”。我建议你用下面这个方法自建一个迷你题库把身边熟悉的业务场景写成一句话需求比如“自助咖啡机支持扫码支付支付时如果余额不足则跳转充值”然后要求自己在一分钟内完成两件事列出用例图里的参与者和关系列出顺序图里的消息序列。坚持每天练三个场景一周后你会发现自己对 include/extend 的判断速度明显变快。这个方法的原理是刻意变式训练同一套业务规则今天改成“支付必须调用风控系统”明天改成“支付完成后可发送电子发票”训练的就是关系变化。比你闭眼乱做五十道题更可靠。我在备考软考时用这个方法把历年高频业务场景电商、订票、仓库管理全部自己改写过一遍最后拿到案例分析题时拆需求的速度快很多。5. 避坑用例图和顺序图做题时最常踩的 5 个坑现象→原因→解决5.1 用例粒度写成“系统内部动作”导致用例数目爆炸现象一张用例图里出现“连接数据库”“校验输入”“显示弹窗”这些用例图密密麻麻得分却很低。原因把实现步骤误当成业务目标本质是对“参与者可感知价值”理解不到位。解决每个用例必须回答“参与者通过系统获得了什么完整结果”。连接数据库是“登录”的一个技术步骤参与者感知不到必须合并进主用例。你可以用反推法如果删掉这个用例参与者的业务目标是否依然成立成立就删掉它或者作为 include 子步骤处理。5.2 include 和 extend 方向搞反规范上叫“依赖方向错误”现象题干说“下单时可以使用优惠券”你画成下单 include 使用优惠券或画成使用优惠券 extend 下单的分支方向不对。原因把“可选”当成“必有”或没弄明白 extend 箭头指向谁。解决记住箭头方向——include 箭头由基础用例指向被包含用例下单→身份验证extend 箭头由扩展用例指向基础用例使用优惠券→下单。判断口诀“必须做的事用 include可选加戏用 extend箭头指向被扩展的基准点。”如果题目出现“支付时若使用优惠券则计算折扣”那么“计算折扣”是扩展用例箭头从“计算折扣”指向“支付”。5.3 顺序图里把返回消息画成实线箭头现象消息序列里所有的交互都画成实线箭头阅卷老师看不出哪些是请求哪些是返回。原因很多教材的简化画法会把返回值省略于是考生干脆全部用实线反而丢掉规范分。解决同步请求用实线实心箭头返回结果用带return或消息名加前缀“返回”的虚线箭头。我自己改卷时发现只要出现一条返回消息画成实线整个图的消息逻辑就会混乱直接扣 2 分以上。画完后用笔尖指着每条箭头检查一遍看到从右向左连的箭头默认是返回必须改成虚线。5.4 顺序图对象名称只写“用户”“订单”没有类名现象对象框里写“用户”“系统”没有冒号类名。原因很多人在 break 到备注时只图快忽略了对象框的标准格式是实例名:类名。解决按规范写若实例名不重要也至少写:User表示该对象的类型。顺序图得分点里“对象命名规范”占 12 分这个分白给不拿白不拿。另外如果对象是参与者的代表比如“普通用户”建议写成user:User避免和“用户对象”混淆。5.5 顺序图激活条没有起止消息悬空现象某对象收到消息后激活条一根到底覆盖了所有后续消息或者根本没有激活条。原因对“激活表示对象执行操作的时间段”理解不到位把每个消息当成独立事件没有连贯性。解决每次同步请求到达某对象时该对象生命线上开始一个激活条直到这条消息的返回消息发出激活条才结束。自调用、回调时激活条要嵌套。检查方法从图中自上而下找每一条消息若消息有接收方且无返回则接收方激活至少持续到消息序列末尾。悬空消息等于告诉阅卷老师你还没理解生命周期。6. 最后再教你一手用“事件流走查法”验证你的顺序图顺便把答案变成面试谈资顺序图画完后我最推荐做一件看似多余实则救命的事把消息序列用自然语言复述成一段连贯的用户故事我称之为“事件流走查法”。你不需要在任何工具里画直接在草稿纸上顺着消息序号往下念“用户提交订单请求商城界面收到后调用订单服务订单服务再调用库存服务库存服务返回充足订单服务保存订单并返回成功……”念到哪卡住哪有问题。卡住的地方通常是三种情况之一某个消息没有接收方某个对象收到消息却没有后续动作返回消息和请求消息对不上。我每次带学员模拟测试凡是用这个方法走查过一遍的人正确率能提高两成因为很多规范问题不是画图时发现的而是在“讲故事”时逻辑漏洞自己就跳出来了。这个方法还有一个额外收益系统分析师有面试或论文答辩环节时你随时能把一张静态顺序图讲成一条清晰的业务事件流。比背概念更有说服力。我自己的习惯是每画完一张图至少用两分钟做这个走查坚持二十张图之后你基本能做到“落笔前先在脑子里跑一遍事件流”。说到底UML 试题考的是你有没有用模型思考业务的能力这个能力不是靠背箭头含义得来的是靠一遍遍把模型翻译成语言练出来的。希望帮到你。本文还有配套的精品资源点击获取