简介资源为《UML网上订餐系统分析与设计》实验报告聚焦UML在软件系统建模中的完整应用适合软件工程、系统分析与设计课程的师生及需要完成UML大作业的学习者。内容覆盖需求模型、分析模型与用例实现三大层次从游客/注册用户/管理员的权限管理到架构模型、分析机制和关键抽象再到注册、登录注销、餐品信息检索等核心用例的事件流、前置/后置条件及顺序图并给出了order、dish、user等类的属性和方法设计能帮助读者快速掌握用例图、类图、顺序图等UML图的绘制思路与文档组织方式。压缩包共1个doc文档约149KB虽体积不大但内容完整便于直接参考修改。该资源已有4225人学习适合作为课程设计或实验报告的模板和案例。1. 为什么一个“UML网上订餐系统.doc”能让课程设计和软考同时受益拿到“UML网上订餐系统.doc”这个标题多数人第一反应是“又是一个课程设计模板”。但真正做过UML项目的人会明白网上订餐系统是UML建模里最典型的“状态驱动型”业务——订单从创建到完成要经历待支付、待接单、配送中、已完成、已取消等多个状态每个状态都有不同的操作权限和校验规则非常适合把用例图、类图、时序图、状态图全部串起来讲清楚。一份好的UML建模文档不仅是画几张图交差而是要让读者照着图就能把系统的数据库表结构、接口设计和前端页面划分出来。这篇笔记适合三类人正在做UML课程设计的学生、准备软考“UML图试题”的考生、以及想用UML把业务需求落成技术方案的从业者。我会按照“需求分析 → 静态建模 → 动态建模 → 踩坑记录 → 答辩与验证”这条路径把一份完整网上订餐系统UML文档的建模过程和落地经验讲透每一步都给出可以直接抄走的图表结构和参数设计。2. 用例图与需求建模先把三个角色和十条用例理清2.1 为什么网上订餐系统适合从用例图切入用例图是UML建模的起点它回答的是“谁来用系统、用来干什么”。网上订餐系统的角色边界非常清晰顾客、商家、骑手三者之间的交互天然形成用例关系不需要像ERP那样梳理复杂的权限层级。我在做这类系统时第一步永远是列角色清单而不是急着画图。角色清单决定了后续所有图的范围角色漏了后面全部返工。网上订餐系统的核心角色有三个顾客是系统的服务对象负责浏览菜品、下单、支付、催单、评价商家负责菜品管理、接单、出餐骑手负责抢单、取餐、送达。这里容易被忽略的是系统管理员角色——很多课程设计把管理员和商家混在一起但管理员管的是用户状态、订单异常处理和平台数据统计权限范围和商家完全不同应该独立建模。用例清单建议控制在十条以内。我常用的划分是顾客侧有“注册登录”“浏览菜品”“下单支付”“取消订单”“催单”“评价”商家侧有“菜品管理”“接单出餐”骑手侧有“抢单配送”管理员侧有“用户与订单管理”。这十条用例对应后续的类图、时序图和数据库表多一条都会让文档结构变臃肿。2.2 用例规约的写法比用例图更值钱的文档用例图画出来只是第一步真正在答辩和软考里拿分的是用例规约。用例规约是把每个用例的文字描述写成结构化表格包含前置条件、后置条件、基本流、备选流。以“下单支付”为例基本流是顾客选择菜品→加入购物车→确认订单→选择支付方式→支付成功→生成订单备选流要写支付超时怎么办、余额不足怎么办、支付成功后商家缺货怎么办。用例名称下单支付 参与者顾客 前置条件顾客已登录购物车有商品 后置条件系统生成待支付订单库存扣减商家收到新订单通知 基本流 1. 顾客点击“去结算”系统展示订单明细与金额 2. 顾客选择支付方式微信/支付宝/余额 3. 系统调用支付接口顾客完成支付 4. 系统生成订单状态置为“待支付-已支付”通知商家 备选流 2a. 订单金额为0使用优惠券全额抵扣跳过支付直接生成订单 3a. 支付超时订单状态保持“待支付”提示顾客重新支付 3b. 支付接口返回失败订单取消释放库存 后置条件补充支付成功后30分钟内商家未接单顾客可申请取消这个规约的价值在于后续画时序图时泳道就能直接从基本流里提取建数据库表时“是否支付”“支付时间”“订单状态”字段也是从备选流里反推出来的。我见过太多人只画了用例图不写规约到答辩时被问“支付失败怎么处理”直接卡住——备选流就是用来接住这类问题的。2.3 活动图用泳道把“从下单到出餐”的流程画明白用例图是静态的活动图负责把用例背后的流程动起来。网上订餐系统里最值得画活动图的是“订单履约流程”从顾客提交订单开始到商家接单、出餐、骑手取餐配送、顾客确认收货结束。画活动图的关键是泳道划分——每一道代表一个参与者或系统组件活动节点放在对应的泳道里这样一眼就能看出某个操作是谁做的。我一般在活动图里分四道顾客、系统、商家、骑手。核心流转是顾客提交订单→系统校验库存并锁定→商家收到通知→商家接单或拒单→商家出餐→系统通知骑手→骑手抢单→骑手到店取餐→配送→顾客确认收货。这里有两个容易被忽略的判断节点一是商家拒单后订单要回到“待接单”状态还是直接取消我一般设计为“可改派其他商家”或“自动取消并退款”二是骑手超过10分钟未抢单时系统要自动扩大配送范围重新派单。活动图画完后建议把每个判断节点的条件单独列成一张表——比如“库存不足”“商家超时未接单”“骑手配送超时”——这些条件就是后续状态图的触发事件也是编程实现时if-else分支的来源。活动图不是用来好看的它直接决定了订单状态机的边界。3. 类图与静态建模从概念模型到数据库表的“翻译”方法3.1 网上订餐系统的核心类识别实体类、控制类、边界类类图是UML文档里信息密度最高的图也是软考UML试题的高频考点。很多人画类图习惯性把所有东西都画成实体类结果类图变成一张巨大的数据表清单。我习惯先把类分成三类边界类界面相关、控制类业务逻辑、实体类数据存储。网上订餐系统的边界类有“顾客端界面”“商家端界面”“骑手端界面”控制类有“订单控制器”“支付控制器”“配送调度器”实体类有“用户”“菜品”“订单”“订单明细”“购物车”“评价”“优惠券”。控制类不是随便加的每个控制类对应一个业务用例——比如“订单控制器”对应下单支付用例“配送调度器”对应抢单配送用例。实体类之间关系则是类图的精髓。以“用户-订单-订单明细”为例用户和订单是一对多订单和订单明细是一对多订单明细和菜品是多对一。这里有个常见错误——把订单明细直接画成订单的属性。一旦订单里有多道菜就必须拆出订单明细类否则数据库无法存储多菜品订单。我一般画完类图后会做一次检查每个类至少有一个属性和一个操作每个关联关系都能说清“为什么是一对多而不是多对多”。3.2 类图属性与方法设计订单类的完整字段清单类图的深度体现在属性和方法上。以“订单”类为例属性不能只写“订单编号”“下单时间”要落到能建表、能写代码的程度。我常用的订单类设计如下订单类Order 属性 order_id: int主键自增 user_id: int外键关联用户表 shop_id: int外键关联商家表 order_no: string(32)业务订单号规则日期随机数 total_amount: decimal(10,2)订单总额含菜品金额和配送费 delivery_fee: decimal(10,2)配送费按距离计算 status: int订单状态0待支付 1待接单 2配送中 3已完成 4已取消 pay_method: int支付方式1微信 2支付宝 3余额 create_time: datetime下单时间 pay_time: datetime支付时间可空 finish_time: datetime完成时间可空 remark: string(255)顾客备注 方法 submit_order(user_id, shop_id, items[]): order_id // 提交订单 cancel_order(order_id, cancel_reason) // 取消订单 pay_order(order_id, pay_method) // 支付订单 confirm_receipt(order_id) // 确认收货 get_order_detail(order_id): OrderDetail // 查询订单详情属性后面写注释是类图文档的加分项软考阅卷时老师能看到你理解字段的业务含义。注意订单编号不能直接用自增id要设计独立的业务订单号因为订单号要展示给顾客和骑手看自增id会暴露平台订单量这是基于系统安全性的实战考量。3.3 从类图到数据库表的映射一对一、一对多、多对多的落地规则类图画完后的落地动作是转数据库表。我在课程设计文档里会附一张“类图转表映射表”这是答辩时最能体现工程能力的部分。映射规则有三条每个实体类对应一张表控制类不建表边界类不建表一对多关系在“多”方加外键多对多关系创建中间表。网上订餐系统里有多对多关系吗有——“购物车”和“菜品”—一个购物车可以放多个菜品一个菜品可以被多个购物车加入所以需要“购物车明细表”来解耦。“订单”和“菜品”也有类似关系但我们已经拆出了“订单明细”实体类所以降级成了订单明细表对菜品表多对一。用户表(user)user_id, username, password, phone, address, role(顾客/商家/骑手/管理员), create_time 商家表(shop)shop_id, user_id, shop_name, address, business_hours, delivery_range(配送范围半径单位km) 菜品表(dish)dish_id, shop_id, dish_name, price, description, image_url, stock, status(上架/下架) 订单表(orders)order_id, user_id, shop_id, rider_id, order_no, total_amount, delivery_fee, status, pay_method, create_time, pay_time, finish_time, remark 订单明细表(order_detail)detail_id, order_id, dish_id, dish_name, price, quantity, subtotal 购物车表(cart)cart_id, user_id, shop_id, create_time 购物车明细表(cart_detail)cart_detail_id, cart_id, dish_id, quantity 评价表(review)review_id, order_id, user_id, shop_id, rating, content, create_time 优惠券表(coupon)coupon_id, user_id, amount, min_threshold, expire_time, status映射表最关键的是标注“由哪个类导出”和“外键字段”。比如订单表的rider_id就来自“骑手配送”这个用例没有画出骑手参与配送的用例图建表时就会漏掉这个字段。我会在映射表里写清楚每个字段对应类图的哪个属性这个属性是哪个用例定义的。这样做的好处是答辩时老师问“为什么订单表有rider_id而订单类没有”你可以回答“骑手是配送用例中的参与者在订单状态流转时被赋值的”。3.4 构件图与组件图把系统拆成可交付的物理模块网上订餐系统的UML文档里构件图组件图是最容易被忽视却最能在答辩加分的部分。构件图描述的是系统的物理模块划分和依赖关系对应到实际开发就是“后台管理模块”“顾客端API”“商家端API”“消息推送服务”“支付网关适配层”等。我一般把系统拆成五个构件用户认证组件、菜品管理组件、订单处理组件、配送调度组件、支付与结算组件。构件图模块划分含依赖关系 [顾客端界面] - [订单处理组件] - [支付与结算组件] [顾客端界面] - [用户认证组件] [商家端界面] - [菜品管理组件] - [订单处理组件] [骑手端界面] - [配送调度组件] - [订单处理组件] [订单处理组件] - [数据库访问层] [配送调度组件] - [地图服务接口]构件图画好后部署图就顺理成章顾客端是微信小程序或H5商家端和骑手端是Android/iOS应用后端服务部署在云服务器数据库用MySQLRedis做缓存。我会在构件图旁边标注每个组件的物理交付物格式——比如“订单处理组件”对应后端Spring Boot服务的order模块“菜品管理组件”对应shop模块——让图不再是纸面设计而是能指导工程目录划分的蓝图。4. 动态建模与订单状态机时序图、状态图、协作图怎么画才不白费4.1 下单支付的时序图泳道划分和消息命名规范时序图是动态建模的核心它描述的是“一次操作中各对象之间按时间顺序的交互”。网上订餐系统里最值得画时序图的是“下单支付”和“骑手抢单”两个场景。我画时序图前会先拉出参与对象清单然后按“客户→界面→控制器→数据库”的层级排列泳道避免出现界面直接操作数据库的“跳层”问题。以“下单支付”时序图为例泳道顺序是顾客、顾客端界面、订单控制器、支付服务、数据库。消息序列为顾客点击“提交订单”→界面调用订单控制器submit_order()→控制器校验购物车和库存→控制器向数据库写入订单记录状态待支付→界面跳转到支付页→顾客选择支付方式并确认→界面调用支付服务pay()→支付服务返回成功→控制器更新订单状态为已支付→控制器通知商家端有新订单。这里有个容易画错的地方支付成功后一定要有“更新订单状态”这一步很多新手画完支付就停了导致订单永远停在待支付状态。画时序图时消息命名要和类图的方法名完全一致。比如类图里订单类定义了pay_order(order_id, pay_method)时序图里就必须写pay_order()不能写“支付”两个字。命名不一致会导致类图、时序图、代码三者对不上答辩时被追问“这个消息对应哪个类的方法”就露馅了。我一般在画完时序图后会做一次“消息追踪”从第一个消息开始逐个检查每个消息左侧的对象是否拥有该方法没有就回类图补方法。4.2 订单状态图网上订餐系统最核心的一张图状态图是网上订餐系统区别于其他选题的标志性存在因为订单状态流转是系统的业务核心。我先定义状态集合再画状态转换条件。订单状态有五个待支付、待接单、待取餐商家已接单但骑手未取餐、配送中、已完成外加一个取消状态。取消不是简单的一个状态而是从多个状态都可以撤销到取消取消后的处理逻辑也不同。订单状态集合 S0 待支付已创建未支付 S1 待接单已支付/货到付款等待商家确认 S2 待取餐商家已接单/已出餐等待骑手取餐 S3 配送中骑手已取餐正在配送 S4 已完成顾客确认收货或系统自动确认 S5 已取消订单关闭涉及退款 状态转换条件 S0 - S1 事件支付成功 [支付接口返回success] S0 - S5 事件超时未支付 [15分钟后自动取消] 或 顾客主动取消 S1 - S2 事件商家接单 [商家点击接单] S1 - S5 事件商家拒单 [系统自动退款] 或 超时未接单 [30分钟未接单自动取消并退款] S2 - S3 事件骑手取餐 [骑手点击“已取餐”] S2 - S5 事件骑手长时间未接单 [系统取消并退款] S3 - S4 事件顾客确认收货 或 骑手点击送达后30分钟自动确认 S4 - 无后续状态订单关闭状态图的核心价值是帮开发人员理清“非法转换”。比如从待支付直接跳到配送中是绝对不允许的状态图里没有这条转换路径代码里的状态机框架就会拦截。软考UML试题经常考“哪个状态转换是合法的”画过状态图的人一眼就能排除错误选项。我会在状态图旁边额外画一个简单的小表列出“每个状态可执行的操作”比如待接单状态下顾客可以取消但不能评价配送中状态下可以催单但不能取消。4.3 协作图与活动图的区别什么时候用协作图什么时候不值得用协作图通信图和时序图表达的是同一组交互只是视角不同时序图强调时间顺序协作图强调对象间的链接关系。网上订餐系统里我建议只对“商家接单”这种多对象协作场景画协作图即可不需要每个用例都画。因为时序图已经覆盖了大部分交互场景协作图画多了会让文档臃肿软考阅卷时也不要求每个用例都配两张图。商家接单的协作图参与对象有四个系统、商家端界面、订单控制器、商家账号。链接关系是系统推送新订单→商家端界面显示订单详情→商家点击接单→订单控制器更新状态→控制器通知骑手端。这个协作图的核心价值在于展示“谁和谁直接通信”。4.4 用例图、时序图、状态图的一致性检查三个必查项图表画完不是结束一致性检查才是决定文档质量的关键。我在交付前固定查三处用例图里的每个用例是否有时序图覆盖没有覆盖的用例要补齐时序图里的每个消息是否能在类图里找到对应方法状态图里的每个状态是否在类图的status属性取值范围内。三条检查都过图与图之间就是闭环的答辩时问到哪张图都能互相呼应。做一致性检查有个实操技巧打印出图表清单给每个用例、每个状态、每个方法编号然后画一张追踪矩阵表。用例编号用UC01、UC02类图方法编号对应到类名加方法名状态图的状态编号用S0到S5。矩阵表三列分别写用例编号、覆盖的时序图编号、涉及的状态编号。这张表放在文档附录里是答辩时的杀手锏也是简历里的项目亮点——因为大多数课程设计没有一致性追踪的痕迹你有了就比同组人“工程化”很多。5. 避坑指南网上订餐系统UML建模的5条血泪经验5.1 坑一用例图画了十几个每个却都没有备选流现象用例图画得密密麻麻顾客注册、修改密码、忘记密码、浏览历史都单独画成用例但每个用例的名字下面没有一行文字说明更没有用例规约。答辩时老师问“顾客注册失败怎么办”回答不上来。原因把系统所有功能都平铺成用例没有关注用例的“业务价值”。修改密码不是独立用例它是用户管理的扩展忘记密码也不是它是登录的备选流。用例不是功能清单而是“参与者可感知的目标”。解决砍掉三个以下子功能把登录注册合并为“用户认证”修改密码、找回密码降级为“用户认证”的备选流。每个用例必须写基本流和备选流备选流至少写两条——一条异常路径一条业务分支路径。用模板强制自己写不会写就回去看2.2节的用例规约示例。5.2 坑二类图里的订单类画了关联关系数据库表里却没有外键现象类图里用户和订单清楚地画了一对多关联但表结构里订单表没有user_id字段。代码里联查用户订单时只能全表扫描再内存过滤逻辑混乱。原因类图画完没有做“类图转表映射”关联关系在类图上存在但没有落到建表语句里。很多时候是因为参考了别人的类图模板属性照抄了关系没抄完整。解决画完类图后强制做3.3节那张映射表逐条检查“每个一对多在多方表里是否有外键”。订单表必须有user_id、shop_id、rider_id三个外键订单明细表必须有order_id和dish_id两个外键。检查时对着类图的每条关联看一遍看漏的用红笔圈出来。5.3 坑三状态图从“待支付”直接画到“配送中”现象状态图上订单从待支付直接变成配送中中间没有经过待接单和待取餐两个状态。代码实现时发现商家还没确认订单骑手就已经接单了业务逻辑完全错乱。原因没有把“商家接单”和“骑手取餐”这两个关键业务节点识别为独立状态。把订单履约过程压缩得太粗觉得“支付完就送”是理所当然。解决先把订单的全流程用活动图过一遍每个需要“等待外部参与者操作”的点都是独立状态。网上订餐系统至少要有待接单和待取餐两个过渡状态不能省略。画状态图之前先列状态集合再画转换不要边画边想。5.4 坑四时序图里的消息用一个箭头直接画到底现象时序图从顾客画一个箭头直接指向数据库写着“保存订单”中间没有经过任何控制类和处理过程。看起来节省了泳道实际把系统的分层结构全毁了。原因把时序图理解成“谁调用了谁”没有理解“边界类-控制类-实体类”的分层职责。常见做法是直接图省事一笔画到底。解决坚持“界面→控制器→数据库”三层结构消息必须逐层传递。顾客端界面只能调用订单控制器订单控制器才能操作数据库对象。这不仅是图的问题也直接决定了代码的Controller-Service-DAO分层是否清晰。5.5 坑五UML图全部用Visio画导出后文字重叠、形状变形现象用Visio默认模板画UML图导出成图片时文字被截断、箭头错位、类图矩形拉伸变形。放进Word文档后更是一团糟老师根本看不清类名和方法。原因Visio虽然能做UML图但它不是UML专用建模工具没有语法校验和布局自动优化。类图属性一多矩形就会无限拉长箭头位置完全失控。解决推荐用专门UML建模工具StarUML或PlantUML都可以。StarUML适合图形化操作支持从类图直接生成代码框架PlantUML适合用文本描述生成图画状态图和时序图效率极高还能放进Git进行版本管理。另外建议导出时用高分辨率PNG或直接嵌入矢量格式避免Word压缩后模糊。6. 从文档到代码一份UML网上订餐系统文档如何变成可运行的项目6.1 类图直接生成数据库建表语句的模板类图画到3.2节那种详细程度时可以半自动生成建表语句。我把类图的属性转成SQL字段类型映射规则是int→INTstring→VARCHARdecimal→DECIMALdatetime→DATETIME。下面的建表语句可以直接抄走字段含义我在注释里标注清楚。CREATE TABLE orders ( order_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 订单主键, user_id INT NOT NULL COMMENT 顾客ID外键关联user表, shop_id INT NOT NULL COMMENT 商家ID外键关联shop表, rider_id INT COMMENT 骑手ID外键关联user表接单后赋值, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号规则yyyyMMddHHmmss4位随机数, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总额菜品金额配送费, delivery_fee DECIMAL(10,2) DEFAULT 0 COMMENT 配送费按距离计算, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1待接单 2待取餐 3配送中 4已完成 5已取消, pay_method TINYINT COMMENT 1微信 2支付宝 3余额, remark VARCHAR(255) COMMENT 顾客备注, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, pay_time DATETIME COMMENT 支付时间可空, finish_time DATETIME COMMENT 完成时间可空, INDEX idx_user_id (user_id), INDEX idx_shop_id (shop_id), INDEX idx_status (status), INDEX idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;这里status字段用TINYINT而不是VARCHAR或ENUM是因为业务上订单状态可能有增减用数字类型加代码注释表比ENUM更灵活。比如未来要加“退款中”状态ENUM就得改表结构TINYINT只需要改常量枚举类。这也是UML类图属性设计中status写“int”的原因——不要为了省事把状态设计成字符串硬编码的字符串在代码里到处都是魔法值。6.2 从状态图到代码状态机的落地用枚举类把状态转换锁起来状态图不是画完就结束它一定要落到代码里才能体现价值。订单状态转换是网上订餐系统里最容易写烂的代码很多人用if-else堆出几十行判断后续新增状态就崩。我习惯于把状态图直接翻译成Java枚举把合法的状态转换写进枚举的转换表。public enum OrderStatus { // 状态定义code是数据库存储值desc是状态说明next是允许转换的状态列表 WAIT_PAY(0, 待支付, new int[]{1, 5}), WAIT_ACCEPT(1, 待接单, new int[]{2, 5}), WAIT_DELIVERY(2, 待取餐, new int[]{3, 5}), DELIVERING(3, 配送中, new int[]{4}), FINISHED(4, 已完成, new int[]{}), CANCELED(5, 已取消, new int[]{}); private final int code; private final String desc; private final int[] next; OrderStatus(int code, String desc, int[] next) { this.code code; this.desc desc; this.next next; } public boolean canTransferTo(OrderStatus target) { for (int n : next) { if (n target.code) { return true; } } return false; } }这个枚举类的设计逻辑就是状态图的“状态转换条件表”。调用处比如商家接单的代码只需判断当前状态是否能转换到目标状态不合法就直接抛出异常。这样保证了图是图的逻辑、代码是代码的逻辑二者不会脱节。如果手边项目用的是Python也可以用同样的思路写一个OrderStatus类用set存储合法转换效果一致。6.3 时序图里的消息链直接对应Controller-Service-DAO三层时序图的“顾客界面→订单控制器→数据库”三层消息链落地到Spring Boot项目就是一个标准的三层架构。我做了个对比表放在文档里方便答辩时讲解时序图消息 对应代码层 顾客端界面 前端Vue/小程序页面 订单控制器submitOrder() OrderController类 控制器调用数据库对象 OrderService - OrderMapper 支付服务pay() PaymentService对接微信支付SDK 通知商家端 RabbitMQ消息队列这里特别注意“支付服务”不是写在OrderController里的而是独立出一个PaymentService——因为支付要对接第三方SDK职责单一。我见过同一篇课程设计里把支付逻辑揉进订单Controller的代码看起来短了但一旦支付接口要替换订单模块就得整体返工。做架构拆分时把控制类拆分到构件图上的独立构件才是靠谱设计。6.4 部署图和构件图的资料答辩时怎么讲才加分答辩时间有限UML文档里图又多不可能每张图都讲。我建议按这个顺序讲第一张讲用例图用两句话概括系统是干什么的、给谁用第二张讲订单状态图重点说明状态转换的合法性设计——这是系统的业务核心最难讲清也最容易出彩第三张讲类图介绍核心实体和关联关系最后如果时间还有提一下构件图对应的技术栈。状态图是最值得用来“立人设”的图。讲的时候这样说“订单表里的status字段我用整型存储状态机用枚举约束从待支付到配送中必须经过待接单和待取餐两个状态——这个约束是从状态图直接翻译成代码的线上跑了一年没有出现一次跳状态异常。”用第一人称讲你的设计决策和结果比单纯念图上的文字有说服力得多。6.5 交付前用这份清单自查一遍省得到答辩现场翻车我吃过亏——答辩前一晚检查文档发现时序图里消息名和类图方法名不一致改图改到凌晨两点。后来我做了一份自查清单每次交付前对照检查这里分享给你第一用例图里的每个用例是否有对应的时序图第二时序图里的每个消息在类图里是否能找到同名方法第三类图里每个一对多关系在数据库表里是否有外键第四状态图里每条转换路径是否都有触发事件和守卫条件第五部署图里的每个节点是否都能对应上构件图里的一个构件。第五项最常被忽略但老师只要问“系统部署了几台服务器”就会用到。做完了这套自查再从头到尾想一遍业务闭环顾客下单钱怎么付商家怎么接骑手怎么送顾客怎么确认每个环节在哪张图里有描述。全部打通这份UML网上订餐系统文档就算真正立住了照着它编码、测试、部署都不会再踩大坑。希望帮到你。本文还有配套的精品资源点击获取