简介网上购物系统用例图是一份面向软件工程、UML建模及数据库课程设计的文档资料适合需要完成在线交易系统需求分析的学生、开发人员与系统设计者参考。资源包共1个文件以doc文档形式呈现压缩包大小约319KB内含系统管理员、客户、公司三类角色的完整用例划分覆盖登录注册、修改密码、商品评价、交易查询、在线购买、发货处理与退货管理等典型业务流程。内容可帮助读者快速梳理系统边界与角色权限理清用例之间的关系也可为毕业设计或课程报告中的需求分析、功能模块设计提供绘图依据。目前已有3342人学习下载适合正在绘制或讲解购物系统用例图、需要快速获取规范图例与业务场景说明的人群使用。1. 一张“网上购物系统用例图”卡住整个需求评审先画边界再画功能很多团队交出的网上购物系统用例图乍看很全——“用户登录、用户注册、用户加购物车、用户下单、用户支付”一长串椭圆排在那里评审会上一句“支付是你们自己做还是调外部渠道”就能让全场沉默。这是画用例图最常见的翻车现场把用例图当成了功能菜单的排列组合而忘了它是“系统边界 角色价值”的可视化契约。用例图不是给程序员看的操作清单它是用来回答“谁在用系统、系统为谁做什么、哪部分是我该做的”这三件事的。这篇文章不铺开讲 UML 理论只讲怎么把一个购物网站的需求拆成可评审、可排期、可测试的用例图以及哪些地方最容易画错。适合正在做需求分析、准备写设计文档、或第一次带模块开发的读者。2. 网上购物系统的建模底层逻辑参与者、系统边界和三种用例关系2.1 参与者不是“用户”两个字先把角色摆清楚用例图里的参与者指的是“在系统边界之外、与系统发生交互的角色”。这个角色可以是人也可以是外部系统。很多草稿图里只有一个叫“用户”的小人这恰恰是后面所有争议的源头——购物系统的用户至少分成“游客”和“买家”两拨游客能浏览商品、搜索商品但加入购物车和下单必须登录买家在游客能力之上多了下单、支付、评价、申请售后这些动作。如果再往后台看还有商家角色要上架商品、处理订单有平台运营要管理类目、审核商品有客服要处理退款和投诉。把这些角色分开画不是形式主义它能直接指导权限设计和功能拆分。我一般会让团队先列“谁会用这个系统”把人放在系统边界框的外面角色之间的差异用泛化关系表达买家继承游客的浏览和搜索再扩展出购买相关的能力。外部系统也要作为参与者出现比如支付渠道、物流系统、短信服务。它们在边界外却决定了系统里很多用例的走向。画错这一步后面要么漏掉游客场景要么把外部系统当成自己要做的事。2.2 系统边界决定哪些用例属于你支付、物流别画进框里系统边界是那个把用例包起来的矩形框。框里面是本系统自己实现的业务功能框外面是外部角色和外部系统。网上购物系统里最容易画错的就是支付和物流。我们通常会把“发起支付”“接收支付回调”“查询物流轨迹”这样的交互用例画在框内因为这些动作由我们的系统发起或承接但“资金清算”“快递运输”这类实现属于外部系统绝不能画进边界框里。为什么这个区分这么重要因为系统边界就是需求范围的直观投影。有一次评审团队把一个叫“支付结算”的用例画进了系统边界内结果会上所有人都默认要自建一套完整的资金结算能力工作量从 2 人日直接跳到 20 人日。后来把“支付结算”拆成“发起支付本系统”和“支付渠道处理外部系统”才把范围拉回来。边界画错了用例图就从需求工具变成了范围陷阱。边界外的东西再重要也不是本项目要实现的它们只参与交互。2.3 include、extend、泛化三种关系画法背后的业务语义网上购物系统用例图里关系画法是最容易被抠细节的地方。include 表示“每次执行基本用例时都必须执行被包含用例”画法是虚线箭头加«include»箭头从基本用例指向被包含用例。比如“提交订单”总是要检查库存就画成 提交订单 →«include»→ 库存校验。extend 表示“在特定条件下才执行扩展用例”画法是虚线箭头加«extend»箭头从扩展用例指向基本用例。比如“使用优惠券”不是每次下单都发生它扩展的是“提交订单”所以箭头从“使用优惠券”指向“提交订单”。泛化关系用实线空心三角表示比如“普通订单”和“预售订单”都是“创建订单”的一种。include 和 extend 的方向恰恰是最多人画反的地方。我见过一份图里extend 箭头从“提交订单”指向“使用优惠券”语义变成了“每次提交订单都包含优惠券”评审时产品经理当场质疑逻辑不对。顺手记一个口诀include 是“每次都要的被主用例拖着走”箭头往外指extend 是“看情况的扩展项指向主用例”箭头往回指。方向画对图才经得起推敲。3. 从业务需求到用例图四步做出可评审的购物系统用例图3.1 第一步先画系统边界列出所有与系统打交道的角色画图的第一步不是画用例而是先把系统边界框画出来再在框外摆参与者。这个过程逼着团队回答一个问题“我们这个系统到底覆盖哪些事”购物网站常见的角色清单如下角色位于边界内外核心业务目标游客边界外浏览商品、搜索商品、查看详情买家已登录边界外下单、支付、评价、申请售后、管理收货地址商家边界外上架商品、修改库存、处理订单、查看销售数据平台运营边界外审核商品、管理类目、处理违规、查看运营报表客服边界外查询订单、处理退款、处理投诉支付渠道边界外外部系统完成扣款、返回支付结果物流系统边界外外部系统提供运单号、更新物流轨迹短信服务边界外外部系统发送验证码、发货通知这一步不需要太精确先把所有“会用系统的人”和“会被系统调用的外部系统”摆出来。如果一个角色想不出来具体要做什么事就先留着到第二步反推用例时再验证。注意一点不要在这个阶段把“管理员”这种泛化角色直接扔进去要具体到“谁在管理、管理什么”否则后面用例容易空泛。3.2 第二步按业务流程反推候选用例再按业务目标合并有了角色清单下一步是沿着购物主流程问“用户为了什么目标来用系统”。我习惯按“找商品 → 看详情 → 加购 → 下单 → 支付 → 收货 → 评价 → 售后”这条链路逐段反推。每个业务目标对应一个候选用例然后把“细碎到不值得单独画”的动作合并进更大的业务用例中。例如业务阶段候选用例处理建议找商品搜索商品、按类目筛选、浏览推荐位合并为“搜索与浏览商品”看详情查看商品图片、查看参数、查看评价并入“浏览商品详情”评价明细单独列加购加入购物车、修改购物车数量、删除购物车商品合并为“管理购物车”下单选择收货地址、填写订单备注、生成订单合并为“提交订单”地址选择作为主流程步骤支付发起支付、查看支付结果合并为“支付订单”收货确认收货、查看物流分开为“确认收货”和“查询物流”售后申请退款、申请换货、查看售后进度合并为“申请售后”合并原则只有一条这个用例对应一个完整的、用户可感知的业务目标。把“填写收货地址”这种子步骤画成一个独立用例就会让图变成操作流程图粒度崩掉。合并之后给每个用例起一个动宾短语名字“搜索与浏览商品”“提交订单”“支付订单”“申请售后”不要用“订单管理”这种名词短语——名词让人不知道动作是什么也不方便后续排期。3.3 第三步用 include 和 extend 梳理用例之间的依赖候选用例列表成型后开始分析用例之间是否存在“每次必须”或“条件触发”的关系。逐个用例问三个问题这个用例在执行时是不是每次都依赖另一个用例如果是画 include。这个用例在某种特殊条件下会不会补充另一个用例的执行内容如果是画 extend。这个用例是不是另一个用例的细分类型如果是用泛化关系。购物系统里常见的关系清单基本用例关系类型关联用例说明提交订单include库存校验每次下单都要先确认库存提交订单extend使用优惠券不是每次都有优惠券支付订单include调用支付渠道每次支付都要走外部渠道登录extend短信验证码登录账号密码之外的扩展方式创建订单泛化普通订单、预售订单不同下单规则公共逻辑相同这里最容易争论的是“登录”。很多人习惯把“用户登录”画成所有用例的 include认为每次操作前都要登录。但用例图表达的是“业务目标”登录只是前置条件。我一般的做法是如果系统强制要求登录后才能下单就把“已登录”写进“提交订单”的前置条件里而不是画成 include。只有当“登录”本身作为一个独立业务目标比如用户主动登录查看个人中心时才画成用例。这样处理图和实现都能对上评审时也不会因为“登录算不算功能”吵起来。3.4 第四步自查用例粒度避免一张图里大小混装最后一步是自查粒度。把画好的图摊开看每个用例是否满足三个条件业务人员能看懂这个用例在说什么这个用例对应一个完整的业务目标这个用例能在一个迭代内开发完成。如果某个用例要拆成三步才能讲清楚说明它是子流程不是用例如果某个用例大到“包含全部交易流程”说明它太粗要拆成“提交订单”“支付订单”“申请售后”这样的粒度。粒度不统一的图最直接的影响是排期失真。我曾见过一个叫“订单管理”的用例被估成 2 天工作量开发打开需求才发现它涵盖订单查询、订单改价、订单取消、订单导出四个子功能最后排期翻了四倍。统一粒度并不难难的是在评审前愿意花十分钟做这个检查。每次画完图我都要指着每个椭圆问一句这真的是一件事吗这句话能挡掉至少一半的返工。4. 把用例图画到能通过评审绘制规范、关系箭头和用例描述模板4.1 绘制规范参与者放框外用例放框内箭头方向不能含糊网上购物系统用例图的版面其实有固定章法参与者画在系统边界框的两侧用例椭圆画在框内参与者与用例之间用实线连接表示“该参与者参与了这项用例”。外部系统画在框外但它与系统内用例之间的交互同样用实线连接。include 和 extend 是虚线箭头必须标注«include»或«extend»字样。泛化关系是实线空心三角从子用例指向父用例。绘制软件随意关键是关系方向检查项正确画法常见错误include 箭头从主用例指向子用例如 提交订单 → 库存校验画成双向或反向extend 箭头从扩展用例指向主用例如 使用优惠券 → 提交订单从主用例指向扩展用例参与者位置全部在系统边界框外把支付渠道画进框内用例命名动宾结构如“提交订单”用“订单管理”“用户操作”外部系统作为参与者出现在框外在框内画“对接支付”用例我见过不少图边界框画得很好但 extend 箭头方向全错导致评审时逻辑越讲越乱。箭头方向不是形式问题它直接表达了业务规则的触发方式。画完图以后我建议按这张表逐项检查一遍再进评审会。4.2 一张“提交订单”用例描述表把每条框线变成可验收的需求用例图只能表达“谁和系统做什么”表达不了“做到什么程度叫完成”。所以画完图还差一步给核心用例配用例描述表。这张表是图和代码之间的桥梁开发排期、测试用例设计都靠它。表头一般包括用例名称、参与者、前置条件、后置条件、主流程、备选流程、异常流程和业务规则。以“提交订单”为例项内容用例名称提交订单参与者买家前置条件买家已登录购物车中存在待结算商品商品库存充足后置条件订单生成状态为待支付库存被锁定或扣减主流程1. 买家进入购物车2. 买家选择要结算的商品3. 系统校验库存4. 买家确认收货地址和发票信息5. 买家提交订单6. 系统生成订单记录并返回订单号备选流程3a. 库存不足提示缺货并允许移除该商品后继续结算异常流程2a. 购物车为空提示无法结算5a. 提交时网络超时系统提示重试并保留已填信息业务规则一个订单只能关联一个收货地址订单编号全局唯一库存扣减在订单提交时完成这张表写清楚后用例图上的“提交订单”就不再是一个模糊的椭圆而是可以逐条核对的需求条目。图负责目录表负责内容两件事不能互相替代。我一般会要求团队至少把“提交订单”“支付订单”“申请售后”这类核心业务用例写成表外围的“查询物流”“修改个人信息”可以只用图表达降低文档维护成本。4.3 三方反向检查开发看实现、测试看场景、产品看业务目标画完图和描述表正式评审前再做一次反向检查让开发盯着每个用例问“这个流程我能实现吗”让测试盯着每个用例问“这个用例我能测出哪些场景”让产品盯着每个用例问“这个用例是用户真正想要的吗”。如果三个问题的答案对不上多半是关系画错、粒度不统一、或者边界判断失误。这个方法听起来简单但能挡住评审会上最尴尬的冷场。让开发看实现能发现“发起支付”和“接收支付回调”是否被混在了一个用例里让测试看场景能发现备选流程是否缺失让产品看目标能发现有没有画进去一个没人用过的“会员积分兑换”。5. 用例图避坑指南五个让评审翻车的建模错误用例图的坑不深但每个都能让评审从技术讨论滑向需求争论。下面这五条我基本都在真实项目里遇到过按“现象 → 原因 → 解决”列出来画图时逐条对照。坑一支付渠道、物流系统被画进系统边界里。现象是系统边界框内出现“对接支付宝”“对接物流”这类用例评审时团队默认这些能力要自己实现。原因是混淆了“交互”和“实现”——我们的系统确实要调用支付渠道但支付渠道本身是外部系统不是我们开发的东西。解决方法是把支付渠道、物流系统、短信服务都画成边界外的参与者框内只保留“发起支付”“查询物流”这些由本系统完成的用例。判断标准很简单这个能力换掉供应商我们的系统要改哪里哪里才是框内的东西。坑二参与者只画一个“用户”。现象是一张图上孤零零一个“用户”小人连着一大片用例。原因是图省事觉得登录后都是一个身份。解决方法是按权限和业务目标拆分参与者游客能浏览和搜索买家能下单和支付商家能上架和管理订单平台运营能审核商品。拆分后用例和参与者的连线才真正表达了“谁能用这个功能”权限设计也能直接从图里读出来。如果工作量大可以用泛化关系让“买家”继承“游客”的能力减少重复连线。坑三include 和 extend 方向画反。现象是评审时说不清“优惠券”到底是“订单的一部分”还是“订单的可选补充”。原因是把两种关系的语义记反了。解决方法是记住两句话include 是每次都要做的子流程箭头从主用例指向子用例extend 是有条件才触发的扩展箭头从扩展用例指向主用例。画完图后用我在 4.1 节给的检查表过一遍两个方向核对一分钟翻车概率基本清零。坑四用例粒度忽大忽小。现象是“提交订单”旁边并排画着“输入收货地址”和“选择配送时间”而另一侧又有“管理订单”这种巨无霸用例。原因是把子步骤和业务目标混在了一张图里。解决方法是统一用“用户能感知的业务目标”作为粒度标准“输入收货地址”是提交订单主流程里的一个步骤写进用例描述表“提交订单”是一个完整用例“管理订单”是多个用例的集合要拆成“查看订单、取消订单、确认收货”。粒度统一后排期和测试才能对齐。坑五只画图不写用例描述。现象是图上有“提交订单”四个字到了开发手里变成“每人对提交的理解都不同”。原因是把用例图当成了需求文档的全部。解决方法是给核心用例配用例描述表至少写清前置条件、主流程和备选流程。图决定范围表决定质量两者缺一不可。如果项目节奏紧我一般要求每个触发支付、订单状态变化的用例必须写描述其余用例至少写前置条件和主流程否则测试连用例场景都列不出来。提示避坑不是画图时小心翼翼而是在评审前照着清单过一遍。对没有专职架构师的中小型团队这五分钟检查能省掉大半改图时间。6. 让用例图真正落地从图反推测试场景和估时技巧6.1 从每个用例推导测试场景矩阵用例图画完别急着归档它最实用的副产品是测试场景矩阵。做法是给每个用例至少写一条主路径、一条备选路径、一条异常路径直接从用例描述表里抄流程再变体。拿“提交订单”举例用例主路径备选路径异常路径提交订单选商品 → 校验库存 → 确认地址 → 提交成功库存不足移除缺货商品继续结算提交时网络超时提示重试支付订单发起支付 → 渠道扣款成功 → 系统更新状态支付中用户退出恢复后继续支付渠道扣款成功但回调丢失订单状态未更新这套矩阵能直接映射到测试用例设计里主路径对应冒烟测试备选路径对应业务规则测试异常路径对应容错测试。有一个项目就是靠这张矩阵在测试阶段提前发现“回调丢失导致订单状态卡在待支付”的问题回填到用例描述表后才堵住漏洞。6.2 用用例粒度估算开发工作量的经验区间我习惯在用例粒度统一后用“每个用例一个估时区间”的方式排迭代。简单用例比如“搜索商品”“查询物流”在数据模型和接口明确的前提下通常 1 到 2 人日中等用例比如“提交订单”“申请售后”涉及库存校验、状态流转和异常分支预留 3 到 5 人日复杂用例比如“支付订单”“订单状态机管理”要对接外部渠道、处理回调、考虑对账补偿按 8 人日起步估。这个小项目让我长了个记性“订单管理”这种大用例估 2 天开发拆出 8 个子功能最后延期一周。现在我的习惯是先做粒度检查再按这个区间估排期说话才硬气。用例图是项目的门面也是排期和测试的源头把这一张图画干净后面每一步都能省事不少。希望帮到你。本文还有配套的精品资源点击获取