企业官网建设流程全解析

简介：网上商城UML图.docx 是一份面向软件工程学习者与系统设计初学者的UML建模参考文档，围绕网上商城系统的需求分析、静态结构模型和动态行为建模展开。文档从系统需求与模块划分入手，梳理了顾客、系统管理员等参与者及用例，再通过类图描述Customer、Goods、Order、管理员等核心类，结合时序图、活动图、协作图覆盖注册、浏览、购买、商品管理、会员管理等典型业务流程。资源为单个docx文档，约297KB，内容包含目录结构清晰的知识点整理与图形说明，便于读者对照学习UML各图型的绘制与应用场景。已有181人学习使用，适合需要完成课程设计、毕业设计或复习UML建模知识的人群参考，可帮助快速建立从需求到建模的完整思路。

1. 一份网上商城UML图.docx，到底应该装多少张图

接手过商城项目的人都有这种经历：需求文档改了三版，开发说“按图开发”，结果项目经理拿着一张类图对着数据库表愣了半天——类图画得和表结构一模一样，连冗余字段都画进去了。反过来，有人把UML图画得极其华丽，每张用例图塞三十个用例，评审会上没人敢说看不懂，但开发根本不知道从哪张图开始写代码。

“网上商城UML图.docx”这个标题看起来像一份普通交付物，实际上它是在问：一个典型B2C网上商城，到底需要哪些UML图、每张图画到什么颗粒度、怎么排版成一份能被评审、能指导编码、能应付答辩或软考UML图试题的docx文档。这篇文章把完整套路讲透。适合正在做课设或毕设的学生、刚接手商城系统的后端开发，以及需要给客户交付设计文档的需求分析师。

2. 网上商城UML图的骨架：先钉死用例、再画类图

2.1 用例图先行：把角色和功能边界钉死

网上商城最容易翻车的地方不是技术选型，而是“谁在用这个系统”没搞清楚。我一般画用例图之前，会先列一份角色清单：游客、注册用户、店铺运营、系统管理员。注意支付网关、短信服务商这类外部系统不要画成actor，它们不是“人”，是外部系统，要用actor框起来但明确标注。

用例的抽取有一个土办法：把需求文档里所有“用户能XX”“系统支持XX”的句子抄出来，动词短语就是候选用例。商城项目常见的用例包括注册登录、浏览商品、搜索商品、加入购物车、下单、支付、查看订单、取消订单、退货退款、商品上下架、库存管理、用户管理。粗看很多，但画出用例图之后你会发现，真正核心的用例只有“下单”和“支付”两个，其余都是围绕它们的辅助用例。

下面这类语法就是常见的做法，我通常用PlantUML快速生成第一版用例图，再贴到docx里手动调整。

@startuml left to right direction actor "游客" as guest actor "注册用户" as user actor "店铺运营" as operator actor "系统管理员" as admin rectangle "网上商城" { guest --> (浏览商品) guest --> (搜索商品) user --> (注册登录) user --> (加入购物车) user --> (下单) user --> (支付) user --> (查看订单) user --> (取消订单) operator --> (商品上下架) operator --> (库存管理) admin --> (用户管理) admin --> (订单管理) } @enduml

代码逻辑说明：left to right direction 让用例图横向排布，actor定义四个角色。rectangle包起来的区域是系统边界，箭头表示角色发起的用例。这个语法的好处是文本化，改一个角色名不用重画。参数说明：箭头方向一定是“角色指向用例”，反过来画就表示系统主动找角色，语义就错了。另外每个用例建议用“动宾结构”命名，比如“加入购物车”而不是“购物车”。

用例图画完之后，docx里这张图旁边至少要配一段话：说明系统边界内外分别是什么、每个角色覆盖哪些用例、扩展关系(extend)和包含关系(include)画了没有。很多人在软考UML图试题里丢分，就是因为include和extend的方向画反了：include是被包含用例在前，箭头指向基础用例；extend是扩展用例指向被扩展用例，箭头方向完全相反。

2.2 类图定核心实体：订单与商品模型的粒度是命门

类图是整个docx里最容易被挑刺的一张图。网上商城的类图核心实体就六个：User、Product、Category、Order、OrderItem、ShoppingCart，加上Payment和Coupon。新手容易犯两类错误：一类是把类图画成数据库表结构的翻版，属性里带id、create_time这种字段；另一类是关系画太密，八个类互相连了二十条线，评审根本没法看。

