商城系统用例图怎么画？系统设计实战指南

很多人做商城项目时，只停留在原型和PRD，忽略了用例图这层抽象，导致角色职责混乱、接口边界不清。基于一个标准商城业务，用例图可以帮助你在开工前一次性理顺角色、流程与功能范围，无论是做需求分析、系统建模，还是应对考试答题，都有一套通用思路可复用。

一、画商城用例图前，要先想清哪些问题？

在打开画图工具前，先用一张纸列出这个商城系统要服务哪些业务目标，比如：在线销售商品、促销活动、订单履约、售后服务等。结合已有的原型或需求文档，把“这个系统做什么、不做什么”列清楚，给自己画出一个清晰的业务边界，避免用例图把支付网关、第三方仓储等外部系统都画成内部功能。

明确边界后，写下几条关键业务路径，例如“用户下单到收货”“商家上架到发货”“运营配置活动到生效”等。每条路径对应一组用例，后面识别角色和用例时就以这些业务路径为主线，画图会更聚焦，也更符合研发团队阅读习惯。

二、商城系统里有哪些典型角色？

商城系统常见的用户群体可以归类为几种“参与者”，它们在用例图中以小人图标表示。常见有：普通买家、平台管理员、商家/店主、客服人员、仓储/物流系统、支付平台等。不同项目可能名称不同，但可以按“是否直接使用前台界面、是否为外部系统”来判断是不是一个独立参与者。

确定参与者时，建议采用问答式自检：“是谁发起这个操作？”“谁从这个功能中获得主要价值？”。满足其中之一，就应该单独建一个参与者。对于“短信服务、第三方支付、快递接口”等，更适合作为外部系统参与者放在用例图边缘，提醒研发在实现时需要系统间集成，而不是在商城内部重复实现这些能力。

三、商城系统的核心用例场景怎么拆？

围绕“普通买家”这类核心角色，可以拆出几类基础用例：注册登录、浏览商品、搜索与筛选、加入购物车、下单与支付、查看订单、申请售后等。每个用例都要能用一句话描述清楚“用户的目标”，例如“浏览商品”是为了“了解商品信息并做出购买决策”，避免写成“点击xx按钮”这类过于界面化的描述。

对“商家/店主”，主要用例包括：发布和管理商品、设置价格和库存、处理订单、发货与填写物流信息、查看店铺数据报表。对“平台管理员”，通常会有：审核商家和商品、配置类目和品牌、运营活动配置、用户与权限管理等。通过这种按角色分组的方式，可以很快看出哪些功能是平台统一管理，哪些是商家自主管理。

在用例图中，可以用“include/extend”表达复用与可选流程。比如“下单与支付”可以包含“使用优惠券”“选择配送方式”等；“申请售后”可以扩展为“退款”“退货”“换货”。include适合抽出公共子流程，如“地址管理”；extend适合表达条件发生时才执行的可选步骤，如“售后仲裁”。

四、一步步完成商城用例图的绘制步骤

落到实操，建议按以下顺序绘制：先在画布中间画一个系统边界框，命名为“商城系统”；接着把前面识别出的用例以椭圆形式放在边界框内部，每个用例命名保持动宾结构，避免使用模糊名词，如写“管理订单”而不是“订单模块”。让同一类业务的用例尽量放在同一区域，例如买家相关在左侧，商家相关在右侧。

随后把参与者放在系统边界外侧，用直线连接参与者与其对应的用例，形成“谁使用哪些能力”的清晰关系图。涉及外部系统（支付平台、物流系统）时，将其单独画成参与者，与“支付订单”“同步物流轨迹”等用例连接。最后补充include/extend关系、标注关键备注，例如“支付失败时触发订单关闭”。检查一遍，确认每个关键业务路径从参与者到用例都能串成一条顺畅链路，整张图就具备交付价值了。

常见问题

商城系统用例图需要画到多细才合适？

用例图更适合停留在“用户目标”层级，不需要把每个按钮都拆成用例。一般来说，能支持需求评审时讨论业务流程就足够。如果某个用例内部流程较复杂，例如“售后处理”，可以在用例图中保持一个用例椭圆，把细节拆到用例说明文档或活动图中，避免整张图变成“功能清单”而失去结构感。

用例图和流程图、原型图是什么关系？

三者关注点不同：用例图关注“谁要达成什么目标”，流程图关注“步骤顺序”，原型关注“界面呈现”。通常做法是：先用用例图确定参与者和用例边界，再用流程图或时序图细化某个关键用例的业务步骤，最后配合原型描述交互。在需求分析阶段，用例图是串联其他文档的骨架，可以帮助团队统一术语和范围。

做考试题时，商城用例图怎么写更标准？

考试题目常给出一段文字描述商城需求，作答时先圈出关键词：用户类型、主要功能、外部系统。答题纸上先写角色列表，再画系统边界和核心用例，保证每个需求点都在图中有对应用例或参与者。命名要规范，例如“浏览商品、提交订单、在线支付”，避免写过于抽象的“信息维护、业务处理”，这样更符合评分标准。

已有商城在重构，旧功能要不要都画进用例图？

重构场景下，用例图可以当“功能断舍离”的工具来用。先按现状把主要用例画出来，标记出“必须保留、待评估、准备下线”三类。对低使用率但实现复杂的用例，可以在图中标注为候选删除项，与业务方讨论是否合并或替换。通过这张图，团队能一眼看出哪些功能会影响到哪些角色和外部系统，为后续拆分模块或服务提供依据。