软件工程用例图复习笔记：从参与者到include/extend关系解析

说实话第一次复习软件工程用例图的时候我心里是有点犯嘀咕的不就是画几个小人、几个椭圆再用线连起来吗能有多难后来做题做到怀疑人生才明白用例图属于那种看着简单一考就废的知识点。平时以为掌握得差不多真到期末考试、软考中级软件设计师真题里一个include和extend的关系判断就能把人绕晕更别说还要区分主参与者、写清用例描述。这篇文章是我自己复习软件工程时整理的一套用例图笔记适合正在准备软件工程期末考试、软考或者在做课程设计前想先把需求梳理清楚的同学。不只是罗列概念我会把教材里含糊的地方用大白话讲透再配合图书管理系统这个最常见的例子把完整画图流程走一遍。1. 用例图不是画小人先搞清楚它在软件工程里解决什么问题1.1 用例图在需求分析阶段的定位软件工程课程里需求分析这一章是重中之重。无论期末考试还是软考中级软件设计师需求阶段用到的图总是反复出现。用例图就是需求分析阶段最常见的一种行为模型图。它解决的问题可以概括成一句话系统要为哪些外部角色提供哪些可见的功能。这句话有三个关键词。第一是外部角色说明用例图只关心站在系统外面的人或系统不关心系统内部怎么实现第二是可见的功能说明用例描述的功能必须是从外部能观察到的结果不是内部的计算过程第三是系统说明所有功能都要画在系统边界之内。在实际项目中用例图往往在需求获取阶段就开始画了。项目组成员和用户坐在一起用户说我要能查图书开发人员就记一个查询图书用例用户说借书时先看这个读者有没有欠费开发人员就记一个验证读者资格用例。这个阶段画图的目的不是追求完美的UML符号而是快速建立共同语言。等需求逐渐清晰再回头修改用例图把关系补全。1.2 系统边界一上来就该画的矩形框很多复习资料把用例图拆成参与者、用例、关系三要素我建议把系统边界也算进来因为它是画图时第一个要落笔的东西。系统边界是一个矩形框框的顶部写上系统名称框内放用例框外放参与者。它的作用是把系统负责的和外部负责的隔开。怎么判断一个功能是不是该放进边界内我用的办法是问自己这个操作的执行系统是否要参与并且要保存结果如果只是某个角色自己完成、系统完全不参与就不算用例。比如读者自己决定看哪本书系统管不着不能画成用例读者在系统中查询图书系统要返回结果可以画成用例。边界的作用在考试里容易被忽略。有的题目给了好几个用例让你从中挑选应该放进系统边界内的这时只要抓住系统是否直接参与就能判断。顺便提一句系统边界框的顶部一般写系统的名称比如图书管理系统网上购物系统不要写成一堆类名或者模块名那是后面设计阶段的事。1.3 和其他UML图的分工用例图只是UML众多图形中的一种。复习时最怕的是把图的功能弄混这里做一个快速区分类图描述系统的静态结构强调对象和对象之间的关系时序图描述一个用例内部多个对象之间消息传递的时间顺序活动图描述业务流程或算法的执行流程状态图描述单个对象在生命周期中的状态变迁用例图描述的是系统的功能全貌不关心内部实现细节。考试如果问以下哪个图用于描述系统功能需求优先选用例图。如果问哪个图描述对象间交互的时间顺序则是时序图。这个概念题虽然简单但在试卷里出现的频率很高属于送分题前提是你真的分清了几种图的名字。2. 参与者识别和用例粒度80%的图错在第一笔2.1 参与者的判断标准谁直接跟系统交互参与者Actor画在系统边界外面通常用一个小人图标表示名字写在图标下面。参与者可以是人可以是外部系统也可以是外部设备。比如图书管理系统里图书管理员读者是人校园一卡通系统是外部系统扫码枪是外部设备。判断参与者的标准就一条这个角色是否直接与系统交互并且系统需要为他提供服务或接受他的输入。如果某个人只是间接使用系统比如读者通过管理员借书那么直接交互的是管理员读者在借书这个用例中不是主要参与者。注意直接交互这个词很关键。常见误区有三个。第一个是把数据库画成参与者这是错的数据库通常是系统内部组件第二个是把人笼统地画成一个参与者比如把图书馆工作人员不分角色地画进去结果分不清是管理员还是编目员第三个是漏掉外部系统比如图书管理系统要和一卡通系统通信一卡通系统就是一个外部参与者。2.2 主参与者与次要参与者谁发起谁配合进一步细分参与者可以分为主参与者Primary Actor和次要参与者Secondary Actor。主参与者是发起用例、希望系统完成任务的人或系统次要参与者是为用例提供支持、但不主动发起流程的一方。举个例子图书借阅用例中主参与者是图书管理员因为他主动发起借书操作次要参与者可能是读者因为读者虽然在场但不在系统中直接操作。如果题目描述的是读者自己在自助借还机上借书那么主参与者就变成读者管理员反而退到保障角色。考试中分析主参与者主要看谁的动作触发了系统操作。这一步分析对了后面识别用例顺序就顺了。我在复习时习惯把题目文字中所有动作的发出者圈出来谁的动作是主动发起谁就是主参与者这个办法屡试不爽。2.3 用例命名和粒度粗了漏功能细了碎成渣用例Use Case用椭圆表示放在系统边界内椭圆下方或内部写用例名。用例名必须是动词短语比如查询图书归还图书维护读者信息不能只写图书读者这样的名词因为用例代表的是功能动作不是数据对象。粒度问题是很多同学画图时最头疼的。到底一个功能应该拆成几个用例我的判断依据是这个动作是否给参与者返回一个完整、可识别的结果。比如验证密码不是一个独立面向用户的完整功能它是用户登录的一部分所以通常不作为顶层用例用户登录给用户返回登录成功或失败的结果是一个完整用例。扫描图书条码不是完整功能借书才是完整功能。但粒度也要看题目要求的详细程度。如果题目专门考察某个流程可能会把身份验证单独作为一个用例然后和借书建立include关系。所以考试时要学会变通不要死记验证永远不能当用例。2.4 参与者的泛化关系读者有很多种参与者之间也可以有继承关系UML里叫泛化Generalization用空心三角箭头表示。比如读者是父参与者学生读者教师读者是子参与者子参与者继承父参与者的所有用例同时还可以有自己的扩展用例。学生读者可以查询图书、借书教师读者也可以但教师读者可能还可以使用教师专用资源下载。画这种关系时箭头从子参与者指向父参与者和类图中继承的箭头方向一致。别画反了软考真题里就出现过把方向画反的选项专门用来坑人。3. include、extend、泛化连线关系才是丢分重灾区3.1 关联关系参与者和用例之间的实线先分清关联Association、包含Include、扩展Extend、泛化Generalization四种关系。关联关系很简单就是参与者与用例之间画一条实线。这条线表示该参与者可以启动或参与这个用例。图里面每个用例至少要和某一个参与者相连如果一个用例孤零零地飘在系统边界里没有任何参与者连过来那要么是画错了要么是漏了关联关系。考试中经常出现该用例无人触发的错误识别题。3.2 包含关系每次执行都逃不掉的那段流程包含关系用虚箭线表示箭头从基用例基础用例指向被包含用例虚线上标注include。它的意思是在执行基用例时一定会执行被包含的那个用例被包含用例是基用例的公共步骤。判断标准非常简单粗暴删掉这个用例基用例还能不能做到每次都完整执行如果不能那就用include。注意这里说的是每次。最经典的就是登录功能。比如借书用例前提是管理员已经登录系统但其实可以抽象为借书包含登录验证因为每次借书都必须经过身份验证下订单包含登录因为每次下单前都要确认用户身份身份验证下面可能又包含密码校验。include的箭头方向千万不要画反。我复习时记的口诀是箭头指向被包含的小步骤。也就是从大用例指向公共用例。很多同学画成从公共用例指向大用例在判断题和画图题里都会扣分。3.3 扩展关系特定条件下才触发的可选分支扩展关系同样用虚箭线表示箭头从扩展用例指向基用例虚线上标注extend。它表示只有在特定条件下基用例才会执行扩展用例中的内容。如果条件不满足基用例可以独立完成并不需要扩展。判断方法和include刚好相反删掉扩展用例基用例依然是一个完整、有意义、独立成立的功能那就用extend。比如还书用例在正常情况下的基本流程是办理归还、更新库存如果读者逾期就需要执行计算逾期罚款但计算逾期罚款不是每次还书都会发生的它就是还书的扩展用例。再看一个典型的在线支付基本流程是选择支付方式、输入密码、扣款成功如果支付时余额不足走余额不足处理扩展流程。并不是每个用户都会余额不足所以用extend而任何一次在线支付都必须调用支付网关接口所以调用支付网关用include。extend箭头方向与include相反要从扩展用例指向基用例。我的记忆方法是扩展是特殊情况来找基本的所以箭头标出的是被影响的一方从特殊指向正常。做题时看到当……时如果……则这类条件描述就优先考虑extend。3.4 泛化关系子用例继承父用例除了参与者之间的泛化用例之间也可以有泛化。比如支付是一个父用例支付宝支付微信支付银行卡支付是子用例。子用例继承父用例的基本行为还可以增加自己的特有行为。UML表示法和参与者的泛化一样是一个带空心三角的实线箭头从子用例指向父用例。泛化和扩展的区别要分清。泛化强调的是多种实现方式它表达的是分类各个子用例是平级的、都有资格独立出现扩展强调的是在基本流程上加料扩展用例不是基用例的一个独立实现而是基用例的可选分支。要是把支付和支付宝支付画成extend语义就完全变了那会变成支付在某种情况下才去执行支付宝支付但实际语义是支付有多种实现方式应该用泛化。3.5 三种关系的快速对比和答题口诀关系类型语义是否必选箭头方向关键字include基用例每次都要执行被包含用例必选基用例指向被包含用例每次、必须、公共步骤extend基用例在特定条件下触发扩展用例可选扩展用例指向基用例如果、当、在...情况下、可选泛化子用例继承父用例行为有多种实现平级分类子用例指向父用例是一种、分类、支持多种方式考试时遇到是否包含的判断题脑子里过一遍口诀每次必做是include条件触发是extend删掉include基本不完整删掉extend基本照样跑。 这句话帮我避开了至少五六道弯路。4. 光画图不算完用例描述表才是得分的后半场4.1 为什么用例图必须配套用例描述用例图画得再漂亮也只是骨架。别人只能看到借书两个字看不到借书之前要满足什么条件、借书过程中可能出什么岔子、借书成功后系统要更新哪些东西。所以复习和实际项目中一定会要求写用例描述Use Case Description。软件工程的期末设计、课程设计评审评审老师拿到你的用例图之后第一件事就是看图上的每个用例是否都有对应的文字描述。软考上午题偶尔会直接考用例描述中不包括下列哪项下午题则在案例分析里给出一个残缺的用例描述让你补充基本事件流或前置条件。把这块练好是实打实的得分点。4.2 用例描述的基本要素一份规范的用例描述至少包含下面几项用例名称和编号和用例图一致编号用来索引参与者主要参与者、次要参与者前置条件执行这个用例之前系统必须满足的状态后置条件用例执行成功后系统到达的状态基本事件流正常路径下参与者和系统之间的交互步骤备选事件流非正常但可预期的路径比如条件分支异常事件流系统出错、超时、数据不存在等异常情况业务规则与用例相关的约束比如最大借书数量、借期、罚款标准。前置条件不是用户打开系统这么刻板而是用例运行前系统真实的必要条件。比如借书的前置条件是管理员已登录读者持有有效借阅证还书的前置条件是读者存在借阅记录。后置条件则要写清楚成功后的变化比如图书库存减一系统生成借阅记录读者借阅列表更新。基本事件流是核心通常写成编号步骤每步一句主语明确避免笼统描述。备选事件流要对应基本事件流的某一步不能凭空冒出来考试时经常让你补写的就是它。4.3 图书借阅用例描述完整示例我自己复习时整理过一份模板直接拿图书管理系统举例描述项内容用例编号UC001用例名称图书借阅主要参与者图书管理员次要参与者读者前置条件管理员已登录系统读者持有有效借阅证读者当前无逾期未还图书后置条件系统更新该书库存在库数减1系统生成一条借阅记录读者借阅列表新增一条记录若成功则返回借阅成功信息基本事件流1. 管理员扫描或输入读者借阅证号2. 系统校验读者资格3. 管理员扫描图书条码4. 系统检查图书状态是否在库5. 系统将图书标记为已借出6. 系统创建借阅记录并保存7. 系统显示借阅成功备选事件流2a. 读者资格校验不通过系统提示原因用例终止4a. 图书状态为已借出或不存在系统提示管理员返回步骤35a. 读者已达到最大借阅数量系统拒绝并提示用例终止异常事件流3a. 网络中断导致条码查询失败系统显示重试界面管理员重新扫描5b. 数据库写入超时借阅记录未成功保存系统回滚库存状态业务规则每名读者最多同时借阅5本借期为30天逾期每天每本罚款0.1元损坏书籍按定价赔偿这里有一个容易忽略的亮点后置条件不只有成功路径失败也要写清楚系统数据保持不变。很多同学写的后置条件只有成功状态结果评审老师追问失败了你怎么办就卡住了。考试中如果看到后置条件这句话要注意判断题里说后置条件描述系统执行成功后的状态其实是片面的失败后的状态也要覆盖或者明确说明失败时系统状态不变。4.4 编写事件流时的表达技巧事件流写法看起来简单但很容易写成屎山。我总结了三条规定主语要么是管理员要么是系统不要用它操作者这种模糊词每一步都是原子操作不能再拆分备选流要写明第几步出现什么情况系统怎么处理不要单独写系统报错。比如3. 系统检查图书状态是否在库4a. 若图书不在库系统提示该书已被借出管理员重新输入就比系统判断库存规范得多。5. 图书管理系统用例图真题拆解从题目到完整成图5.1 解题步骤先画边界再找参与者最后补用例每次拿到画用例图的题目我按固定顺序做基本不错画系统边界矩形框顶部写系统名通读题目把所有名词性角色圈出来判断哪些直接与系统交互放入边界外把所有动词短语圈出来判断哪些是完整功能放入边界内把参与者和用例用实线连接看哪些用例之间存在公共步骤添加include看哪些流程有条件和可选分支添加extend看是否存在多种方式实现同一功能添加泛化最后检查每个用例是否至少有一个参与者连接所有参与者是否都连到了至少一个用例。第2步和第3步最容易混合因为题目中的动词短语不一定都是用例需要过滤掉那些不是系统参与的动作。第5步和第6步最容易混淆上一条说的判断口诀在这里直接用。5.2 一个典型题目图书管理系统的用例图假设题目描述是这样的图书管理员可以维护图书信息和读者信息读者可以在系统中查询书目、查看自己的借阅记录管理员负责借书和还书借书前需要验证读者身份如果读者逾期还书系统要计算罚款读者可以在系统中预约图书管理员可以处理预约。第一步参与者有谁直接交互的是图书管理员和读者。有人会问逾期罚款的触发者是谁这里系统启动计算也可以用一个系统定时器表示但考试题通常不希望引入非人角色你就把它当作还书的一个备选流扩展即可不单独作为参与者。第二步候选用例维护图书信息、维护读者信息、查询书目、查看借阅记录、借书、还书、验证读者身份、计算逾期罚款、预约图书、处理预约。第三步过滤验证读者身份是借书的公共步骤用include计算逾期罚款是还书的可选分支当且仅当逾期时执行用extend预约图书和处理预约一个由读者发起一个由管理员发起都是独立用例查询书目和查看借阅记录都属于查询类操作也可以泛化成一个查询父用例但一般不至于拆得太细题目没说时保持现状。画出来之后的关系可以表述为读者关联查询书目、查看借阅记录、预约图书图书管理员关联维护图书信息、维护读者信息、借书、还书、处理预约借书 ——include—— 验证读者身份还书 ——extend—— 计算逾期罚款箭头由计算逾期罚款指向还书。这一套推演下来整道题的图形结构就清楚了。考试时不一定会要求你画全图但判断关系错对的能力正是通过这种一步一步推演练出来的。5.3 一道软考真题里的常见陷阱软考中级软件设计师的用例图真题经常把关系线画好让你判断对错或者给出一张残缺图让你选缺失的关系。我印象里常见陷阱有四个陷阱一把include箭头画反。题目故意把实线、虚线的方向标反很多同学只记得include是虚线忘了方向。陷阱二把extend画成include。比如当余额不足时执行充值这种条件触发正确是extend但选项里给include一不留神就选错。陷阱三在系统边界内放参与者。参与者永远在边界外边界内只能是用例。陷阱四用例名写名词。比如图书而不是查询图书这在改错题里是常见错误点。做题时我习惯先看关系关键词再看箭头方向最后看参与者位置三步排除法可以降低失误率。6. 复习冲刺阶段的工具、自检清单和踩坑提醒6.1 画图工具怎么选平时做课程设计和写实验报告工具我推荐三个层次手绘白板适合考试复习阶段快速练习强迫自己把用例图结构记在脑子里强烈建议刷题时用手画不要用工具draw.iodiagrams.net免费、没有平台限制、支持UML模板画完可以直接导出图片放进课程设计文档我现在的项目文档大多数都用它ProcessOn和StarUMLProcessOn在线协作方便适合小组课设StarUML是老牌桌面工具适合复杂系统建模但界面稍微陈旧。如果你只是想快速梳理需求不用追求完美符号画图工具不是核心用例图的灵魂在逻辑关系不在美观程度。我自己曾经为了把椭圆画得好看花了半小时调格式结果关系判断错了白忙一场。6.2 画完用例图后的自检清单每次画完我按下面几项自查系统边界内是否只有用例没有参与者和外部系统每个用例是否至少和一个参与者相连每个参与者是否至少参与一个用例用例名称是否都是动词短语是否存在每次执行都必须做的公共步骤却漏掉了include是否存在特定条件下触发的可选流程却错用成了include泛化箭头是否都从子指向父用例描述是否覆盖前置条件、后置条件、基本事件流、备选事件流、业务规则这个清单也适合考试前的快速回顾相当于把整章知识点压缩成八个检查点。6.3 我复习时踩过的坑和应对方法踩过的坑里印象最深的是把借书和查询图书都当作同级别用例结果画出来的图完全没有层次。后来我意识到用例图也可以有层次顶层用例是用户视角最重要的业务功能公共子流程被抽取出来用include关联可选分支用extend关联。这样图就不会变成一团乱麻。另一个坑发生在用例描述的备选事件流上。我一开始只写系统报错被老师批了之后才明白备选流必须能对应到基本事件流的具体步骤而且要给出系统处理方式。比如基本流第4步是检查图书状态备选流就写4a若图书已借出系统提示已借出返回第3步。这样测试人员拿到用例描述才能写测试用例。还要提醒一句复习时间紧张时不要只盯着概念背一定要动手画几张图。哪怕题目不给图自己也随便想一个小系统比如学生选课系统医院挂号系统在线点餐系统按顺序画参与者、用例、关系再写一个用例描述。这个过程坚持三次胜过硬啃十页笔记。7. 最后说点复习之外的题外话用例图这个东西考试考的是规范和逻辑但实际工作中它更像个沟通工具。你画出来的图项目经理能看懂客户能看懂开发人员也能看懂这就是它的价值。复习时我反复练图书管理系统、在线购物这些经典场景练到最后发现不管题目换成什么系统判断的逻辑完全一样。把参与者、用例、include、extend这几件事吃透任何新场景都能快速套进去。另外软考的下午案例分析题里用例图经常和ER图、类图放在同一道大题里考画完用例图还要补出对应类图。所以复习时不要孤立地啃用例图可以顺带看看类图的基本画法两者在需求分析和概要设计阶段是衔接的。最后分享一个小技巧考前把include和extend的判断口诀、泛化箭头的方向、用例描述的八个要素抄在一张巴掌大的便签纸上进考场前扫一眼就够了。我当时靠这张便签把最容易丢分的关系判断题全捞了回来。希望这份笔记对你有用也祝准备考试和课设的你少走几个弯路。