我的做法是分两层画。第一层是静态结构图，只画实体类，属性写业务属性，不写数据库字段；方法写关键行为，不写CRUD。第二层是局部细化图，针对订单模块单独画一张，把Order、OrderItem、Payment、Coupon的关系展开。这样docx里一张大图加一张局部图，比一张图表全部更实用。

@startuml class User { - userId: String - nickname: String - phone: String - level: int + addAddress(addr: Address): boolean } class Product { - productId: String - title: String - price: BigDecimal - stock: int + reduceStock(num: int): boolean } class Category { - categoryId: String - name: String - parentId: String } class Order { - orderId: String - userId: String - totalAmount: BigDecimal - status: OrderStatus + pay(timeout: int): boolean + cancel(): boolean } class OrderItem { - itemId: String - productId: String - quantity: int - price: BigDecimal } Order "1" -- "1..*" OrderItem Order "*" -- "1" User Product "*" -- "1" Category @enduml

代码逻辑说明：这里用类图语法定义六个类。类里的访问修饰符用-表示private、+表示public，字段用“属性名: 类型”的格式，方法用“方法名(参数): 返回值”。底部四行表示关系：Order与OrderItem是一对多关联，Order与User是多对一，Product与Category是多对一。关系线上可以标数量重数，这是类图评分的关键点。

参数说明：属性类型尽量用业务类型而不是数据库类型。price用BigDecimal而不是double，因为金额用浮点数会翻车，这是电商项目的底线经验。stock库存字段单独画出来，因为超卖问题在类图上的体现就是stock没有防并发控制。

类图在docx里配文要写清楚三件事：类之间的关联是单向还是双向、重数是多少、有没有聚合或组合关系。ShoppingCart和OrderItem其实是一对多的聚合，User和Order是关联。把聚合和关联写明白，数据库设计阶段就能少走弯路。

2.3 动态图补流程：时序图和状态图的取舍

类图回答“有什么”，动态图回答“怎么动”。网上商城必须有的动态图是：下单时序图、支付回调时序图、订单状态图。很多人的图文档里只有用例图和类图，没有时序图，被答辩老师问“订单从创建到完成经过哪些状态”直接卡住。

时序图建议画两张。一张是正常的下单流程：用户提交订单、系统创建订单、锁定库存、调用支付、支付回调、更新订单状态。另一张是异常流程：库存不足、支付超时、用户取消。状态图单独画订单状态机：待支付→已支付→已发货→已完成，待支付→已取消，已发货→退款中→已退款。这五个状态的转移条件要写清楚，转移条件就是代码里状态机的判断逻辑。

@startuml [*] --> 待支付 : 创建订单 待支付 --> 已支付 : 支付成功回调 待支付 --> 已取消 : 用户取消 / 超时未付 已支付 --> 已发货 : 卖家发货 已发货 --> 已完成 : 用户确认收货 已发货 --> 退款中 : 用户申请退款 退款中 --> 已退款 : 卖家同意 退款中 --> 已发货 : 卖家拒绝 @enduml

代码逻辑说明：[ * ]是初始状态，箭头上的文字是触发事件。状态图的价值在于它把“什么时候不能流转”也画出来了。比如已支付不能直接到已取消，这就在状态图上形成一道约束，开发写代码时不会漏掉。参数说明：状态图里的状态命名建议用枚举名而不是中文描述，这样代码里的OrderStatus枚举可以直接对应上。

时序图在docx里比状态图占版面，我的经验是一张时序图控制在六个生命线以内，超过就拆。下单时序图的生命线是：用户界面、订单服务、库存服务、支付服务、数据库。每张时序图下面配一段“正常路径/异常路径”的文字，异常路径一定要写，这是评审时最容易提问的地方。

3. 把UML图组织成docx交付文档：工具选择与版面规范

3.1 画图工具选型：PlantUML、draw.io还是StarUML

做网上商城UML图.docx，工具选型决定了后半程的效率。我维护的商城项目文档用过Visio、StarUML、draw.io、PlantUML四种，各有利弊。Visio上手最平滑、手动拖拽灵活，但是图和文字是分离的，改一张图要重排整个docx。StarUML正向工程强，能反向生成代码骨架，但它导出到Word的图片清晰度一般，而且对中文支持偶尔出现乱码。draw.io免费、模板多、多人协作方便，缺点是版本对比靠手动。PlantUML文本化、可版本管理、批量导出方便，但学习曲线比拖拽工具陡。

