带过几届做课程设计的学生之后我发现一个相当稳定的规律用例图画得最花哨的那组需求文档往往写得最烂而真正把系统想明白了的那组用例图看起来反而朴素得有点丑。用例图这个东西门槛极低画图工具里拖几个椭圆、连几条线就能交差但要画到能过评审、能直接支撑后面的类图和时序图、能在软考中级软件设计师的题目里稳住分数中间隔着的是一整套判断标准。这篇就把这套标准拆开讲从谁算参与者这种基础问题一直讲到图书管理系统用例图这种具体场景的成图过程最后再聊聊评审时最容易被挑出来的毛病。不管你是第一次画用例图的新手还是已经画过几张但总觉得不对劲的人应该都能找到能直接落地的东西。1. 用例图到底在画什么先破除三个最常见的误解1.1 用例图不是流程图也不是功能清单用例图在 UML 的行为图家族里描述的是谁在用系统和用系统做什么它压根不负责回答系统内部怎么一步步执行。这个定位一确定很多画法上的争论就自动消失了——顺序、判断、循环这些东西天生就不该出现在用例图里。我见过不少同学把输入账号密码、校验、跳转首页画成一串带箭头的椭圆交上去看着像用例图实际上是退化版流程图评审的人一眼就能认出来。另一个极端是把用例图画成菜单树。用户管理下面挂增加用户删除用户修改用户查询用户删除用户再挂批量删除单个删除。这种画法语法上没毛病但信息量接近零本质上是把需求文档里的功能列表原封不动搬进了椭圆。用例图真正的价值在于同时说清三件事系统的职责边界在哪、外部有哪些角色、每个角色能触发哪些完整目标。菜单树只呈现了第三件事里最浅的一个切面。还有一个更隐蔽的误解是觉得用例图必须一次画到位。实际项目里它一般要迭代三轮以上第一轮只把参与者和主要用例铺出来第二轮补关系关联、包含、扩展、泛化第三轮做减法和重命名。我自己的习惯是第二轮才动关系因为过早加 include 会把注意力从业务目标拐到代码复用上那是设计阶段该操心的事放在需求阶段只会让图变复杂。1.2 参与者不一定都是人参与者的定义是与系统交互的外部实体。它可以是一个人也可以是外部系统、硬件设备某些场景下甚至可以是时间。放到图书管理系统里借阅者图书管理员系统管理员是人校园一卡通接口短信通知平台支付渠道是外部系统而每月自动生成逾期清单这类用例真正的触发者是时钟不是管理员。这一点在软考里经常被拿去出题。题干写系统每天凌晨自动统计前一天的借阅数据并生成报表问参与者是谁。不少人下意识写系统管理员但管理员只是查看报表的参与者生成报表的触发者应该是时间或定时器。这道题考的就是有没有把触发用例的东西和消费用例结果的东西分开看。还有一条硬规则参与者必须站在系统边界之外。如果某个角色本身就在系统内部比如数据库日志模块那它顶多算内部组件不该出现在用例图上。判断办法很土但很管用——把系统画成一个方框真正的参与者一定在框外框里的全都是系统自己的事。1.3 用例粒度失控是用例图最大的死因粒度这件事用同一个例子讲最清楚。图书管理系统里借书可以是一个用例也可以拆成验证读者身份检查借阅额度登记借阅记录更新图书状态四个用例。到底哪种对判断依据是这个用例是否给参与者带来一个可观测、有价值的结果。读者来借书他要的结果是书借到手了中间那几步对他来说是系统内部的事所以借书作为单个用例就够了。反过来如果图书管理员需要单独执行检查借阅额度——比如读者跑到柜台问我还能借几本——那它才独立成一个用例。我在评审里总结过一条土办法凡是参与者不会主动说我要做这件事的动作基本都不该是独立用例。按这条筛一遍通常能砍掉三到四成的椭圆图立刻清爽很多。2. 从一段需求描述里抠出参与者与用例的完整流程2.1 先画边界框再找框外的人拿到一段需求文字别急着找动词先画那个方框。方框代表系统本身方框的名字就是系统的名字。这一步看着像形式主义实际上是强制自己回答一个要命的问题这套东西到底管到哪儿为止。很多用例图返工根源就在边界没定一会儿把第三方支付算进来一会儿又把校园卡中心算出去改到最后整张图自相矛盾。框画好之后站在框外面往里看凡是需要跟这套系统的功能打交道的人或外部系统全列成候选人。列的时候不要筛选先把能想到的都写下来包括不常见的角色比如审计人员外部监管接口。第二步再做减法某个候选人如果从头到尾没有任何一个用例跟他交互那他就不是参与者删掉。这里有个经验值可以参考。一个中等规模的业务系统参与者数量通常在 3 到 7 个之间。如果你的候选名单超过十个多半是把内部角色或者模块名字当成了参与者如果只有一两个那可能是漏掉了管理员、外部接口或者定时触发者。2.2 动词筛选法从需求句子里捞用例边界和参与者定了接下来从需求文字里捞用例。土办法是把每一句需求的主谓宾拆开主语负责映射参与者谓语动词负责映射候选用例。比如读者可以通过系统查询图书的借阅状态主语是读者动词是查询宾语是借阅状态候选用例就是查询借阅记录。捞完之后要合并同类项。需求文档经常把一件事拆成好几句话写比如读者可以查看自己的借阅记录读者可以查看借阅到期时间读者可以查看是否逾期这三句其实是同一个用例的不同信息项合并成查询借阅记录一个椭圆就够了。再往下要做的是补漏。书面需求往往只写了正常流程异常和触发式场景经常被漏掉。这时候可以问自己几组问题有没有需要定时触发的动作有没有需要外部系统通知才发生的事有没有只有特定角色才能做的操作把这几类过一遍通常能补出三到五个被遗漏的用例。2.3 用例命名动宾结构站在参与者视角命名是用例图里最容易被忽视、又最容易被扣分的地方。规范只有一个用动词加名词的动宾结构并且站在参与者的视角描述他达成的目标。下表是我经常拿去给学生做对照的取名清单左边是常见的错误写法右边是改完之后的样子。错误命名问题所在推荐命名用户管理是模块名不是目标新增读者、注销读者删除缺宾语动作不完整删除图书信息查询太笼统不知道查什么查询图书、查询借阅记录借阅模块系统内部视角借书、还书、续借数据录入不知道谁录入什么登记新书入库系统登录视情况可能不体现业务价值视场景保留或省略最后一行单独说一下。登录要不要画争论了很久。我的处理方式是看它有没有承载业务价值如果登录之后能做的事彼此独立、登录本身不产生业务结果那就省略如果系统里存在普通读者和VIP读者这类由登录区分的分支流程那保留也无妨。软考的标准答案倾向是省略因为登录属于系统级公共功能画上去会让图变啰嗦。2.4 拿图书管理系统跑一遍第一轮把上面三步合起来用图书管理系统做一次完整的第一轮拆解。参与者先分成三类读者侧借阅者、管理侧图书管理员、系统侧系统管理员再加上两个外部系统参与者校园一卡通接口、短信通知平台以及一个非人的触发者——时钟。用例部分把需求里所有动作捞出来再合并得到的大致清单是借书、还书、续借、预约图书、查询图书、查询借阅记录、缴纳逾期罚金、维护图书信息、维护读者信息、统计借阅报表、生成逾期清单、发送逾期提醒。这十二个用例覆盖了系统的绝大部分业务目标而且每一个都能对应到某个参与者主动发起的意图颗粒度基本一致。第一轮画完就可以停下来看一眼有没有哪个椭圆特别大明显能拆成好几件事有没有哪个椭圆特别小小到参与者根本不会专门发起有没有参与者只连了一条线孤零零挂在旁边这三类问题各修一遍图就站得住了。3. 关联、包含、扩展、泛化四种关系的判定标准3.1 关联关系为什么那条直线不该加箭头参与者和用例之间的那条线叫关联表示参与者能触发这个用例。它通常画成一条实线不加箭头或者加一个空心箭头都行——UML 2.x 里两种画法都合法但考试和评审场合我更推荐不加箭头也就是双向关联的默认画法。原因是关联本身只表达可以交互不表达控制流方向加了箭头容易让人误以为存在调用关系。真正容易出错的是参与者自己之间的连线。有些同学想表达图书管理员可以操作系统管理员的功能就直接在两个参与者之间画一条线这是错的。参与者与参与者之间只允许泛化关系空心三角箭头的继承不能有普通关联。如果两个角色之间真的有交互那属于业务层面的事应该在需求描述里说清楚而不是塞进用例图。3.2 include被抽出来的公共行为包含关系«include»解决的是多个用例里重复出现的公共片段。判定条件有两个缺一不可一是这段行为被两个以上的用例使用二是这段行为本身是一个完整的功能单元可以被独立命名。画法上有个经典易错点箭头方向是从「基用例」指向「被包含用例」也就是说发起方指向被复用的那一方。比如借书和续借都需要先验证读者状态那应该是借书和续借各画一条虚线带 «include» 标签箭头指向验证读者状态。很多人把箭头画反写成验证读者状态指回借书这在语义上完全说不通。再强调一遍使用门槛如果某段行为只被一个用例使用那就算它再独立也不该拆出去做 include直接写成该用例内部的一个步骤就行。为了看起来专业而滥用 include是用例图退化成流程图的头号原因。3.3 extend有条件才发生的可选行为扩展关系«extend»表达的是在特定条件下才插入的可选行为。判定关键在条件两个字基用例在通常情况下能独立完成扩展用例只在条件成立时才追加进去而且基用例本身不知道扩展的存在。箭头方向和 include 正好相反从「扩展用例」指向「被扩展的基用例」。举例来说还书这个用例正常走完就结束了但如果读者已经逾期系统需要额外走一遍缴纳逾期罚金那缴纳逾期罚金就是扩展用例虚线带 «extend» 标签箭头指向还书。整条链路读下来就是正常情况还书流程闭环逾期这个附加条件触发时才多出一段。include 和 extend 的分水岭说白了就一句话被拆出来的那段行为是每次都要执行还是只在条件成立时才执行每次都要执行的用 include有条件的用 extend。这个判断标准朴素但极其好用考场上比什么都快。3.4 泛化参与者泛化与用例泛化泛化关系画成实线加空心三角箭头箭头永远指向父元素。它有两种用法一种是参与者泛化一种是用例泛化。参与者泛化处理的是多个角色共享同一批用例的场景。比如校内读者和校外读者都能查图书、都能借书但只有校内读者能预约。这时候可以抽出一个父参与者读者把查图书、借书这类通用用例挂到父参与者上然后让校内读者和校外读者分别继承各自再挂自己的专属用例。这样做的好处是不用把同一个用例重复连好几条线图会干净很多。用例泛化用得相对少一般出现在某个用例是另一个用例的特化版本的场合。比如缴纳罚金可以特化成现金缴纳和在线缴纳。需要注意的是用例泛化在实际评审里经常被认为属于过度设计——如果两种缴纳方式的业务差异很大那不如干脆拆成两个独立用例差异很小那就一个用例配一段文字说明。我个人的经验是除非确实存在可替换的多种实现路径否则别用用例泛化。3.5 一张对照表把四种关系的判定条件钉死关系符号箭头方向判定条件典型例子关联实线可无箭头参与者能触发该用例管理员 — 维护图书信息包含虚线 «include»基用例 → 被包含用例行为被多个用例复用且可独立命名借书 → 验证读者状态扩展虚线 «extend»扩展用例 → 基用例条件成立时才追加基用例可独立完成缴纳罚金 → 还书泛化实线 空心三角子元素 → 父元素存在一般到特殊的分类层级校内读者 → 读者这张表可以当口诀背。考场上先判断是不是参与者连线是就填关联不是再看箭头方向指向被复用的那方是 include指向被扩展的那方是 extend如果出现了继承层级那就是泛化。按这个顺序过一遍四种关系基本不会填错。4. 软考中级软件设计师真题里的用例图套路4.1 真题反复考的三种题型翻近几年软考中级软件设计师的卷子用例图相关的题目大致跑不出三种形态。第一种是选择题给一小段需求描述问参与者是谁、某个用例和另一个用例是什么关系、某个动作该不该作为独立用例。这类题考的是概念边界属于送分题但每年都有人丢分。第二种是下午题里的填空。题干给一张画了一半的用例图参与者画好了用例只填了一部分或者关系标签空着让你根据需求文字补全。这种题的难点在于信息全藏在文字里必须逐句对应一旦漏读一句就会漏一个空。第三种是让你判断给定用例图里的错误。可能是参与者画在了边界框里面可能是 include 箭头画反了可能是两个参与者之间连了关联线也可能是把内部模块当成了参与者。这类题看着开放其实考点很固定就是上面讲的那些判定规则。4.2 从题干文字反推填空答案下午题的答题节奏我自己是这么走的先通读需求标出所有出现的人名、角色名、系统名这一步对应参与者空再把所有动词短语圈出来对应用例空最后重点抠那些出现如果当……时自动必须的地方这些词后面藏的基本都是扩展或包含关系。有个特别好用的技巧是看句式。系统可以……通常对应一个基础用例当……时系统需要……通常对应扩展在……之后系统……如果这个动作被多个场景提到通常对应包含。掌握这三种句式填空的准确率会明显提升。另外提醒一句题干里出现的名词不一定都是参与者。像数据库服务器接口层这类名词属于系统内部构成题目里提到它们只是背景交代不要往上填。4.3 include 与 extend 的真题判定实例举个典型题干读者归还图书时系统首先记录归还信息。如果该书已超过归还日期系统需要计算逾期天数并生成罚金记录。这里记录归还信息是还书流程的固有部分不单独拆计算逾期天数并生成罚金记录带明确条件如果已超过归还日期而且还书流程本身在没有逾期时也能正常走完所以它是扩展箭头从计算罚金指向还书。再换一段读者办理借书和续借时系统都需要先验证读者的借阅资格和当前借阅数量。注意都需要三个字——这是复用信号说明验证借阅资格被两个用例共同使用属于包含关系箭头从借书续借分别指向验证借阅资格。同样是验证类动作一段写成条件触发一段写成共同复用答案就完全不同。差别只在如果和都需要这几个字上读题时用笔圈出来基本不会翻车。4.4 答题格式与最容易丢分的四个细节答题书写上有几个地方每年都有人栽。一是关系标签的写法规范是双尖括号包住关系名写成 «include» 和 «extend»别只画一条虚线不写标签。二是箭头方向include 从基用例指向被包含用例extend 从扩展用例指向基用例这两个方向记反了扣分很实在。三是参与者不能画在系统边界框内画进去等于承认它是系统内部的东西。四是用例命名必须动宾结构借阅管理图书模块这种名词性写法在阅卷标准里是不给分的。还有一个细节容易被忽略系统边界框一定要画并且要写上系统名称。有些同学的答案图只有参与者、用例和连线没有那个大方框虽然内容没错但结构分拿不满。5. 图书管理系统用例图从零到成图的完整实操5.1 需求梳理与角色划分假设需求是这样一段描述读者可以查询图书、借阅图书、归还图书、续借图书、预约已被借出的图书、查询自己的借阅记录、缴纳逾期罚金图书管理员负责图书信息维护、读者信息维护、处理借还业务、生成借阅统计报表系统每天凌晨自动统计前一天的借阅情况对即将到期的借阅发送提醒系统需要通过校园一卡通接口核验读者身份通过短信通知平台发送提醒。按角色划分参与者一共六个借阅者、图书管理员、系统管理员、校园一卡通接口、短信通知平台、时钟。其中校园一卡通接口和短信通知平台是外部系统时钟是非人触发者这四个是最容易被漏掉的。再确认一遍边界图书馆管理系统本身包含图书信息、借阅记录、读者资料这三块数据校园一卡通只负责身份核验短信平台只负责消息投递两者都在边界外。边界一旦画清楚后面的连线就不会乱。5.2 用例清单与关系标注按前面讲的合并与筛选规则整理出十二个用例借书、还书、续借、预约图书、查询图书、查询借阅记录、缴纳逾期罚金、维护图书信息、维护读者信息、统计借阅报表、生成逾期清单、发送到期提醒。关系部分逐个过一遍。借书和续借都要核验读者身份所以抽出核验读者身份作为被包含用例两条 «include» 虚线分别从借书、续借指向它。还书时如果存在逾期需要缴纳罚金所以缴纳逾期罚金是扩展用例箭头指向还书。生成逾期清单由时钟触发发送到期提醒由短信平台承接这两条用关联线连到对应参与者。参与者泛化方面图书管理员和系统管理员都涉及读者信息相关的部分操作可以抽一个父参与者系统用户让两者继承把公共的查询借阅记录挂到父参与者上减少连线数量。5.3 图形布局与工具选择布局上有几条实战经验。参与者统一放在左右两侧或者上下两端不要围着方框乱撒。用例按业务分组摆放比如借阅相关的放一起信息维护相关的放一起报表相关的放一起视觉上一眼能看出模块划分。连线尽量不交叉实在交叉就在交叉处画一个小跳跃符号或者用弧度绕开。工具方面做课程设计和项目文档我用得比较多的是几款免费在线建模工具优点是导出图片方便、支持中文标签写技术文档的时候更倾向于用纯文本描述的绘图语言因为改起来快版本管理也友好改一行字就能重画一张图不用重新拖拽对齐。软考考场上只能手绘那就记住一个原则先把方框、参与者、用例的位置铅笔轻轻标一遍确认不挤了再描实能省下大量涂改时间。5.4 交图前的自检清单图快画完的时候按下面这张清单逐条过一条不合格就回去修。系统边界框是否画了名字是否写全。所有参与者是否都在框外有没有混进内部模块。每个参与者是否至少连了一条线有没有孤立的角色。每个用例是否至少连了一个参与者或者一个关系有没有孤立的椭圆。用例命名是否全部是动宾结构。«include» 箭头是否从基用例指向被包含用例。«extend» 箭头是否从扩展用例指向基用例。参与者之间是否存在关联线不允许只能泛化。是否有两个用例名字重复或者语义重复。是否存在只被一个用例使用的 include应改回普通步骤。这张清单我用了很多年几乎每次都能揪出两三个问题尤其是第八条和第十条出错率最高。6. 图画完之后评审时最常被挑的毛病与用例规约6.1 系统性缺陷缺边界、命名不一致、关系滥用评审时被挑得最多的一类问题是缺少系统边界。很多人觉得那个方框没信息量就省了但在评审视角里没有边界框的用例图无法判断哪些是你负责的系统、哪些是外部依赖等于需求范围没界定。第二类问题是命名不一致。用例图里写借阅者需求文档里写读者数据库设计里写user三套叫法混着来。评审的人不会去帮你对齐只会觉得你没想清楚。我的做法是画图之前先定一张术语表人、角色、实体、用例的名字全部统一后面所有文档都从这张表取词。第三类问题是关系滥用。图上密密麻麻全是 «include»掰开一看八成都是可以合并回主用例的内部步骤。判断标准还是那句老话被拆出来的行为是否被多个用例复用、是否是完整功能单元。两条都满足才拆只满足一条就留着。6.2 用例规约该怎么配用例图的下半场用例图只画出了轮廓具体每个用例怎么走要靠用例规约补。规约一般包含这几个部分用例名称、参与者、前置条件、后置条件、主事件流、备选流、异常流。主事件流是正常情况下从触发到结束的步骤序列备选流是条件不满足时的分支异常流是出错时的处理。拿借书举例。前置条件是读者身份已核验且借阅额度未满后置条件是借阅记录新增一条、对应图书可借数量减一主事件流是读者提交借书请求、系统核验身份、系统检查额度、系统登记借阅记录、系统提示借阅成功备选流是额度已满时提示拒绝并给出可借数量异常流是核验接口超时提示稍后重试。提示主事件流的每一步都应该是一个可以被参与者感知的动作不要写成系统调用 DAO 层查询数据库这种实现细节那属于设计文档的内容。6.3 一个可复用的小模板最后给一个我一直在用的规约模板直接抄就行用例名称动宾结构与用例图上的椭圆文字完全一致。参与者主参与者是谁有没有辅助参与者比如支付接口。前置条件执行该用例之前系统必须满足的状态。后置条件用例成功结束后系统发生的状态变化。主事件流编号列出正常路径每条一句话动作主体明确。备选流编号列出分支标明触发条件。异常流编号列出异常标明处理方式。业务规则额度上限、逾期天数计算方式这类约束。模板本身不复杂难的是坚持让每一个椭圆都配一份规约。我见过太多只交图不交规约的作业评审的时候被问一句这个备选流怎么处理就答不上来。我个人在做课程设计和写需求文档时最大的体会是用例图的价值不在于它画得多完整而在于画图这个动作逼着你把谁用、用来干什么、什么情况下有不 一样的分支这三件事逐条回答清楚。图上的每一个椭圆背后其实都有一份没写出来的规约图画完、规约补齐、术语统一这套东西才算是真的交付了。