简介网上购物系统用例图是一份以UML建模为核心的设计参考文档面向计算机相关专业学生、系统分析设计人员及UML初学者适用于课程设计、毕业设计或项目前期需求梳理阶段用于表现网上购物系统中管理员、客户、公司三类角色与系统之间的交互行为。资源打包为doc格式单文件文档约319KB内容包含系统用例、登录注册管理、在线购买、公司物流管理、公司发货管理等章节便于直接查看、编辑或提取复用。目前已有3342人学习下载是同类需求建模资源中较受欢迎的案例。除完整用例清单外还辅以业务流程图式说明覆盖客户从注册、登录、浏览商品、下单付款到确认收货以及管理员与公司的商品管理、发货退货处理等全流程可帮助读者快速理解系统角色权限边界与核心业务规则为绘制标准UML用例图提供直观参考。1. 网上购物系统用例图先别急着画框想清楚它到底回答什么问题网上购物系统用例图看起来不过是一张画着矩形、小人和椭圆的图却是需求分析阶段最能暴露团队分歧的产物。我见过不少团队跳过用例图直接开建表结果模块权限全靠口头约定联调时炸出一堆歧义。用例图不描述页面细节也不描述数据表结构它只回答一个朴素问题谁在这个系统里能做什么事。买家的下单、管理员的商品审核、游客的浏览、支付回调的触发边界都会被压成一个个椭圆和连线。这篇文章按一次完整建模过程来讲从角色边界到 include、extend 的画法再到用例规格说明表和验收清单让新手画得出来也让熟手少返工。适合电商项目的需求分析、后端开发、测试与产品同学直接上手。2. 用例图的基本构成与网上购物系统的角色边界2.1 用例图的四个核心元素参与者、用例、关系与系统边界很多人第一次画网上购物系统用例图时会先打开绘图工具找模板然后照着网上的示例抄一遍。这个做法本身没错但前提是先搞懂图里每个元素的含义。用例图一共只有四类元素参与者Actor、用例Use Case、关系Relationship和系统边界System Boundary。参与者是站在系统外部、与系统发生交互的人或外部系统在图中用小人图标表示。用例是参与者通过系统完成的一个可观察、可度量的目标用椭圆表示。系统边界是一个矩形框框住的是「当前要建设的系统范围」框外是参与者所处的环境。关系则分为关联实线、include虚线箭头带«include»、extend虚线箭头带«extend»和泛化实线空心箭头四种。这里最容易理解错的是「用例」的含义。用例不等于功能更不等于页面。「用户登录」在严格建模意义上不是一个好用例因为登录本身不带来业务价值但如果把「下订单」当作用例登录就成了它的前置条件。判断一个椭圆是不是合格用例就问一句这个行为完成后参与者拿到了什么可感知的结果买家拿到订单号、管理员完成商品上架、游客看到商品列表这才叫用例。2.2 网上购物系统的参与者清单六个候选角色怎么筛选以常见的网上购物系统为例先列出所有可能出现在图里的候选参与者再逐个判断是否需要保留。判断标准只有一条该角色是否直接与系统交互并追求某个目标。如果只是间接受益不画如果是系统内部组件不画如果交互发生在系统之外也不画。候选参与者与系统的交互是否保留理由游客浏览商品、搜索商品、查看详情保留未登录状态是电商真实入口需要覆盖匿名浏览买家注册用户下单、支付、查订单、退货退款保留核心业务参与者管理员商品管理、订单管理、用户管理保留后台运营的核心角色支付系统接收支付请求、返回支付结果保留外部系统作为参与者与「在线支付」用例交互物流系统获取发货信息、回传物流轨迹看迭代范围首期若只做订单和支付物流查询可放二期不画入本次图数据库管理员维护数据表不保留数据库是系统内部组件不是外部参与者大多数网上购物系统用例图会保留「游客、买家、管理员、支付系统」四个参与者这个组合既能覆盖 C 端主流程也能覆盖后台管理流程。如果你负责的系统还包含卖家入驻那就再加一个「商家」参与者对应商品发布、订单发货、店铺结算等用例。参与者的取舍本质上是业务边界的取舍宁可少画一个也不要为了图好看把无关角色塞进图里。2.3 系统边界怎么划哪些功能放进「网上购物系统」的框里系统边界是网上购物系统用例图里争议最多的地方。常见的翻车方式是把库存管理、物流配送、财务对账全部画进一个矩形里美其名曰「大而全」结果评审时谁也说不清哪个模块是本次迭代要开发的。我给一个实用判断方法凡是本次迭代需要自研开发、修改、升级的功能放进边界内凡是外部已有的、只是通过接口对接的放在边界外。按这个方法商品检索、购物车、订单生成、订单状态流转这些是自研的进边界支付能力、物流轨迹、短信通知这些是外部依赖放边界外并以外部系统作为参与者画交互线。注意边界不是按「系统部署在哪台服务器」划分而是按「本次项目的责任范围」划分。同一套代码里部署的定时任务如果本期不做就不该出现在这张用例图里。3. 把购物流程拆成用例include 与 extend 的实战划分3.1 从一次完整购物旅程拆用例从游客到售后共触发哪些椭圆拿到网上购物系统用例图的任务时我习惯先不打开绘图工具而是把一次完整购物旅程写下来。这个动作看起来笨却能把用例拆得接近完备。下面是一次典型购物旅程的步骤与对应用例游客进入系统浏览首页和商品分类 → 用例「浏览商品」游客通过关键词查找目标商品 → 用例「搜索商品」游客点击某件商品查看价格、库存、评价 → 用例「查看商品详情」游客注册并登录 → 用例「注册账号」登录作为「下订单」等行为的前置条件买家把商品放入购物车并调整数量 → 用例「管理购物车」买家进入结算页确认收货地址和配送方式 → 用例「填写订单信息」买家提交订单 → 用例「下订单」买家选择支付方式并完成付款 → 用例「在线支付」买家查看订单状态、物流信息 → 用例「查看订单」买家在未发货前取消订单 → 用例「取消订单」买家签收后因质量问题申请退款 → 用例「申请退货退款」把这条旅程画成用例图时第 1 到第 3 步归属于「游客」第 4 到第 11 步归属于「买家」。管理员和支付系统的用例先不急着画等 C 端主流程稳定后再叠加。拆用例的粒度以「一个参与者能否独立衡量该行为的结果」为准比如「填写订单信息」是一个用例因为地址和配送方式选完参与者能感知到一个明确结果而「点击按钮」就太细不是用例。3.2 include 与 extend两条虚线怎么决定用例图的质量拆出用例清单后下一步是连关系线。两条最容易被画反的虚线分别是 include 和 extend。先看对比表再讲判断方法。关系语义箭头方向判断问题include包含基用例在执行过程中必须包含子用例子用例是基用例完成目标的一部分从基用例指向被包含用例虚线箭头标«include»缺少它基用例是否无法完整完成extend扩展扩展用例在特定条件下才加入基用例流程基用例缺失它依然成立从扩展用例指向基用例虚线箭头标«extend»缺少它基用例是否依然能完成核心目标以网上购物系统为例「下订单」必须包含「填写订单信息」因为不填收货地址和配送方式就无法生成订单所以从「下订单」画一条虚线箭头指向「填写订单信息」标注«include»。「使用优惠券」则只在用户主动选择时才发生没有优惠券下单流程照样走完所以从「使用优惠券」画一条虚线箭头指向「下订单」标注«extend»。这两个关系的判断方法可以浓缩成一句口诀include 缺了主线断extend 缺了主线不变。画完每条虚线后都拿这句口诀回查一遍基本不会画反。如果你在评审时发现有人把「在线支付」画成了「下订单」的 include可以直接指出问题下单后不支付订单依然存在只是状态为待支付所以支付应当是扩展或独立用例而不是必含子流程。3.3 用 PlantUML 画出网上购物系统用例图可直接改的文本源码文本源码比拖拽画图更适合评审与版本管理。下面这份 PlantUML 代码覆盖了游客、买家、管理员、支付系统四个参与者以及 C 端主流程和后台管理用例你可以直接复制改参数。startuml left to right direction skinparam packageStyle rectangle actor 游客 actor 买家 actor 管理员 actor 支付系统 rectangle 网上购物系统 { usecase 浏览商品 as UC01 usecase 搜索商品 as UC02 usecase 查看商品详情 as UC03 usecase 注册账号 as UC04 usecase 管理购物车 as UC05 usecase 填写订单信息 as UC06 usecase 下订单 as UC07 usecase 在线支付 as UC08 usecase 查看订单 as UC09 usecase 取消订单 as UC10 usecase 申请退货退款 as UC11 usecase 商品管理 as UC12 usecase 订单管理 as UC13 usecase 用户管理 as UC14 } 游客 -- UC01 游客 -- UC02 游客 -- UC03 买家 -- UC04 买家 -- UC05 买家 -- UC07 买家 -- UC08 买家 -- UC09 买家 -- UC10 买家 -- UC11 UC07 .. UC06 : include UC06 .. UC05 : include UC08 .. UC07 : extend UC10 .. UC07 : extend 管理员 -- UC12 管理员 -- UC13 管理员 -- UC14 支付系统 -- UC08 enduml这段源码里几个参数值得说明。left to right direction让参与者集中在左侧、用例集中在右侧能避免连线交叉适合参与者较少的系统如果参与者超过六个建议改回默认的上下布局否则横向空间不够。skinparam packageStyle rectangle只是把系统边界渲染成矩形纯视觉参数删掉不影响结构。usecase 名称 as 别名是给用例起短别名后续关系线都引用别名避免因为改用例名称而改动所有连线。关系线的写法是UC07 .. UC06 : include表示从 UC07下订单指向 UC06填写订单信息。如果你想调整用例名称只需要改usecase ...里的中文文本别名和连线都不用动。这份源码导入绘图工具或命令行渲染后就是一张标准的网上购物系统用例图。如果你用的是 draw.io 这类拖拽工具对应关系是参与者用「Actor」图形用例用「Ellipse」图形边界用「Rectangle」图形关系线用「Dashed Arrow」在标签里填 «include» 或 «extend» 即可。4. 用例图之后用例粒度控制与用例规格说明表4.1 用例粒度为什么「下订单」要拆出一个「填写收货地址」不少初次画网上购物系统用例图的人会纠结一个问题「下订单」是一个用例还是应该拆成「填写收货地址」「选择配送方式」「确认商品清单」「提交订单」四个用例拆太粗评审时看不清业务细节拆太细整张图被椭圆塞满失去沟通价值。我的经验是用例图上的粒度取决于这张图的读者是谁。如果读者是产品经理和测试用来对齐业务需求那么「下订单」作为一个用例即可细节放进用例规格说明表。如果读者是开发人员需要指导模块拆分和接口设计那么「下订单」拆成「填写订单信息」和「提交订单」两级更合适因为这两部分对应不同的页面和接口。判断粒度的三条标准该用例是否描述了一个完整业务目标该目标能否被独立开发或独立测试该目标是否能在一次交互会话中完成。满足这三条的就保留为一个用例不满足的要么上提要么下拆。以「填写订单信息」为例它包含收货地址、配送方式、发票信息但这些都是同一页面同一目标的组成部分合并成一个用例是合理的。反过来如果把「选择配送方式」单独拆成一个用例它无法独立产生业务价值也没有独立的验收入口这种粒度就是过度拆分。同一个系统里用例粒度允许有差异但同一张图内要保持一致否则读者会产生困惑。4.2 从用例图到用例规格说明表一张表格让用例可评审可测试用例图只画骨架真正能指导开发和测试的是用例规格说明表。画完网上购物系统用例图后我一般会为每个核心用例补一张表。以「下订单」为例完整的规格说明表长这样项目内容用例名称下订单参与者买家前置条件买家已登录购物车或商品详情页发起结算主流程1. 买家点击「去结算」2. 系统校验商品库存与状态3. 买家确认收货地址、配送方式4. 系统计算订单金额5. 买家提交订单6. 系统生成订单号并锁定库存7. 系统跳转支付环节异常流2a. 库存不足提示缺货商品并阻断提交3a. 地址缺失提示补充地址后再结算5a. 订单金额变动回到确认页重新确认后置条件生成待支付订单商品库存预占订单状态变为「待支付」这张表的重点是「前置条件」和「异常流」。前置条件写全了开发能明确知道接口要做什么前置校验异常流写全了测试能直接导出异常场景用例。你可以发现有了这张表之后「登录」不再需要画成指向所有用例的 include 线它出现在前置条件里就够了这能大大简化用例图的连线复杂度。4.3 跨系统交互场景支付与库存的边界怎么表达网上购物系统必然与支付系统交互很多用例图在这里画错。一种错误是把「支付」画成系统内部用例另一种错误是让「买家」直接连到「支付系统」。正确的画法是「在线支付」作为系统边界内的用例「支付系统」作为边界外的参与者用实线连接两者。至于支付系统内部怎么完成扣款、对账网上购物系统用例图完全不需要关心。库存的处理可以套用同样思路。如果库存模块属于本次自研范围那么「扣减库存」可以作为「下订单」的 include 子用例画在边界内如果库存由独立的仓库系统管理那么应该把「库存系统」画成参与者放在边界外并画一条关联线指向「下订单」。这两种画法没有绝对对错关键在于和你实际的架构一致。用例图是沟通工具不是为了追求 UML 规范上的满分而是为了让团队在五分钟内达成共识。评审时请架构师确认一遍边界外系统的交互方式比纠结虚线方向更有价值。5. 用例图常见问题排查五个返工率最高的画法错误5.1 把功能清单当成用例图全是方框和箭头没有价值主线现象图上画了「商品列表」「购物车页面」「订单数据库」「生成验证码」这类椭圆参会者看半天也说不清谁在什么时候、为了什么目标使用这个系统。原因把用例图当成了功能模块图画的其实是系统内部组件和页面元素而不是参与者的业务目标。解决回到用例的定义重新筛选。每个椭圆必须能回答「哪个参与者通过这个用例获得了什么可衡量的结果」。商品列表是页面不是用例「浏览商品」才是用例。订单数据库是存储组件不是用例「查看订单」才是用例。把不属于用例的内容删掉保留的椭圆用主流程串起来检查它们是否构成一条完整的业务价值链。5.2 include 与 extend 方向画反评审时被连环追问的重灾区现象图上有「下订单」指向「在线支付」并标 «extend»也有「填写订单信息」指向「下订单」并标 «include»评审时谁也解释不清哪条是主线。原因混淆了「谁包含谁」和「谁扩展谁」的方向规则。include 是基用例指向被包含用例extend 是扩展用例指向基用例。解决画每条虚线前先做判断。问「下订单」缺了「填写订单信息」能否完成不能所以是 include箭头从「下订单」指向「填写订单信息」。问「下订单」缺了「在线支付」是否依然成立成立订单会停在待支付状态所以「在线支付」是扩展或用独立用例处理箭头从「在线支付」指向「下订单」。如果团队里反复出现这个问题建议在评审前把 include 和 extend 的对比规则打印出来贴墙上。5.3 登录被画成万能用例全图一半的线都连着「登录」现象图上「登录」出现一次然后「下订单」「管理购物车」「查看订单」全都用 include 指向它整张图被认证相关的线占满核心业务反而看不清。原因把登录当成业务目标且错误地认为每个操作都要显式包含登录。实际上登录是系统的通用认证机制不是某个用例的子流程。解决两个方案二选一。方案一把「已登录」写进所有涉及个人数据的用例的前置条件图上完全不画登录相关连线。方案二如果团队坚持要表现认证过程只保留一个「登录」用例画一条从「买家」到它的关联线并加一行注释「访问需认证用例时自动触发登录」而不是把它连到每个业务用例上。第二种方案会牺牲部分规范性但至少图面干净。5.4 参与者里混进了系统内部角色现象图上出现了「数据库」「定时任务」「管理员」同时出现的场景里「数据库」被画成一个小人放在边界外还连了三条实线。原因把系统内部的组件或角色误当成外部参与者。参与者必须是系统外部的角色或系统数据库、缓存、消息队列都是系统内部的组成部分不应该以参与者的身份出现在用例图里。解决删除内部组件参与者只保留外部角色和外部系统。网上购物系统里买家、游客、管理员是外部角色支付系统是外部系统这三类可以保留。如果你确实需要表达数据库交互那属于时序图或组件图的工作不要塞进用例图。顺带提醒一句「管理员」要确认是使用后台系统的人而不是后台系统本身有人会把管理员画成一个系统块这也是同样的错误。5.5 系统边界把不属于本次迭代的功能全圈进来现象一张网上购物系统用例图里同时出现了「商品推荐」「社区种草」「直播带货」三个业务域而本次迭代只做基础交易链路图上多出来的用例让开发摸不清优先级。原因系统边界画得过大把远期规划、周边系统或非本次范围的功能全部纳入用例图从需求确认工具变成了项目愿景墙。解决明确本次迭代范围后再画边界。把「本次要交付」的用例放进矩形内把「未来要做的」用文字标注在图外或者干脆不画。如果有外部系统参与交互画到边界外即可。评审时如果有人在图上追加用例先问他一句这个用例是本次开发还是外部依赖这个动作能避免用例图变成垃圾桶。6. 用例图的验收技巧三个「能不能」让用例图不再返工用例图画完不等于工作结束我习惯在提交评审前用三个「能不能」自检一遍。第一能不能不看任何文字说明仅凭图面用一句话读出核心业务一张合格的网上购物系统用例图应该能直接说出「游客浏览和搜索商品买家下单支付并管理订单管理员维护商品和用户支付系统完成在线支付」。如果读不出这句话说明图的层次或关系线有问题。第二能不能让测试同事从图里直接导出冒烟测试场景每一个用例都应该对应至少一条可执行的测试用例画好的图应当能支撑「买家从下单到支付」这样一条端到端路径。第三能不能让开发从图上分清权限边界谁连了哪些用例就等于谁需要哪些接口和权限管理员用例和买家用例分不清开发就没法动手。在三个「能不能」之外还有一个我踩过坑的细节提交用例图时顺手附一版配套的用例清单和规格说明表。图和文字一起评审速度比只看图快一倍。因为图回答「有什么」规格说明表回答「怎么走」缺了哪个评审都会变成猜谜现场。画完这张图后最后悔的一件事是某次给图里的支付流程加了一堆 include 关系把支付系统内部步骤全画了进来结果评审时被问住只好当场重画。后来我给自己定了一条规矩用例图的每一条线必须能当场解释它存在的意义解释不了的线当场删掉。这条规矩帮我避免了很多次无效返工希望也能帮到你。本文还有配套的精品资源点击获取