我的经验是：如果是给客户做正式交付，用Visio或draw.io出图、导出成SVG嵌入docx；如果这套UML图要长期跟着代码走，用PlantUML源码维护，出图交给脚本。网上商城的类图和时序图变动频率不低，一个订单状态变化就可能牵连三张图，PlantUML的文本化优势在这里非常明显。很多人一开始嫌学语法麻烦，等到改第五版文档时就会感谢文本化。

3.2 图编号、图题与配文：让docx具备评审价值

一份只有图没有文字的UML图docx，评审会上就是灾难。我见过的翻车现场：图编号直接从1跳到7，图题写“类图”两个字的都有，更别提每张图没有说明文字，评委翻两页就失去耐心。

我一般给每张图配一个固定结构的说明段落：这张图回答什么问题、核心元素是什么、图里哪个关系最容易被误解、对应的验证方法是什么。比如类图配文写“本图展示核心实体关系。Order与OrderItem为一对多组合关系，OrderItem不能脱离Order存在。验证方法：检查数据库表order_item是否包含order_id外键且非空。”这样配文，docx从“图集”升级成“设计说明”。

图编号在docx里要用“章号-图序号”的格式，比如图2-1表示第2章第1张图。用Word的题注功能自动编号，不要手动输入数字——手动编号意味着改一次图就要全文找一遍引用，有人写脚本抽段落里的“图x-x”和题注做比对，避免漏改。编号、图题、配文三件套齐全，这份docx才谈得上评审价值。

3.3 导出与排版：SVG优先，图片清晰度是隐藏门槛

从工具导出图片嵌入docx，分辨率是个容易被忽略的坑。draw.io默认导出PNG是96dpi，放到Word里缩放到一页宽，文字直接发虚。PlantUML导出PNG默认也是模糊的，需要指定DPI参数。正确做法是导出SVG嵌入Word，Word 2016以上版本支持原生SVG，放大不糊。如果必须用PNG，导出时把DPI设到150以上，单张图宽度控制在15cm以内，不要一张图横跨整页。

docx排版上还有一个细节：UML图的边框。默认的白底黑线图嵌在Word里边界不明显，我给每张图加一个浅灰色单线边框，和正文区隔开。图与图之间的间距统一设为段前6磅段后6磅。另外，建议在docx页脚放文档版本号和生成日期，因为UML图文档必然被反复修改，没有版本号，一周后你自己都不知道哪张图是最新的。

4. 网上商城UML图常见的坑：从图到代码的翻车集中营

4.1 类图画成数据库表：反向工程思维害死人

现象：网上商城类图里的User类，属性是user_id、user_name、create_time，全部和数据库字段一一对应，方法全是getter/setter。评审人问“User和Order是什么关系”，画图的人回答“看外键就行”。

原因：画图的人先设计了数据库表，再把表结构套进UML图画给客户看。类图和表结构确实相关，但UML类图表达的是业务概念，数据库表表达的是存储方案，两者存在一对多或多对多的映射关系，强行对齐会让后续需求变更成本翻倍。

解决：把类图属性改回业务属性：userId、nickname、phone、level，把getter/setter删掉，只保留行为方法比如addAddress、reduceStock。做这一步的意义是逼自己思考“用户”这个概念在商城业务里有什么行为，而不是在数据库里有什么字段。

4.2 时序图里画满了if/else分支：动态图变流程图

现象：下单时序图里画了八个alt片段，分别是库存不足、余额不足、风控拦截、超时重试、重复下单，整张图的生命线之间全是分支框，评审看不出主流程长什么样。

原因：时序图的职责是展示对象之间的消息交互顺序。画图的人把接口实现逻辑搬到图里，把时序图画成了程序流程图。网上商城的下单主流程其实很短：createOrder→lockStock→callPayment→waitCallback→updateStatus，异常逻辑用文字描述即可。

解决：同一张时序图只保留一条主链路加一个最关键的分支。其他异常场景拆成独立小图或直接在配文里讲。时序图不是越详细越好，详细到能编码的是伪代码，不是UML图。

4.3 用例图的角色用了外部系统：把系统当用户

