2. 先摸透底细扩展特征和用例到底在需求分析里扮演什么角色很多第一次接触用例建模的人拿到定义扩展特征【用例】这个题目时第一反应是翻UML规范找标准答案。我可以直接告诉你结论UML规范里关于扩展关系extend的官方定义只有寥寥几百字真正让这个知识点变得烧脑的是它在需求分析和系统设计之间那座桥梁的位置——你得知道什么时候该用它什么时候用了反而是添乱。扩展特征本质上描述的是一种可选的、有条件触发的行为变体。举个生活化的例子你去便利店买水最核心的流程是扫码付款——拿水走人。但如果店员突然跟你说加3块钱可以换购一瓶功能饮料你决定换购这就从买水的主流程里岔出去了一条支线。这条支线不是每次都会发生它有触发条件店员推荐了、你有零钱、你想换而且买水这个主流程本身完全可以独立完成。在UML用例图里这种关系就是扩展关系那条支线就是扩展用例。我们这个项目标题里的定义扩展特征实际要做的是把这种支线行为从主流程里剥离出来用规范的符号、准确的规则和清晰的边界把它表达成独立的用例。这事儿如果干得漂亮需求文档的可读性和系统的扩展性会同时上一个台阶后期开发和测试人员拿到手就能明白哪些路径是路径主干、哪些是分支场景如果干得稀烂用例图就会变成一张密密麻麻的蜘蛛网每个用例之间互相拉扯评审会上被问到这个分支到底怎么触发这个行为算主流程还是算扩展的时候全员沉默。我见过太多团队在这一点上翻车根子在于他们把识别用例和定义扩展特征混为一谈。识别用例是靠业务事件触发而定义扩展特征靠的是对行为变体的精准切割。我们的核心任务就是把这块切割的刀法练好包括三个层次第一判断一个行为到底算独立用例、包含用例还是扩展用例第二用标准的UML符号把扩展关系画出来第三把扩展条件的细节写到需求规格里让开发和测试没有歧义。这个内容适合谁来读如果你正在做系统需求分析、用例建模或者你是初入行的产品经理、业务分析师、软件架构师甚至你只是在准备系统架构师考试这篇文章都能给你一套可以直接落地的判断标准和实操步骤。下面会给你一种判断思路当你在为业务流程图里那些如果……那么……否则……分支发愁的时候就是用扩展特征化解复杂度的时候。3. 核心概念速通扩展关系、扩展点、扩展条件三个概念先整明白在讲实操之前必须先把三个容易搞混的基础概念掰扯清楚因为它们像榫卯结构一样扣合在一起缺一个扩展特征就只是个空壳。扩展关系Extend Relationship是UML用例图中的一种连接器方向性很关键。它带箭头从扩展用例指向被扩展的基用例。很多初学者画反方向一画反整个语义就完全错了。箭头指向基用例表示的含义是扩展用例在符合特定条件时会主动插进基用例的执行流程中。注意是扩展用例主动依附到基用例上基用例对此毫不知情也不依赖扩展用例的存在。这有点像手机装App手机系统本身功能完整装不装某个特定App都不影响打电话、发短信但一旦你装了你就能在特定场景下多出来一些能力。扩展点Extension Point是基用例内部预先声明的一个插槽。它给扩展行为标出了一个精确的插入位置。比如在线购物下单这个基用例扩展点可以定义在填写收货地址和选择支付方式之间。有了这个位置锚定扩展用例中的行为片段的插入时机就非常确定了。一个基用例可以有多个扩展点一个扩展点下也可能挂多个扩展用例这都需要在用例说明中写清楚。扩展条件Extension Condition描述的是扩展行为被触发的限定条件。这是扩展关系最具实战价值又最容易被偷懒跳过的部分。经典的反面教材是只画一条虚线箭头但完全不写什么时候触发。比如ATM取款用例扩展是打印凭条条件通常可以写成用户选择需要凭条。如果不在用例描述里把这个条件写明开发人员会默认所有取款都弹出一个打印凭条确认框逻辑就会多走一步跟真实业务流程产生偏差。更进一步还可以加上时间窗条件比如系统的运营活动窗口内才允许触发优惠秒杀出了窗口就恢复原流程。把条件量化得越清楚代码实现就越不需要猜。这三个概念对应的最核心的一句话就是扩展特征是一种可选行为它只在特定条件下、在特定位置插入到主流程里主流程缺了它依然完整。有了这个共识后面那些技巧才有了着落点。4. 火候判定什么时候该用扩展关系什么时候应该用包含关系或者独立用例现在到了最有实战价值的部分。我可以给出一个表格直接帮你做该用哪个的决策这张表也是我每次做用例评审时心里默念的清单。判断维度用扩展关系Extend用包含关系Include用例独立是否每次主流程都执行否只在特定条件下触发是只要走主流程就必须执行它是另一条独立的用户目标主流程缺少它是否完整完整没有它业务流程照常跑不完整缺少它核心流程没法收尾它是单独有价值的业务流程触发条件是否明确是需要写清楚条件表达式不需要天然要执行没有依附关系典型场景特殊规则、优惠活动、可选的增值服务身份校验、日志记录、统一支付登录、查询、下单这类独立业务举个例子应该就秒懂了。一个外卖下单用例如果里面有个步骤叫用户实名认证这件事在每次下单前都会发生而且不完成就没法继续下单那它就是包含关系需要用 include 指向它。但如果有个步骤是使用平台发放的优惠券抵扣金额用户完全可以选择不用券流程正常走那它就是扩展关系画一个 extend 指向确认订单金额这个扩展点。还有一种情况你可能需要把这个行为提升为一个独立的用例而不是挂在任何基用例下面。比如申请退款这个动作虽然它跟下单有业务关联但它本身有完整的用户意图用户就是要来退钱有独立的触发入口那就没有理由去把它设计成下单用例的扩展。把它独立出来后续的权限设计、状态流转、财务对账都更好处理。用我踩过的坑来给你反向提个醒如果一个团队在评审时对某个动作算不算扩展纠缠超过15分钟通常不是技术问题而是需求本身的业务边界没理清。这时候比较好的做法是跳出来问两个问题如果去掉这个动作用户的核心目标还能达成吗以及这个动作的成功或失败会导致主流程的结果发生改变吗如果两个答案都是否那它大概率只是一个附属的、可选的特征符合扩展关系的定位。5. 定义扩展特征的四步实操流程按这个顺序走不容易翻车5.1 第一步圈定候选扩展行为不要把目标一开始就聚焦在怎么画弧线、怎么拉箭头。先把能想到的功能点、流程分支全部列出来。做法是拿一份业务流程说明或者用户故事列表给你的流程图每个分支标一个记号。常见的高概率候选扩展行为有异常路径比如超时、校验失败、库存不足这些兜底逻辑可选增值项比如短信通知、发票开具、加急配送外部规则插入比如合规检查、风控拦截、权限审批业务活动期间临时增加的规则比如双11的满减、秒杀、限购。在实际项目中我一般会分两轮。第一轮快速列只问这个分支存在不存在不去想它最终以什么身份进用例图。第二轮才是做筛选拿到候选清单后逐一对照上文那张决策表。第一轮收集得越宽松越好宁滥勿缺避免把真正重要的行为变体埋没在流程文档里。5.2 第二步确定基用例和扩展点选好候选行为之后再找出它依附的主流程用例也就是基用例。这里的经验是找那个能独立完成用户目标、信息量最完整的用例。比如预约挂号和在线支付,如果扩展行为是医保结算报销,它的被依附主体通常是预约挂号流程里收付款环节所在的那个用例而不是把用户登录拿来做扩展的挂靠点——登录用例的职责边界太窄塞它是没有意义的。确定基用例后扩展点要用动词短语精确表达避免模糊。比如完成支付动作之后订单状态变为已发货时提交表单通过校验后。我在评审中经常见到有人写用户操作过程中这种等于没写因为整个过程都是操作过程中。扩展点应该细化到几乎可以直接对应代码里一个钩子函数的位置这个精度才算合格。5.3 第三步编写扩展条件及可选的扩展片段描述这一步是全文的重中之重。扩展条件建议用结构化表达式来描述一般由条件和动作拼接起来。比如扩展条件当用户在下单页面勾选了使用优惠券抵扣选项且当前账户存在有效优惠券。很多人只写到当用户选择使用优惠券漏掉了第二种限制条件导致开发实现时在看到优惠券过期场景下还要回头确认需求。把条件写完整至少覆盖以下三个维度前置环境状态账户有无优惠券、系统是否处于促销期、用户显式动作勾选、点击、输入、系统内部状态库存余量、风险评分。三个维度缺一不可。至于扩展用例本身的描述标准做法是写一段行为片段behavior fragment说明从扩展点接入后系统做什么事情。它跟普通完整用例的写法不同不需要独立的为主目标服务的完整场景它只需要描述插入的那几段step。一个扩展用例内可以包含多个扩展片段。这一点新手容易忽视我建议在编写时明确加一个小标签比如扩展片段开始/结束既方便审查者也方便测试用例工程师划定边界。5.4 第四步绘制用例图并编写用例描述最后一步才是画图。在UML用例图中扩展关系用带箭头的虚线表示箭头指向基用例线上标注extend。同时用注释或者专门图形把扩展点标注在基用例的椭圆内部并用虚线引到扩展用例上。图形方面各家工具大同小异PlantUML、StarUML、Enterprise Architect都有原生支持。画图有个节奏的问题建议不要一上来就追求全量用例图先画一张全局鸟瞰图把基用例和扩展用例的依附关系点亮然后针对最复杂的那个基用例单独画一张局部放大图里面把扩展点位置和条件写详细。毕竟一张图塞下50个用例信息密度过高。这里我可以给个PlantUML的示意方便你快速上手startuml left to right direction :顾客: -- (在线下单) (在线下单) .. (使用优惠券) : extend\n条件勾选优惠券且账户有有效券 (在线下单) : 扩展点确认订单金额后 enduml画完图之后必须回到文本描述层面因为在很多规范的项目里用例图只是索引真正的细节都在用例描述文档里。描述文档至少要包含编号、用例名称、参与者、前置条件、后置条件、主成功场景、扩展条件与扩展点绑定说明。很多团队只画图不写描述最后的结果就是图上看起来工工整整一到开发反推逻辑就处处碰壁。6. 实战演示一个电商会员订单系统里的扩展特征定义全过程理论铺垫够了下面用一个我实际参与过的电子会员订单系统来做整体演示。需求描述很简单用户在商城购买会员礼品下单成功后系统会生成订单。但订单生成后有几种可选行为需要建模。第一段风险订单复核。这个行为只有命中风控规则时触发。比如下单地址与常用地址不一致、下单频次异常、同一设备短期内注册多个账号。如果命中系统的订单将由自动流转切换为人工审核。那么这个行为作为一个独立的用例风险订单复核挂在基用例提交会员礼品订单的订单创建成功后扩展点下方扩展条件明确写系统风控引擎返回风险等级≥高且订单状态位已进入待审核状态。最关键的是基用例提交会员礼品订单的主流程在正常情况下并不依赖这个人工审核它完全可以在系统判定无风险时直接完成下单这就是它的可选择性。第二段电子券包自动发放。用户下单成功后系统有时会额外赠送一张电子优惠券可它并不是每次都触发条件通常设计为新用户首单或者当月消费满三次。把这个自动发放优惠券设计成扩展用例挂在订单确认扩展点下条件明确为用户满足首单奖励条件或月消费满3单。这样设计的好处非常明显当运营想做第四季度拉新活动、把首单用户的门槛降低时只需要修改扩展条件主用例码字不用动真正做到了一处改动、隔离影响。第三段订单信息推送通知。这个行为的技术实现可以对接短信、Push、邮件等多种渠道。它显然不是主流程的组成要件用户下单成功与否跟通知发送成功与否没有强关联。所以它也是一个标准的扩展用例挂点在订单状态变为已支付之后。如果后续要接入微信模板消息只要新增一个扩展用例或修改推送渠道参数不会污染订单主流程逻辑。这个真实的例子里扩展定义的判断口径就非常有代表性了。你可以拿它当一个标准模板来套自己的项目。每次做扩展封装时问一遍基础主流程能不能独立跑完扩展条件是否可量化、可测试挂载的扩展点位置是否唯一无歧义三个条件全部通过就可以放心大胆地用扩展关系。7. 六个高频错误和排查技巧都是血泪教训换来的7.1 错误一把异常处理全部画成扩展用例异常路径和扩展行为有关系但不是一个东西。比如数据库连接超时、第三方接口宕机这类技术异常属于系统内部健壮性设计跟业务用例的可选行为不是一个层面。如果你把系统超时重试这种用例画进了业务用例图整个图就会充满纯技术噪音业务方看不懂开发还得不停地解释这个用例实际上是哪段代码。正确处理是异常的兜底逻辑放在用例的异常场景章节里描述而不要单独开辟一个扩展用例。7.2 错误二滥用扩展关系造成用例图本身丧失可读性有些同事追求所谓完全解耦凡是稍微带一点其他可能性的步骤都想从主用例拉出去当扩展。前期看着模块化很清爽等到系统迭代到第三个版本主用例的壳里什么都没剩全身上下全是扩展插槽整个图从远处看就像一只刺猬。真实业务没那么复杂大胆地把那些紧密相关的行为放在主流程里把真正可选的、可管理的才抽出来。哪怕是扩展用例一个基用例名下挂超过五六个扩展也要警惕过度设计。7.3 错误三扩展条件和基用例状态没有绑定很多新手写条件只写业务侧条件不写系统状态位。比如当用户请求开发票但没说明这个请求发生在订单已支付、订单已完成还是任何状态。结果评审会上开发和测试会追问那如果用户支付失败还点开发票呢这就是模糊条件产生的连锁歧义。正确写法是当订单状态为‘已支付’且用户点击‘申请发票’按钮时。7.4 错误四扩展用例与包含用例在实际实现中被当成同一种东西实话说代码实现层面很多扩展关系其实就是if语句的判断分支包含关系则对应固定的函数调用。如果你在建模阶段把方向搞错到了代码层面容易出现该必选的逻辑成了可选项或者该可选的逻辑被写进每个主流程执行路径白白增加无用开销。所以团队如果内部实现语境能用哪个分支写完会被跳过来检验收到的效果一定更直观。7.5 错误五基用例对扩展用例无感知变成彻底无感知连触发入口都断了这里有一个很容易走极端的误区。扩展关系在语义上确实不要求基用例感知扩展用例但是在实现上触发扩展的总入口必须在基用例流程中存在。比如你预售订单系统里有优惠券抵扣,基用例主流程的订单金额计算这一步必须设计一个判断是否存在有效优惠券并调用扩展用例的入口逻辑。如果不留这个口子扩展用例画得再漂亮也只是空中楼阁永远无法被触发。所以在基用例的设计上除了必要的状态位还必须保留扩展点钩子的概念。7.6 错误六忘记维护扩展用例的后置条件后置条件是经常被忽略的挂载点。一个扩展用例执行完成后它可能修改了系统状态比如优惠券状态变更为已核销、可能产生了新的子系统消息比如触发推送、也可能改变了主流程的后续走向比如风控复核导致订单状态回到草稿。在主成功场景不变的情况下需要明确说明扩展片段执行后主用例是继续回归原路径还是被分叉到另一条路径。这一点没写清楚测试用例设计就会漏掉关键路径的断言。8. 一个收尾的实用提醒扩展特征的定义要与用户故事和验收标准联动从经验上讲单独定义扩展特征不会发挥最大价值一定要把它跟用户故事以及验收标准联动起来。在需求拆解阶段一个带有扩展特征的用例最终应该生成一条或几条独立的用户故事并且这些故事的验收标准里要以Given-When-Then格式显式覆盖到扩展条件的布尔组合。比如风险订单复核扩展用例对应的用户故事可以是作为风控运营人员我希望系统在检测到高风险的订单时自动进入人工审核队列以便我能更高效地拦截可疑交易。它的验收标准可以拆成给定一个订单状态为待支付且风险等级为低时当用户完成支付那么订单正常流入已完成状态不触犯风控人工审核逻辑给定一个订单状态为待支付且风险等级为高时当用户完成支付那么订单状态自动更新为待人工审核并给风控运营发送待办提醒。这样定义的扩展特征才能真正从纸面落到开发任务和自动化测试用例里而不是停留在建模文档里当一张装饰画。每次评审的时候我都会拿着用户故事跟用例图对照一遍一旦发现某条用户故事描述的行为找不到对应的扩展用例或者某个扩展用例没有对应的用户故事和验收标准那就说明建模和需求链条有脱节趁早理顺越往后拖成本越高。一句话经验是扩展特征定义得好不好不在UML符号画得顺不顺眼而在于它能不能精确回答什么条件下、在什么位置、执行什么事情、结果如何影响主流程这四个问题。把这四个问题吃透了你已经跑赢大多数项目团队了。