马上要考软件工程了最近后台好多同学都在问用例图该怎么复习。说实话用例图在软件工程的知识体系里属于“看着简单、考起来全是坑”的那类内容尤其是软考中级软件设计师的真题几乎每年都有一道用例图相关的题目而且选择题、案例分析题都喜欢从关系判断上挖陷阱。很多人复习的时候习惯把重点放在数据流图、ER图甚至流程图上面用例图往往被当成送分题一眼扫过结果真到了考试才发现参与者怎么找、包含和扩展怎么区分、箭头往哪边画全是模棱两可。这篇笔记不是把课本重新抄一遍而是我从期末复习、软考刷题、课程设计画图这几个实际场景里整理出来的干货。我会把用例图的核心元素、四种关系、画图步骤、图书管理系统这个经典案例还有软考真题的答题套路全部串起来讲清楚。不管你是正在准备期末考的大学生还是打算报考软考中级软件设计师的从业者又或者是被课程设计逼着画用例图的人这篇文章都能让你少走不少弯路。先消化概念再盯住关系最后上手案例这应该是复习用例图最靠谱的路径。1. 先搞懂用例图到底在表达什么1.1 用例图的本质是“功能视角”而非“流程视角”很多初学者最容易犯的第一个错误就是把用例图当流程图来画。流程图描述的是“一件事怎么做”强调步骤先后和分支判断而用例图描述的是“系统为谁提供什么价值”强调角色和功能的对应关系。换句话说流程图回答的是“how”用例图回答的是“who”和“what”。这个差别非常重要。比如图书管理系统里的“借书”功能用流程图画出来你要画出读者提交申请、管理员核验身份、检查借阅数量、登记借出信息、更新库存这一长串步骤。但用用例图画“借书”就只是一个椭圆形的用例旁边连着一个叫“读者”的小人至于内部怎么实现用例图根本不关心。所以复习的时候心里要有个标尺如果画出来的用例图里出现了“先”“然后”“判断”“循环”这类词汇那大概率是把用例图画成了流程图。用例图里的用例应该是黑盒外部看不到内部细节。这一点在软考的选择题里也经常考题干描述一个系统然后问应该采用什么图来表示系统功能答案往往就是用例图。1.2 一张标准用例图的四个必备构件一张完整的用例图说穿了就四样东西参与者Actor、用例Use Case、系统边界System Boundary、关系Relationship。这四样缺一不可少了任何一个都算不上规范。参与者是系统外部的人和物注意这里有个极其容易忽略的细节——参与者一定是“角色”而不是“具体的人”。比如“图书管理员”是角色“张三”就不是角色“读者”是角色“正在借书的那个学生”就不是角色。软考真题里经常出现“以下哪项不能作为参与者”这类选项有时候会把“数据库”放进去这就涉及另一个规则参与者必须与系统进行交互且位于系统外部。数据库如果只是被系统内部访问它就不是参与者但如果系统需要从另一个独立的外部认证系统获取用户信息那个外部系统就可以是参与者。用例就是系统提供的功能单元画成椭圆。系统边界是那个大大的矩形框用例画在里面参与者画在外面。关系是最容易考的地方关联、包含、扩展、泛化四种关系各有各的画法和语义我后面单独开一章详细拆。1.3 系统边界最常被忽略的得分点你以为系统边界只是个装饰框那就太小看它了。系统边界直接决定了参与者的识别。考试里有时候会故意省略边界让你根据描述判断某个外部实体到底算不算参与者这个时候你就要自己脑补边界画在哪。判断方法很简单这个功能是系统内部完成的还是借助外部完成的如果“验证读者身份”需要调用一个独立的身份认证中心那么身份认证中心就在系统边界之外是参与者而“验证读者身份”这个用例本身在系统边界之内。另一个常用的判断角度是这个人或系统是否直接与目标系统交互。只间接产生影响的比如上级领导要看统计报表但他本人不直接操作系统那他就不应该出现在用例图里。我复习的时候习惯每画一个参与者就问自己一句话“他是自己动手用系统还是只是听说系统有这功能”前者才配当参与者。这个方法在课程设计和软考案例题里都非常好用。1.4 用例粒度画多细才算合适用例图难画往往不是不会画而是不知道画到什么程度。粒度太粗一个“管理图书”就把增删改查全包了粒度太细把“输入书名”“点击查询按钮”“显示结果”全拆出来那就把用例图画成了功能菜单。我的经验是用例名称一定要包含动词并且表达完整的业务目标。比如“查询图书”“预约图书”“归还图书”这种就是标准的用例名“输入书名”这种只是操作步骤不能作为用例“增删改查图书”这种也不合适太笼统。判断粒度是否合适的标准是看这个用例能不能给参与者带来一个可识别的价值结果。从“借书”这个动作到“借书成功”这个结果中间不管经历了多少步操作它都只是一个用例。在软考真题里有时候会给你一个用例清单让你判断哪些用例命名不规范或者哪些用例应该合并、哪些应该拆分。掌握“动词业务对象”“可独立交付价值”这两条原则基本就能稳拿这几分。2. 四种关系逐个拆包含、扩展、泛化、关联2.1 关联关系参与者和用例之间的“连线”关联关系是参与者与用例之间那条实线表示参与者发起了某个用例或者参与了某个用例。严格来说关联关系是参与者与用例之间唯一允许直接存在的关系用例与用例之间的关系是另外三种。关联关系里容易出考题的是方向。如果只画一条实线不带箭头表示双向交互很多时候会带箭头表示谁主动发起。比如“读者”和“查询图书”之间通常画成读者指向查询图书的箭头表示读者发起了查询动作。而“图书管理员”和“读者管理”之间箭头从管理员指向读者管理。软考里有一类经典考法是给出几个参与者和用例让你判断哪条连线画错了这时候就要检查是不是把两个用例之间直接连了关联线或者把参与者和参与者之间连线了。2.2 包含关系include公共步骤的强制复用包含关系是整个用例图的考试核心几乎每年都出题。包含关系表示基用例在执行过程中一定会调用被包含的用例。画法是虚线箭头箭头指向被包含的用例箭头上方标注include。举个例子“借书”这个用例在执行的时候一定要先“验证读者身份”所以借书包含验证读者身份箭头从“借书”指向“验证读者身份”。之所以会出现包含关系核心目的是抽取公共步骤很多用例都要验证身份那干脆把“验证读者身份”抽成独立用例让“借书”“续借”“预约”等用例共同包含它避免重复描述。判断是不是包含关系有一个很实用的测试方法问自己“如果没有被包含的那个用例当前用例还能不能成立”如果答案是不能成立那基本就是包含关系。比如没有“验证读者身份”“借书”就没法执行所以是包含。强制、必需、必然执行这三个词是包含关系的关键特征。2.3 扩展关系extend条件触发下的可选增强扩展关系描述的是另一个方向的依赖基用例在特定条件下才去执行扩展用例。画法同样是虚线箭头但箭头方向与包含相反箭头指向基用例箭头上方标注extend。回到图书管理系统的例子“还书”这个用例正常执行时只做归还登记。但如果读者超期了就需要执行“计算罚款”。这个“计算罚款”并不是每次还书都必须执行的只有在“超期”这一特定条件下才触发所以它是“还书”的扩展用例。画图时箭头从计算罚款指向还书标注extend。扩展关系和包含关系的箭头方向是反的这是考试里最经典的陷阱。我当年复习的时候就因为箭头方向记反在模拟题上载过跟头。这里给一个记忆技巧包含关系里被包含的用例是被人用的所以箭头指向它扩展关系里扩展用例是来添加服务的所以箭头指向被扩展的基用例。一个是“指向被依赖方”一个是“指向被增强方”想明白这一层方向就不会记错了。2.4 泛化关系父子用例之间的继承逻辑泛化关系对应面向对象里的继承概念。父用例是通用行为子用例在父用例的基础上进行特化。画法是一条实线加一个空心三角箭头箭头指向父用例。图书管理系统里“读者管理”可以泛化出“新增读者”“修改读者信息”“删除读者”。在更复杂的系统里“支付”可以泛化出“微信支付”“支付宝支付”“银行卡支付”这就是非常典型的泛化用例结构。软考案例题有时候会要求你“结合泛化关系给出用例模型”本质就是考察你是否能在多个相似功能之间识别出共性与差异。泛化关系与包含扩展的区别在哪里简单说泛化描述的是“同一类功能的不同变体”包含描述的是“一个功能必然依赖的公共步骤”扩展描述的是“一个功能在特定条件下的可选流程”。三者维度不同做题时拿这三个定义去套准确率会高很多。2.5 关系判断速查表复习的时候我整理了一张关系判断的速查表做题的时候直接对着套省掉很多纠结。把这张表理解了软考里关系判断的选择题基本就是送分题。关系类型符号箭头指向关键字特征判断口诀关联实线参与者和用例之间谁发起谁执行有人参与就有它包含虚线include指向被包含用例必然、必须、公共步骤少了它活不成扩展虚线extend指向基用例条件触发、可选、异常分支条件满足才出现泛化实线空心三角指向父用例继承、特化、变体儿子像爸爸注意泛化关系也可以出现在参与者之间。比如“学生读者”和“教师读者”都是“读者”的特化就可以用泛化关系来表示。这也是软考喜欢出的一种变化别只想着用例之间的泛化。2.6 用图论思维复盘用例关系这里说点进阶的内容也是我复习到后期突然想通的一个点。用例图里参与者、用例和关系组合起来本质上就是一张有向图。用例作为节点包含、扩展、泛化作为带方向的边从某个参与者出发沿着关系边就能推演出这个角色能够触发的完整功能链。为什么要说这个因为软考案例分析题里经常要求你“找出图中的错误用例关系”或者“补齐缺失的用例”这时候如果你只是盯着单个关系看很容易漏判。正确的做法是像跑图算法一样从每个参与者节点出发沿关系遍历一遍检查每个用例是不是都能从合适的参与者通过合理路径到达。比如“读者”能不能通过关联关系到达“图书入库”如果图中画了这条边那你就要反思图书入库是管理员的工作读者不应该触达这条边就是错的。更进一步Floyd算法这类图论算法考察的是所有节点之间的可达性复盘用例图时也可以借用这种思路把每个用例当成节点把包含、扩展关系当成路径系统性检查每个业务场景从起点到终点是否畅通。我备考软考时就是按照这种“遍历所有路径”的方式检查用例图的结果是Mock案例题的错误基本上一次就能全部揪出来。这个方法特别适合用来做完整性和一致性的自查。3. 经典案例拆解图书管理系统用例图3.1 为什么拿图书管理系统当例题搜“软件工程用例图”的时候跳出来最多的关联词就是“图书管理系统用例图”这绝不是偶然。图书管理系统的业务逻辑足够典型有面向普通用户的查询、借阅功能有面向管理员的图书管理、读者管理功能还有超期罚款、预约预留这类条件触发的扩展流程。角色划分清楚功能层次丰富包含和扩展关系都能体现出来。所以不管是教材、课程设计还是毕业设计大家都爱拿它举例。你把图书管理系统的用例图画熟了再去画网上商城、会议管理、教务管理系统思路完全是相通的。3.2 参与者识别别人画三个你画四个到底哪个对图书管理系统的参与者大部分教材列了三个读者、图书管理员、系统管理员。但很多课程设计里还会出现第四个——预约系统或者外部认证中心。到底哪个对没有绝对答案取决于系统的边界画在哪。如果你画的系统只包含图书管理的核心业务预约邮件通知是系统外发的那你需要把“邮件服务系统”作为外部参与者如果学校统一身份认证系统负责验证校园卡信息那么身份认证中心也是一个参与者。这恰好说明了一个重要原则用例图没有唯一标准答案边界不同参与者就不同。考试里如果题目没给系统边界你要么自己加一段说明要么根据用例清单反推边界。在软考案例分析里边界通常已经在题目中隐含了比如“该系统需要调用第三方支付系统完成缴费”这句话读完你就该知道要把支付系统作为参与者画出来。3.3 用例清单从需求描述中提取功能画用例图之前先把用例清单列出来后面画图才不容易乱。整理图书管理系统的用例清单我习惯按参与者分组读者注册、登录、查询图书、预约图书、借书、还书、续借、查看个人借阅记录图书管理员图书入库、图书信息维护、读者信息维护、借书登记、还书登记、预约处理、超期罚款处理系统管理员系统参数配置、权限分配、借阅统计报表注意这里“借书”和“还书”既出现在读者组里也出现在管理员组里是不是重复了不是。从业务流程上说读者发起借书请求管理员执行借书登记最终完成的是同一个“借书”用例。在用例图上可以画一个“借书”用例左右两边分别用关联线连向“读者”和“图书管理员”表示两个角色共同参与了这个用例。这也是软考里考察参与者和用例关联关系的一个常见设置。3.4 关系梳理把用例图连成一张完整的网有了用例清单接下来就是标注关系。图书管理系统的关系大致可以这样梳理“借书”包含“验证读者身份”“检查借阅额度”“还书”包含“检查逾期”另外“续借”也包含“验证读者身份”。这就是典型的公共步骤抽取凡是被多个用例重复使用的功能都值得改成包含关系。“还书”扩展“计算罚款”“借书”扩展“图书预约处理”当预约读者优先借阅时。要注意这里的“图书预约处理”和“计算罚款”都不是每次还书、借书必走的流程所以用扩展。“逾期罚款处理”和“借阅统计”是“报表管理”的子用例三者构成泛化关系。这里的父用例“报表管理”可以是抽象用例不一定独立使用但在建模层面它是合理的。在软考真题里题目经常给出已经画好的用例图然后问你“下列关于该图关系的叙述正确的是哪一项”选项里会出现类似“图书管理员与借书之间是包含关系”“还书与计算罚款之间是包含关系”这种混淆命题。你只要把包含和扩展的定义吃透一眼就能判断出“还书与计算罚款”不是包含而是扩展。3.5 场景推演借书流程全链路验证画完关系后我的习惯是至少选一个核心场景做一次完整推演。拿“读者借书”来说读者通过登录进入系统登录是基础用例选择想要借的图书发起借书请求此时“借书”用例启动自动调用“验证读者身份”再调用“检查借阅额度”通过后由管理员完成登记最后借书成功。推演的过程中重点检查三件事第一参与者和用例的关联是否完整读者、管理员是否都画了连线第二包含的公共用例是否覆盖了所有需要它的场景第三扩展用例的触发条件是否在题目描述里有明确交代。这一套走下来你画出来的用例图就不会出现逻辑断裂。课程设计答辩的时候老师问“为什么这里用扩展不用包含”你要是能把这个场景推演讲清楚印象分会高很多。4. 上手实操从需求到用例图的完整画法4.1 六步画图法很多同学拿到需求文档就懵不知道从哪里开始。我整理了一个六步流程按照这个顺序走画图效率会高很多通读需求文档圈出所有“人”和“外部系统”。人名不一定都是参与者但圈出来再筛选总比漏掉好。圈出所有带动词的短语比如“查询图书”“归还图书”“统计借阅量”。这些就是候选用例。确定系统边界把参与者放边界外用例放边界内。这一步在纸上画一条矩形框就行。用关联线把参与者和他们发起的用例连起来。先不画用例与用例之间的复杂关系只画最基础的关联。识别用例之间是否存在包含、扩展、泛化关系逐条加上。这是最关键的一步也是出错最多的一步。对照需求逐条验证。每个用例在需求中都能找到依据每个参与者在需求中都有动作或交互做到“题题有着落”这张图才算合格。4.2 用例命名的规范细节命名不是随便写个词就行。规范的用例名称应当是“动词短语”比如“管理图书”“生成借阅报表”。尽量避免只写名词比如“图书”“报表”这种命名让人猜不到功能和价值画出来也没有意义。软考的评卷标准也吃这一套。案例分析题里如果有“请为系统补充用例名称”这种小题你写“图书管理员”大概率不得分写“图书管理员登录系统”或者更标准的“登录”得分写“管理图书信息”得分。我记得刷历年真题时遇到过要求写出“预约图书”相关用例的题不少考生写了“预约”两个字严格来说不够完整写了“在线预约图书”并且加上了“查看可借状态”这种关联动作的基本可以拿满分。细节往往决定这一两分。4.3 工具选型手画、Visio还是开源工具复习阶段画用例图说实话不需要上手太复杂的工具。我做软考真题的时候直接在草稿纸上画既能练速度也能避免在工具操作上浪费时间。但如果是课程设计需要交文档那就得用正经工具了。免费且好上手的有draw.io网页版浏览器直接打开UML模板里自带用例图的图形符号导出PDF、PNG都很方便。PlantUML适合喜欢用代码画图的人写一小段文本自动生成用例图缺点是关系多了以后排版需要手动调整。StarUML是老牌UML建模工具功能全但界面略显陈旧适合毕业设计这种需要更规范建模的场景。Visio是公司里常见的工具画出来最规整但正版要钱学生用免费工具足够了。我个人最推荐的实操路径是复习刷题用纸笔课程设计用draw.io最终的文档插图用PlantUML或者draw.io二次修整。学习阶段把精力放在逻辑上而不是工具快捷键上这才是重点。4.4 画完图之后的自查清单画完用例图一定要对照自查清单过一遍。以下是我复习时用到的检查项参与者是否都是系统外部的角色或系统有没有把具体人名画进去每个用例名称是否都是动词短语能否独立表达一个业务目标是否每个用例都与至少一个参与者有关联孤立用例基本是错的。包含关系的箭头是否指向被包含用例扩展关系的箭头是否指向基用例方向有没有画反两个用例之间有没有直接用关联线连接这种情况不应该出现。图中是否出现了流程顺序描述比如编号、步骤说明用例图不该有这些。系统边界是否清晰参与者是否都在边界外这七条里面第四条和第六条是我见过的最常见的翻车点。考试画图题里关系方向错了直接扣分这属于硬伤没有任何商量的余地。5. 软考视角用例图真题怎么考、怎么拿分5.1 软考中级软件设计师的命题特点软考中级软件设计师下午的案例分析题里UML建模是固定板块用例图几乎是年年登场。考查方式通常在两种之间轮换一种是“根据需求描述写出指定场景对应的用例名称”另一种是“完善用例图指出图中的错误关系”。有时候也会结合用例描述表来考题干会给出一张表格列出用例名称、参与者、前置条件、后置条件然后让你补全缺失项。从热搜词里“软考中级软件设计师用例图真题”常年有人搜索就能看出这一块是大家的痛点。实际上它的难度并不高属于“背概念会审题”就能解决的题目。关键是要适应真题的提问方式而不是只停留在概念层面。比如题干说“系统支持读者查询图书和查询个人借阅记录这两项均需登录后才能进行”这句话翻译成用例图语言就是查询图书和查询个人借阅记录这两个用例都包含“登录”。5.2 真题还原图书馆管理系统案例题解析下面用一道高度还原软考风格的题目来演示答题思路。假设某图书馆管理系统提供以下功能读者可以注册账号、登录系统、查询图书、预约图书、续借图书。图书管理员可以管理图书信息包括新增、修改、删除可以处理读者的借阅和归还请求。所有借阅操作前必须验证读者身份。归还图书时如果超过借阅期限系统自动计算罚款并生成罚款记录。系统可以生成各类统计报表统计报表包括图书流通报表和读者借阅报表。题目第一问通常这样出请指出“借书”用例与“验证读者身份”用例之间是什么关系并说明理由。这道题的答案是包含关系理由就是“所有借阅操作前必须验证读者身份”说明验证身份是借书的必要步骤缺少它借书流程无法继续。答题的时候一定把题干原话引出来再扣到定义上分两步写逻辑清晰评卷老师一眼就明白你掌握了。题目第二问可能是请写出“还书”用例可能包含或扩展的用例名称。这时候就要抓住“超过借阅期限系统自动计算罚款”这个关键句。超期是条件计算罚款是条件触发下的动作所以是扩展关系。用例名写作“计算罚款”即可。题目第三问如果升级难度会这样问“请用包含关系和扩展关系完善该系统的用例图并说明图中可能存在的错误。”错误点往往藏在两个地方一是把包含和扩展画反二是漏掉了“注册”作为独立用例三是把“统计报表”当成一个不带任何子用例的普通用例事实上这里应该体现泛化关系“图书流通报表”和“读者借阅报表”都是“统计报表”的特化。5.3 做题的得分技巧与时间分配下午案例分析题一场下来时间紧张用例图相关的小题建议控制在15分钟以内。我的做题顺序是先通读题干把所有功能词圈出来然后立刻判断哪些功能带条件、哪些功能是必需的前置步骤最后再把它们映射到包含和扩展关系上。这样做题的最大好处是你不用反复回看原文一次性把信息提取干净。答题语言也有讲究。“补充用例名称”这种题直接写“验证读者身份”“计算罚款”这种完整用例名不要写成“验证”“罚款”这种半截词。“说明理由”的题必须引用题干原文的关键条件再结合关系定义去解释两句话就能拿到全分。只写关系名称不给理由会被扣掉一半的分这是很多人在软考上吃过的暗亏。另外下午案例题中用例图有时候会与用例描述表结合出题。例如题干给出“用例名称图书预约参与者读者前置条件读者已登录主事件流…”然后让你补“备选事件流”或者“异常事件流”。这时候你要联想到扩展关系因为异常事件往往就是扩展用例的触发条件。比如预约时发现图书已被借出系统提示可加入等待列表这个“加入等待列表”就是“图书预约”的扩展用例。软考很喜欢这种把关系分析与场景描述结合起来的考法重点是“触发条件”四个字。6. 复习踩坑实录与高频错题实战6.1 包含和扩展总是搞混问题出在哪每个复习用例图的人都经历过这个阶段看教材的时候觉得包含扩展很明白一做题就出错。我复盘下来问题通常出在只记符号、不记语义。包含的关键词是“必然调用”扩展的关键词是“条件触发”。只要题干里出现了“如果”“当…时”“在…情况下”这类表达优先考虑扩展只要出现了“必须”“均需”“首先”这类表达优先考虑包含。再补充一个更底层的信息有些同学把“包含”理解成了“部分”。我见过有人把“借书”包含“查询图书”画出来理由是“借书之前肯定要经过查询”。这个理解是错的。“查询图书”和“借书”是两个独立业务目标读者可以查完书不借也可以直接拿着索书号去柜台借借书并不必然包含查询。判断依据永远是“当前用例的执行是否必须调用另一个用例的行为”不能靠业务上的先后顺序去猜。6.2 参与者的三类典型误判参与者的识别错误在课程设计评审里最常见我也帮不少同学看过图归纳起来无非三类。第一类是“把系统功能当参与者”比如画一个名叫“图书数据库”的框还把它和用例连上线。数据库是系统内部的存储组件不是外部角色这个框应该删掉。第二类是“把具体的人当参与者”写成“张三”“值班管理员小李”应该改成角色名“读者”“图书管理员”。第三类是“漏掉非人类参与者”比如支付宝、短信网关、身份认证中心这些外部系统。题目里如果明确写了“该系统的支付功能对接第三方支付平台”那这个支付平台就必须出现在用例图里漏画会直接被扣分。6.3 用例图与流程图、数据流图的边界感复习软件工程时自然会把用例图、流程图、数据流图放在一起对比。它们各自描述的维度完全不同用例图看功能、流程图看处理顺序、数据流图看数据流动。题目里如果给了一段库存管理的描述问用什么图表示最合适你要能准确选出来。数据流图和用例图尤其容易混淆。数据流图强调“数据从哪来到哪去”中间有加工、存储、外部实体涉及数据流的命名和层次分解用例图则强调“角色能做什么”不关心数据怎么流。软考上午题出过“以下关于用例图和数据流图的叙述哪个正确”这种辨析题解题关键就是理解用例图的视野比数据流图更高它只描述系统与外部交互的价值边界不描述内部数据处理。6.4 冲刺阶段的复习策略如果你距离考试只剩一周我的建议是前三天把本文第2章的关系判断表背熟然后每天精做两道软考历年案例分析题中的用例图小题中间两天把图书管理系统的用例图完整画两遍一遍闭卷、一遍对照答案查漏补缺最后两天回归教材把用例图的定义、组成、关系和命名规范快速过一遍顺便把用例描述表中前置条件、主事件流、备选事件流的概念看一眼。刷题的时候不要只刷选择题一定要逼自己写案例分析题的文字答案。用例图主观题是步骤分光会判断不会写理由照样拿不到分。每次写完答案主动对照参考答案的措辞学习人家是怎么把题干条件翻译成“包含”“扩展”的。这块熟练了之后上考场看到用例图题目会非常从容因为本质上无非就是那几种固定考法反复出现。再说一个我自己用着很顺的方法把历年真题里所有用例图题目复制到一起不看选项和答案纯凭题干描述先画出该系统的用例图再和真题答案对比。这样练五道题基本就能在脑子里自动建立“题干关键句→关系判断”的反射。这个方法前期比较费时间但见效极快比单纯刷题刷十道都管用。
软件工程用例图复习指南：关系判断与软考真题解析
马上要考软件工程了最近后台好多同学都在问用例图该怎么复习。说实话用例图在软件工程的知识体系里属于“看着简单、考起来全是坑”的那类内容尤其是软考中级软件设计师的真题几乎每年都有一道用例图相关的题目而且选择题、案例分析题都喜欢从关系判断上挖陷阱。很多人复习的时候习惯把重点放在数据流图、ER图甚至流程图上面用例图往往被当成送分题一眼扫过结果真到了考试才发现参与者怎么找、包含和扩展怎么区分、箭头往哪边画全是模棱两可。这篇笔记不是把课本重新抄一遍而是我从期末复习、软考刷题、课程设计画图这几个实际场景里整理出来的干货。我会把用例图的核心元素、四种关系、画图步骤、图书管理系统这个经典案例还有软考真题的答题套路全部串起来讲清楚。不管你是正在准备期末考的大学生还是打算报考软考中级软件设计师的从业者又或者是被课程设计逼着画用例图的人这篇文章都能让你少走不少弯路。先消化概念再盯住关系最后上手案例这应该是复习用例图最靠谱的路径。1. 先搞懂用例图到底在表达什么1.1 用例图的本质是“功能视角”而非“流程视角”很多初学者最容易犯的第一个错误就是把用例图当流程图来画。流程图描述的是“一件事怎么做”强调步骤先后和分支判断而用例图描述的是“系统为谁提供什么价值”强调角色和功能的对应关系。换句话说流程图回答的是“how”用例图回答的是“who”和“what”。这个差别非常重要。比如图书管理系统里的“借书”功能用流程图画出来你要画出读者提交申请、管理员核验身份、检查借阅数量、登记借出信息、更新库存这一长串步骤。但用用例图画“借书”就只是一个椭圆形的用例旁边连着一个叫“读者”的小人至于内部怎么实现用例图根本不关心。所以复习的时候心里要有个标尺如果画出来的用例图里出现了“先”“然后”“判断”“循环”这类词汇那大概率是把用例图画成了流程图。用例图里的用例应该是黑盒外部看不到内部细节。这一点在软考的选择题里也经常考题干描述一个系统然后问应该采用什么图来表示系统功能答案往往就是用例图。1.2 一张标准用例图的四个必备构件一张完整的用例图说穿了就四样东西参与者Actor、用例Use Case、系统边界System Boundary、关系Relationship。这四样缺一不可少了任何一个都算不上规范。参与者是系统外部的人和物注意这里有个极其容易忽略的细节——参与者一定是“角色”而不是“具体的人”。比如“图书管理员”是角色“张三”就不是角色“读者”是角色“正在借书的那个学生”就不是角色。软考真题里经常出现“以下哪项不能作为参与者”这类选项有时候会把“数据库”放进去这就涉及另一个规则参与者必须与系统进行交互且位于系统外部。数据库如果只是被系统内部访问它就不是参与者但如果系统需要从另一个独立的外部认证系统获取用户信息那个外部系统就可以是参与者。用例就是系统提供的功能单元画成椭圆。系统边界是那个大大的矩形框用例画在里面参与者画在外面。关系是最容易考的地方关联、包含、扩展、泛化四种关系各有各的画法和语义我后面单独开一章详细拆。1.3 系统边界最常被忽略的得分点你以为系统边界只是个装饰框那就太小看它了。系统边界直接决定了参与者的识别。考试里有时候会故意省略边界让你根据描述判断某个外部实体到底算不算参与者这个时候你就要自己脑补边界画在哪。判断方法很简单这个功能是系统内部完成的还是借助外部完成的如果“验证读者身份”需要调用一个独立的身份认证中心那么身份认证中心就在系统边界之外是参与者而“验证读者身份”这个用例本身在系统边界之内。另一个常用的判断角度是这个人或系统是否直接与目标系统交互。只间接产生影响的比如上级领导要看统计报表但他本人不直接操作系统那他就不应该出现在用例图里。我复习的时候习惯每画一个参与者就问自己一句话“他是自己动手用系统还是只是听说系统有这功能”前者才配当参与者。这个方法在课程设计和软考案例题里都非常好用。1.4 用例粒度画多细才算合适用例图难画往往不是不会画而是不知道画到什么程度。粒度太粗一个“管理图书”就把增删改查全包了粒度太细把“输入书名”“点击查询按钮”“显示结果”全拆出来那就把用例图画成了功能菜单。我的经验是用例名称一定要包含动词并且表达完整的业务目标。比如“查询图书”“预约图书”“归还图书”这种就是标准的用例名“输入书名”这种只是操作步骤不能作为用例“增删改查图书”这种也不合适太笼统。判断粒度是否合适的标准是看这个用例能不能给参与者带来一个可识别的价值结果。从“借书”这个动作到“借书成功”这个结果中间不管经历了多少步操作它都只是一个用例。在软考真题里有时候会给你一个用例清单让你判断哪些用例命名不规范或者哪些用例应该合并、哪些应该拆分。掌握“动词业务对象”“可独立交付价值”这两条原则基本就能稳拿这几分。2. 四种关系逐个拆包含、扩展、泛化、关联2.1 关联关系参与者和用例之间的“连线”关联关系是参与者与用例之间那条实线表示参与者发起了某个用例或者参与了某个用例。严格来说关联关系是参与者与用例之间唯一允许直接存在的关系用例与用例之间的关系是另外三种。关联关系里容易出考题的是方向。如果只画一条实线不带箭头表示双向交互很多时候会带箭头表示谁主动发起。比如“读者”和“查询图书”之间通常画成读者指向查询图书的箭头表示读者发起了查询动作。而“图书管理员”和“读者管理”之间箭头从管理员指向读者管理。软考里有一类经典考法是给出几个参与者和用例让你判断哪条连线画错了这时候就要检查是不是把两个用例之间直接连了关联线或者把参与者和参与者之间连线了。2.2 包含关系include公共步骤的强制复用包含关系是整个用例图的考试核心几乎每年都出题。包含关系表示基用例在执行过程中一定会调用被包含的用例。画法是虚线箭头箭头指向被包含的用例箭头上方标注include。举个例子“借书”这个用例在执行的时候一定要先“验证读者身份”所以借书包含验证读者身份箭头从“借书”指向“验证读者身份”。之所以会出现包含关系核心目的是抽取公共步骤很多用例都要验证身份那干脆把“验证读者身份”抽成独立用例让“借书”“续借”“预约”等用例共同包含它避免重复描述。判断是不是包含关系有一个很实用的测试方法问自己“如果没有被包含的那个用例当前用例还能不能成立”如果答案是不能成立那基本就是包含关系。比如没有“验证读者身份”“借书”就没法执行所以是包含。强制、必需、必然执行这三个词是包含关系的关键特征。2.3 扩展关系extend条件触发下的可选增强扩展关系描述的是另一个方向的依赖基用例在特定条件下才去执行扩展用例。画法同样是虚线箭头但箭头方向与包含相反箭头指向基用例箭头上方标注extend。回到图书管理系统的例子“还书”这个用例正常执行时只做归还登记。但如果读者超期了就需要执行“计算罚款”。这个“计算罚款”并不是每次还书都必须执行的只有在“超期”这一特定条件下才触发所以它是“还书”的扩展用例。画图时箭头从计算罚款指向还书标注extend。扩展关系和包含关系的箭头方向是反的这是考试里最经典的陷阱。我当年复习的时候就因为箭头方向记反在模拟题上载过跟头。这里给一个记忆技巧包含关系里被包含的用例是被人用的所以箭头指向它扩展关系里扩展用例是来添加服务的所以箭头指向被扩展的基用例。一个是“指向被依赖方”一个是“指向被增强方”想明白这一层方向就不会记错了。2.4 泛化关系父子用例之间的继承逻辑泛化关系对应面向对象里的继承概念。父用例是通用行为子用例在父用例的基础上进行特化。画法是一条实线加一个空心三角箭头箭头指向父用例。图书管理系统里“读者管理”可以泛化出“新增读者”“修改读者信息”“删除读者”。在更复杂的系统里“支付”可以泛化出“微信支付”“支付宝支付”“银行卡支付”这就是非常典型的泛化用例结构。软考案例题有时候会要求你“结合泛化关系给出用例模型”本质就是考察你是否能在多个相似功能之间识别出共性与差异。泛化关系与包含扩展的区别在哪里简单说泛化描述的是“同一类功能的不同变体”包含描述的是“一个功能必然依赖的公共步骤”扩展描述的是“一个功能在特定条件下的可选流程”。三者维度不同做题时拿这三个定义去套准确率会高很多。2.5 关系判断速查表复习的时候我整理了一张关系判断的速查表做题的时候直接对着套省掉很多纠结。把这张表理解了软考里关系判断的选择题基本就是送分题。关系类型符号箭头指向关键字特征判断口诀关联实线参与者和用例之间谁发起谁执行有人参与就有它包含虚线include指向被包含用例必然、必须、公共步骤少了它活不成扩展虚线extend指向基用例条件触发、可选、异常分支条件满足才出现泛化实线空心三角指向父用例继承、特化、变体儿子像爸爸注意泛化关系也可以出现在参与者之间。比如“学生读者”和“教师读者”都是“读者”的特化就可以用泛化关系来表示。这也是软考喜欢出的一种变化别只想着用例之间的泛化。2.6 用图论思维复盘用例关系这里说点进阶的内容也是我复习到后期突然想通的一个点。用例图里参与者、用例和关系组合起来本质上就是一张有向图。用例作为节点包含、扩展、泛化作为带方向的边从某个参与者出发沿着关系边就能推演出这个角色能够触发的完整功能链。为什么要说这个因为软考案例分析题里经常要求你“找出图中的错误用例关系”或者“补齐缺失的用例”这时候如果你只是盯着单个关系看很容易漏判。正确的做法是像跑图算法一样从每个参与者节点出发沿关系遍历一遍检查每个用例是不是都能从合适的参与者通过合理路径到达。比如“读者”能不能通过关联关系到达“图书入库”如果图中画了这条边那你就要反思图书入库是管理员的工作读者不应该触达这条边就是错的。更进一步Floyd算法这类图论算法考察的是所有节点之间的可达性复盘用例图时也可以借用这种思路把每个用例当成节点把包含、扩展关系当成路径系统性检查每个业务场景从起点到终点是否畅通。我备考软考时就是按照这种“遍历所有路径”的方式检查用例图的结果是Mock案例题的错误基本上一次就能全部揪出来。这个方法特别适合用来做完整性和一致性的自查。3. 经典案例拆解图书管理系统用例图3.1 为什么拿图书管理系统当例题搜“软件工程用例图”的时候跳出来最多的关联词就是“图书管理系统用例图”这绝不是偶然。图书管理系统的业务逻辑足够典型有面向普通用户的查询、借阅功能有面向管理员的图书管理、读者管理功能还有超期罚款、预约预留这类条件触发的扩展流程。角色划分清楚功能层次丰富包含和扩展关系都能体现出来。所以不管是教材、课程设计还是毕业设计大家都爱拿它举例。你把图书管理系统的用例图画熟了再去画网上商城、会议管理、教务管理系统思路完全是相通的。3.2 参与者识别别人画三个你画四个到底哪个对图书管理系统的参与者大部分教材列了三个读者、图书管理员、系统管理员。但很多课程设计里还会出现第四个——预约系统或者外部认证中心。到底哪个对没有绝对答案取决于系统的边界画在哪。如果你画的系统只包含图书管理的核心业务预约邮件通知是系统外发的那你需要把“邮件服务系统”作为外部参与者如果学校统一身份认证系统负责验证校园卡信息那么身份认证中心也是一个参与者。这恰好说明了一个重要原则用例图没有唯一标准答案边界不同参与者就不同。考试里如果题目没给系统边界你要么自己加一段说明要么根据用例清单反推边界。在软考案例分析里边界通常已经在题目中隐含了比如“该系统需要调用第三方支付系统完成缴费”这句话读完你就该知道要把支付系统作为参与者画出来。3.3 用例清单从需求描述中提取功能画用例图之前先把用例清单列出来后面画图才不容易乱。整理图书管理系统的用例清单我习惯按参与者分组读者注册、登录、查询图书、预约图书、借书、还书、续借、查看个人借阅记录图书管理员图书入库、图书信息维护、读者信息维护、借书登记、还书登记、预约处理、超期罚款处理系统管理员系统参数配置、权限分配、借阅统计报表注意这里“借书”和“还书”既出现在读者组里也出现在管理员组里是不是重复了不是。从业务流程上说读者发起借书请求管理员执行借书登记最终完成的是同一个“借书”用例。在用例图上可以画一个“借书”用例左右两边分别用关联线连向“读者”和“图书管理员”表示两个角色共同参与了这个用例。这也是软考里考察参与者和用例关联关系的一个常见设置。3.4 关系梳理把用例图连成一张完整的网有了用例清单接下来就是标注关系。图书管理系统的关系大致可以这样梳理“借书”包含“验证读者身份”“检查借阅额度”“还书”包含“检查逾期”另外“续借”也包含“验证读者身份”。这就是典型的公共步骤抽取凡是被多个用例重复使用的功能都值得改成包含关系。“还书”扩展“计算罚款”“借书”扩展“图书预约处理”当预约读者优先借阅时。要注意这里的“图书预约处理”和“计算罚款”都不是每次还书、借书必走的流程所以用扩展。“逾期罚款处理”和“借阅统计”是“报表管理”的子用例三者构成泛化关系。这里的父用例“报表管理”可以是抽象用例不一定独立使用但在建模层面它是合理的。在软考真题里题目经常给出已经画好的用例图然后问你“下列关于该图关系的叙述正确的是哪一项”选项里会出现类似“图书管理员与借书之间是包含关系”“还书与计算罚款之间是包含关系”这种混淆命题。你只要把包含和扩展的定义吃透一眼就能判断出“还书与计算罚款”不是包含而是扩展。3.5 场景推演借书流程全链路验证画完关系后我的习惯是至少选一个核心场景做一次完整推演。拿“读者借书”来说读者通过登录进入系统登录是基础用例选择想要借的图书发起借书请求此时“借书”用例启动自动调用“验证读者身份”再调用“检查借阅额度”通过后由管理员完成登记最后借书成功。推演的过程中重点检查三件事第一参与者和用例的关联是否完整读者、管理员是否都画了连线第二包含的公共用例是否覆盖了所有需要它的场景第三扩展用例的触发条件是否在题目描述里有明确交代。这一套走下来你画出来的用例图就不会出现逻辑断裂。课程设计答辩的时候老师问“为什么这里用扩展不用包含”你要是能把这个场景推演讲清楚印象分会高很多。4. 上手实操从需求到用例图的完整画法4.1 六步画图法很多同学拿到需求文档就懵不知道从哪里开始。我整理了一个六步流程按照这个顺序走画图效率会高很多通读需求文档圈出所有“人”和“外部系统”。人名不一定都是参与者但圈出来再筛选总比漏掉好。圈出所有带动词的短语比如“查询图书”“归还图书”“统计借阅量”。这些就是候选用例。确定系统边界把参与者放边界外用例放边界内。这一步在纸上画一条矩形框就行。用关联线把参与者和他们发起的用例连起来。先不画用例与用例之间的复杂关系只画最基础的关联。识别用例之间是否存在包含、扩展、泛化关系逐条加上。这是最关键的一步也是出错最多的一步。对照需求逐条验证。每个用例在需求中都能找到依据每个参与者在需求中都有动作或交互做到“题题有着落”这张图才算合格。4.2 用例命名的规范细节命名不是随便写个词就行。规范的用例名称应当是“动词短语”比如“管理图书”“生成借阅报表”。尽量避免只写名词比如“图书”“报表”这种命名让人猜不到功能和价值画出来也没有意义。软考的评卷标准也吃这一套。案例分析题里如果有“请为系统补充用例名称”这种小题你写“图书管理员”大概率不得分写“图书管理员登录系统”或者更标准的“登录”得分写“管理图书信息”得分。我记得刷历年真题时遇到过要求写出“预约图书”相关用例的题不少考生写了“预约”两个字严格来说不够完整写了“在线预约图书”并且加上了“查看可借状态”这种关联动作的基本可以拿满分。细节往往决定这一两分。4.3 工具选型手画、Visio还是开源工具复习阶段画用例图说实话不需要上手太复杂的工具。我做软考真题的时候直接在草稿纸上画既能练速度也能避免在工具操作上浪费时间。但如果是课程设计需要交文档那就得用正经工具了。免费且好上手的有draw.io网页版浏览器直接打开UML模板里自带用例图的图形符号导出PDF、PNG都很方便。PlantUML适合喜欢用代码画图的人写一小段文本自动生成用例图缺点是关系多了以后排版需要手动调整。StarUML是老牌UML建模工具功能全但界面略显陈旧适合毕业设计这种需要更规范建模的场景。Visio是公司里常见的工具画出来最规整但正版要钱学生用免费工具足够了。我个人最推荐的实操路径是复习刷题用纸笔课程设计用draw.io最终的文档插图用PlantUML或者draw.io二次修整。学习阶段把精力放在逻辑上而不是工具快捷键上这才是重点。4.4 画完图之后的自查清单画完用例图一定要对照自查清单过一遍。以下是我复习时用到的检查项参与者是否都是系统外部的角色或系统有没有把具体人名画进去每个用例名称是否都是动词短语能否独立表达一个业务目标是否每个用例都与至少一个参与者有关联孤立用例基本是错的。包含关系的箭头是否指向被包含用例扩展关系的箭头是否指向基用例方向有没有画反两个用例之间有没有直接用关联线连接这种情况不应该出现。图中是否出现了流程顺序描述比如编号、步骤说明用例图不该有这些。系统边界是否清晰参与者是否都在边界外这七条里面第四条和第六条是我见过的最常见的翻车点。考试画图题里关系方向错了直接扣分这属于硬伤没有任何商量的余地。5. 软考视角用例图真题怎么考、怎么拿分5.1 软考中级软件设计师的命题特点软考中级软件设计师下午的案例分析题里UML建模是固定板块用例图几乎是年年登场。考查方式通常在两种之间轮换一种是“根据需求描述写出指定场景对应的用例名称”另一种是“完善用例图指出图中的错误关系”。有时候也会结合用例描述表来考题干会给出一张表格列出用例名称、参与者、前置条件、后置条件然后让你补全缺失项。从热搜词里“软考中级软件设计师用例图真题”常年有人搜索就能看出这一块是大家的痛点。实际上它的难度并不高属于“背概念会审题”就能解决的题目。关键是要适应真题的提问方式而不是只停留在概念层面。比如题干说“系统支持读者查询图书和查询个人借阅记录这两项均需登录后才能进行”这句话翻译成用例图语言就是查询图书和查询个人借阅记录这两个用例都包含“登录”。5.2 真题还原图书馆管理系统案例题解析下面用一道高度还原软考风格的题目来演示答题思路。假设某图书馆管理系统提供以下功能读者可以注册账号、登录系统、查询图书、预约图书、续借图书。图书管理员可以管理图书信息包括新增、修改、删除可以处理读者的借阅和归还请求。所有借阅操作前必须验证读者身份。归还图书时如果超过借阅期限系统自动计算罚款并生成罚款记录。系统可以生成各类统计报表统计报表包括图书流通报表和读者借阅报表。题目第一问通常这样出请指出“借书”用例与“验证读者身份”用例之间是什么关系并说明理由。这道题的答案是包含关系理由就是“所有借阅操作前必须验证读者身份”说明验证身份是借书的必要步骤缺少它借书流程无法继续。答题的时候一定把题干原话引出来再扣到定义上分两步写逻辑清晰评卷老师一眼就明白你掌握了。题目第二问可能是请写出“还书”用例可能包含或扩展的用例名称。这时候就要抓住“超过借阅期限系统自动计算罚款”这个关键句。超期是条件计算罚款是条件触发下的动作所以是扩展关系。用例名写作“计算罚款”即可。题目第三问如果升级难度会这样问“请用包含关系和扩展关系完善该系统的用例图并说明图中可能存在的错误。”错误点往往藏在两个地方一是把包含和扩展画反二是漏掉了“注册”作为独立用例三是把“统计报表”当成一个不带任何子用例的普通用例事实上这里应该体现泛化关系“图书流通报表”和“读者借阅报表”都是“统计报表”的特化。5.3 做题的得分技巧与时间分配下午案例分析题一场下来时间紧张用例图相关的小题建议控制在15分钟以内。我的做题顺序是先通读题干把所有功能词圈出来然后立刻判断哪些功能带条件、哪些功能是必需的前置步骤最后再把它们映射到包含和扩展关系上。这样做题的最大好处是你不用反复回看原文一次性把信息提取干净。答题语言也有讲究。“补充用例名称”这种题直接写“验证读者身份”“计算罚款”这种完整用例名不要写成“验证”“罚款”这种半截词。“说明理由”的题必须引用题干原文的关键条件再结合关系定义去解释两句话就能拿到全分。只写关系名称不给理由会被扣掉一半的分这是很多人在软考上吃过的暗亏。另外下午案例题中用例图有时候会与用例描述表结合出题。例如题干给出“用例名称图书预约参与者读者前置条件读者已登录主事件流…”然后让你补“备选事件流”或者“异常事件流”。这时候你要联想到扩展关系因为异常事件往往就是扩展用例的触发条件。比如预约时发现图书已被借出系统提示可加入等待列表这个“加入等待列表”就是“图书预约”的扩展用例。软考很喜欢这种把关系分析与场景描述结合起来的考法重点是“触发条件”四个字。6. 复习踩坑实录与高频错题实战6.1 包含和扩展总是搞混问题出在哪每个复习用例图的人都经历过这个阶段看教材的时候觉得包含扩展很明白一做题就出错。我复盘下来问题通常出在只记符号、不记语义。包含的关键词是“必然调用”扩展的关键词是“条件触发”。只要题干里出现了“如果”“当…时”“在…情况下”这类表达优先考虑扩展只要出现了“必须”“均需”“首先”这类表达优先考虑包含。再补充一个更底层的信息有些同学把“包含”理解成了“部分”。我见过有人把“借书”包含“查询图书”画出来理由是“借书之前肯定要经过查询”。这个理解是错的。“查询图书”和“借书”是两个独立业务目标读者可以查完书不借也可以直接拿着索书号去柜台借借书并不必然包含查询。判断依据永远是“当前用例的执行是否必须调用另一个用例的行为”不能靠业务上的先后顺序去猜。6.2 参与者的三类典型误判参与者的识别错误在课程设计评审里最常见我也帮不少同学看过图归纳起来无非三类。第一类是“把系统功能当参与者”比如画一个名叫“图书数据库”的框还把它和用例连上线。数据库是系统内部的存储组件不是外部角色这个框应该删掉。第二类是“把具体的人当参与者”写成“张三”“值班管理员小李”应该改成角色名“读者”“图书管理员”。第三类是“漏掉非人类参与者”比如支付宝、短信网关、身份认证中心这些外部系统。题目里如果明确写了“该系统的支付功能对接第三方支付平台”那这个支付平台就必须出现在用例图里漏画会直接被扣分。6.3 用例图与流程图、数据流图的边界感复习软件工程时自然会把用例图、流程图、数据流图放在一起对比。它们各自描述的维度完全不同用例图看功能、流程图看处理顺序、数据流图看数据流动。题目里如果给了一段库存管理的描述问用什么图表示最合适你要能准确选出来。数据流图和用例图尤其容易混淆。数据流图强调“数据从哪来到哪去”中间有加工、存储、外部实体涉及数据流的命名和层次分解用例图则强调“角色能做什么”不关心数据怎么流。软考上午题出过“以下关于用例图和数据流图的叙述哪个正确”这种辨析题解题关键就是理解用例图的视野比数据流图更高它只描述系统与外部交互的价值边界不描述内部数据处理。6.4 冲刺阶段的复习策略如果你距离考试只剩一周我的建议是前三天把本文第2章的关系判断表背熟然后每天精做两道软考历年案例分析题中的用例图小题中间两天把图书管理系统的用例图完整画两遍一遍闭卷、一遍对照答案查漏补缺最后两天回归教材把用例图的定义、组成、关系和命名规范快速过一遍顺便把用例描述表中前置条件、主事件流、备选事件流的概念看一眼。刷题的时候不要只刷选择题一定要逼自己写案例分析题的文字答案。用例图主观题是步骤分光会判断不会写理由照样拿不到分。每次写完答案主动对照参考答案的措辞学习人家是怎么把题干条件翻译成“包含”“扩展”的。这块熟练了之后上考场看到用例图题目会非常从容因为本质上无非就是那几种固定考法反复出现。再说一个我自己用着很顺的方法把历年真题里所有用例图题目复制到一起不看选项和答案纯凭题干描述先画出该系统的用例图再和真题答案对比。这样练五道题基本就能在脑子里自动建立“题干关键句→关系判断”的反射。这个方法前期比较费时间但见效极快比单纯刷题刷十道都管用。