现象：用例图里画了一个actor叫“支付平台”，箭头指向“支付”用例；又画了一个actor叫“短信服务商”，指向“发送验证码”。

原因：把“调用外部接口”误解为“外部系统主动使用系统”。支付平台确实参与了支付流程，但它是被系统调用的服务提供者，不是发起操作的用户角色。用例图里的actor是“与系统交互的外部参与者”，这个参与者可以是人也可以是外部系统，但方向必须是“主动发起”。

解决：支付和短信验证码这类场景，把外部系统作为系统边界外的actor、用包含关系include挂到主用例下，表示“用户发起支付时包含一次支付网关调用”。这样意图清晰，也不会在评审时被追问“支付平台为什么要注册登录”。

4.4 组件图和部署图混用：物理和逻辑傻傻分不清

现象：docx的组件图里画了服务器、数据库、Redis、Nginx图标，标注为“系统架构组件图”。

原因：组件图是逻辑层面的软件模块划分，比如“订单服务”“库存服务”“支付服务”这些组件及其接口依赖。部署图才是物理层面描述软件部署在哪些节点上。把服务器画进组件图，等于把物理部署塞进逻辑视图，评审时架构师很难接受。

解决：网上商城的组件图按模块画：前端应用、订单服务、商品服务、支付服务、消息队列、数据库，组件之间存在依赖关系即“订单服务依赖库存服务”。部署图另外画一张：Nginx→应用服务器→数据库服务器，标注端口和协议。两张图各司其职，docx的结构层次也清楚。

4.5 docx里的图片模糊不清：导出设置没到位

现象：docx里UML图缩放后文字虚成一片，答辩投影时完全看不清，只能现场打开画图工具放大看。

原因：导出图片分辨率不够。draw.io和PlantUML默认导出是96dpi，插入Word后缩放，相当于把本来就不清晰的位图放大，文字边缘自然糊。

解决：导出SVG格式嵌入Word。SVG是矢量格式，缩放无损。工具不支持SVG的，导出PNG时指定150dpi以上，并把画布尺寸设成接近目标显示宽度。我在交付docx里统一用SVG，客户在Word里放多大都清晰，这个标准基本成了我的默认配置。

5. 从docx里的UML图到可运行的代码：三类落地路径

5.1 类图驱动数据库表设计：一对一、多对多怎么落

类图画完了，下一步是转数据库表。这个环节是“网上商城UML图.docx”这个文件价值的兑现点。网上商城的核心类图转表有固定套路：一个业务类一张表，类名转表名用下划线分隔，属性转字段，关系决定外键怎么加。

关键在于关系的基数。一对多关系，在“多”的那端加外键：Order与OrderItem是一对多，order_item表加order_id外键。多对多关系建中间表：Product与Coupon是多对多，新建product_coupon中间表存product_id和coupon_id。一对一关系直接合并或共享主键，商城系统里User与UserAccount就是一对一，把账号字段并进user表，比单独建表更简单。

-- 根据类图生成的核心表结构（简化版） CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, nickname VARCHAR(50) NOT NULL, phone VARCHAR(20), level INT DEFAULT 0 ); CREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL, price DECIMAL(10, 2) NOT NULL, stock INT NOT NULL ); CREATE TABLE `order` ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, total_amount DECIMAL(10, 2) NOT NULL, status TINYINT NOT NULL, FOREIGN KEY (user_id) REFERENCES user(id) ); CREATE TABLE order_item ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, quantity INT NOT NULL, price DECIMAL(10, 2) NOT NULL, FOREIGN KEY (order_id) REFERENCES `order`(id), FOREIGN KEY (product_id) REFERENCES product(id) );

代码逻辑说明：这段DDL与类图一一对应。注意price用DECIMAL(10,2)而不用double，对应类图里BigDecimal的约定。order表名加了反引号，因为order是SQL保留字。FOREIGN KEY部分体现类图里的关联重数。参数说明：status用TINYINT存枚举值，不要直接存字符串；外键加索引，否则订单查询会随着数据量膨胀而变慢。表结构设计好以后，回去对照类图重数检查一遍，类图画错的地方表结构一定会暴露。

5.2 状态图驱动订单状态机：状态流转别写散

订单状态图是docx里直接指导编码价值最高的一张图。状态图里画了：待支付→已支付→已发货→已完成，待支付→已取消，已发货→退款中→已退款。这个流转直接对应代码里的状态机。最常见的错误是把状态判断写成散落的if/else，每个接口里都判断一次“当前状态能不能做这个操作”，状态一多就漏判断。

正确的做法是建一个状态转换表，用一个Map或枚举来管理合法的流转路径。

public enum OrderStatus { PENDING_PAYMENT, PAID, SHIPPED, COMPLETED, CANCELLED, REFUNDING, REFUNDED; private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = new EnumMap<>(OrderStatus.class); static { TRANSITIONS.put(PENDING_PAYMENT, EnumSet.of(PAID, CANCELLED)); TRANSITIONS.put(PAID, EnumSet.of(SHIPPED, REFUNDING)); TRANSITIONS.put(SHIPPED, EnumSet.of(COMPLETED, REFUNDING)); TRANSITIONS.put(REFUNDING, EnumSet.of(REFUNDED, SHIPPED)); } public boolean canTransitionTo(OrderStatus target) { Set<OrderStatus> allowed = TRANSITIONS.get(this); return allowed != null && allowed.contains(target); } }

代码逻辑说明：TRANSITIONS这个Map就是状态图的代码化。key是当前状态，value是允许到达的目标状态集合。canTransitionTo方法在订单更新的入口统一调用。参数说明：REFUNDING允许回到SHIPPED是业务上的“拒绝退款”分支，如果状态图里没画这个箭头，代码里就不该出现这个流转。两个文件实现了同一个模型，状态图更新了代码就要跟着同步，这就是我们维护PlantUML源码的核心理由。

5.3 时序图转接口时序：异常分支要落成接口约束

时序图在docx里展示的是消息顺序，落地时直接映射到接口调用顺序。网上商城下单时序图的生命线是：用户界面、订单服务、库存服务、支付服务、数据库。对应的接口调用是：订单服务先调用库存服务锁定库存，再调用支付服务创建支付单，支付回调后订单服务更新状态。

这里有个实际落地的细节：时序图中画了“库存锁定失败则取消订单”，那订单服务调用库存服务时就要明确两个接口：锁库存接口和回滚库存接口。光有锁没有回滚，超时或支付失败时库存会慢慢被耗光。

POST /api/order/create POST /api/order/{orderId}/pay POST /api/order/{orderId}/cancel POST /api/inventory/{productId}/lock POST /api/inventory/{productId}/unlock

参数说明：接口列表与时序图生命线的消息名称一一对应。测试验证时，按“创建订单→锁库存→支付→支付回调→完成”的路径走一遍主流程，再按“锁库存失败”和“支付超时取消”走两遍异常路径。网上商城的核心链路就这三条，docx里的时序图如果画得比这个复杂，要么是图画过头了要么是系统逻辑有冗余。我用这个清单反查时序图，能发现不少“图上没画但代码里有”的死角。

6. 用PlantUML源文件维护docx里的整套图：一次改图处处同步

进阶做法是让docx里的UML图不再是静态图片，而是一套文本源文件渲染出的产物。我维护的商城项目，.puml文件放在docs/uml目录下，和代码仓库同源管理。改一张类图，改的是.puml文本，跑一条命令重新生成图片和docx。这套流程帮助最大的场景是答辩前夜——需求变了一版，手工重画三张图要两小时，改文本十分钟解决。

@startuml !pragma teoz true @enduml

这段不算业务代码，只是PlantUML的一个开关：teoz是PlantUML的时序图引擎，开启后消息顺序更严谨，画时序图建议常开。我的习惯是每张图源码开头都写一行注释说明这张图对应软件需求文档的哪个章节，这样docx里的图与需求可追溯。配合脚本批量导出SVG，再粘贴进Word，图编号和图题还是手工维护的话，一套脚本下来一分钟就能完成一次全量更新。

还有一个小技巧：docx里的图配文与图本身分离维护，配文写在.puml注释里，这样图和文字绑定在一起不会丢。虽然有人用Java写工具读取docx段落做图号校验，但更省力的做法是从源头把编号规则固定好。这份UML图文档的价值在于它能把“商城有哪些角色、订单怎么流转、类与表怎么映射”一次性讲清楚，省掉开发与需求之间的反复沟通。我自己吃过不少亏，最深的教训是：图画得全不如图画得齐，每张图能回答一个问题、配文能说明一个决策，这份docx才真正有人看。希望帮到你。

本文还有配套的精品资源，点击获取