简介《UML网上订餐系统分析与设计》是一份面向软件工程课程实验与UML建模初学者的完整实验报告围绕网上订餐场景梳理游客注册、用户登录/注销、餐品检索、订单维护及管理员后台等业务流程。文档从需求模型入手依次给出架构模型、分析机制、关键抽象和用例实现并配有类图与顺序图注册、登录等用例还细化了事件流、前置条件、后置条件与备选流便于对照理解从需求到设计的建模思路。资源包共1个doc文件约149KB篇幅集中、结构清晰可直接作为课程大作业、实验报告撰写或UML建模练习的参考范本。已有4230人学习适合需要快速掌握用例图、序列图/顺序图和类图表达方式的学生与开发人员查漏补缺。1. 需求先立住一份 UML 网上订餐系统设计为什么难在三处对齐带过几轮大作业之后我发现UML 网上订餐系统这类题目真正卡住人的从来不是画不出图而是三处对不上需求模型里列了十个用例分析模型里的类却只剩五个顺序图里界面层直接连数据库类图标了 0..1 的多重性建表时却写成外键非空。评审的人只要顺着一条主流程走下来三处一断整份设计就站不住。这套方案要解决的就是对齐问题把游客、注册用户、管理员三类角色餐品、订单、收藏、评论、留言、公告六条业务线用需求模型、分析模型、用例实现三段式串成一条能从图走到表的链路。它适合正在交 UML 建模大作业、软件工程课程设计的学生也适合要出一份系统分析文档的初级工程师照着结构改改就能用。2. 需求模型三类角色、十个用例与权限边界的切法需求模型最容易写成功能清单十个用例排成一列谁都能做、谁都做不全。合格的切法是把角色先钉死再让用例挂到角色上最后用权限矩阵反向校验一遍有没有漏角色、有没有多角色。2.1 用例图角色先定用例后挂这份设计的角色只有三类不要贪多。游客是未登录态能做的只有注册、浏览餐品目录、看部分留言和公告注册用户是登录态比游客多出选购、收藏、评论、订单维护、个人资料修改管理员是后台态管餐品、管订单、管用户权限、管留言和公告。三个角色不并列游客和注册用户是同一实体的不同状态这一点在类图里会体现为 guest 与 user 的关联而不是继承。十个用例按业务归组账户线有注册、登录与注销、用户信息管理交易线有餐品信息检索、餐品选购、订单信息管理内容线有餐品评论、收藏夹管理、留言板管理、公告栏管理再加一条管理员专属的餐品管理和用户权限管理。归组的意义在于同一组的用例共享同一批实体类画顺序图时可以复用控制层对象不至于十张图画出十种风格。判断用例粒度有个简单办法一个用例必须能独立写出一段完整的基本流和至少一条备选流。如果写不出来说明它只是主用例里的一个步骤应该降级为子流程。比如「清空订餐车」单独拿出来做用例就过细它属于餐品选购基本流里的第 3 步。2.2 用例规约的六要素以注册和登录为例用例规约是很多人偷懒的地方图上画个椭圆就算完。实际评审看的就是规约写得够不够细。六个要素固定为简要说明、事件流基本流加备选流、前置条件、后置条件、特殊要求、扩展点。扩展点可以写「无」但前五个不能缺。注册用例的规约重点在备选流。基本流是游客选注册、系统返回注册页、填写用户名密码邮箱电话安全问题、系统校验、提交、提示成功并默认登录。三条备选流必须写全字段长度超限或格式不符时给提示并退回注册页用户名已被占用时提示并退回系统异常时给出维护提示。前置条件是游客发起注册后置条件是游客成为注册用户。登录用例要拆成两个角色看。普通用户在前台登录输入用户名、密码、验证码校验通过后记录登录态并回主页可以主动注销。管理员只能从后台登录不提供管理员注册入口账号只能在数据库里由运维添加这一条是安全性设计里最容易被忽略又最容易被问到的点。备选流至少写三条忘记密码走找回流程、账号密码错误提示重试、管理员越权从前台进入时拒绝。2.3 include 与 extend 的取舍这两个关系被滥用的概率极高。判断标准只有一条被抽出来的行为是不是每次都要执行。每次必执行、且被多个用例共用用 include比如「登录校验」被选购、收藏、评论、订单四条线 include箭头指向被包含用例。有条件执行、执行与否取决于运行时分支用 extend比如「找回密码」只在用户点忘记密码时才发生箭头从扩展用例指向基础用例。有个反直觉的经验宁可少画 include。一张用例图上出现五六条 include 线通常说明作者把「系统内部调用」误当成用例关系了。用例之间是参与者可见的行为关系不是代码里的函数调用。2.4 角色权限矩阵反向校验用把十个用例和三类角色做成矩阵横轴角色、纵轴用例能做的打勾。这张表的价值不在展示在于校验每一行至少有一个勾否则是用例没人用每一列至少有一个勾否则角色是多余的管理员这一列不能出现「注册」用户这一列不能出现「餐品上架」。用例游客注册用户管理员注册可不可不可登录/注销不可可仅后台餐品检索可可可餐品选购不可可不可收藏夹管理不可可不可餐品评论仅浏览可评论回复仅浏览订单信息管理不可可下单撤销可发货完成留言板管理仅浏览部分可留言可回复删除公告栏管理可浏览可浏览可增删改餐品管理不可不可可用户权限管理不可不可可冻结解冻矩阵里「订单信息管理」这一行最有意思同一用例被两个角色共用但操作不同这时候不要拆成两个用例而是在规约的基本流里分段写「用户订单管理」和「管理员订单管理」顺序图也画两张。这是角色与用例多对多时最干净的写法。3. 分析模型四节点架构、六种分析机制与九个关键类需求模型回答做什么分析模型回答怎么分。这一层如果只画一张漂亮的类图就交差后面的顺序图必然接不上因为没人知道哪个类该承担持久化、哪个类该做安全校验。3.1 架构模型四个节点各自管什么架构图画成 ClientSystem、Server、DBsever、Printer 四个节点。ClientSystem 是浏览器端只负责界面渲染和输入采集不写业务判断Server 承载控制层和信息保护层所有校验、状态流转、权限判定都在这里DBsever 承担持久化只有信息保护层能连它Printer 是订单出票的外部设备通过 Server 的打印接口对接。四个节点之间的连线是有方向的这一点很多人画错。客户端到服务器是请求方向服务器到数据库是读写方向服务器到打印机是单向输出。客户端不能直连数据库这条在顺序图上体现为界面层永远只发消息给控制层绝不出现「界面层 → 数据库」的消息箭头。Printer 单独成节点常被质疑多余其实它是「遗留接口」分析机制的载体。现实中的订餐系统出票机走的是并口或串口协议属于典型的 legacy interface把它画成独立节点正好说明系统为什么需要一个适配层去包装它而不是让控制层直接调硬件。3.2 分析机制把横切关注点挂到类上原文列了六种机制Persistency、Security、Distribution、Communication、Parsing、Legacy interface、Redundancy。逐个对上号orderlist、order、dish、user、guest、favorite、notice-board、comment 都带 Persistency因为这些实体都要落库order、system、user、guest 带 Security因为涉及权限和身份dish 带 Distribution因为餐品信息要分发到前台展示和管理员后台orderlist、notice-board、comment 带 Communication因为它们承载用户与系统之间的消息comment 带 Parsing评论内容要做长度和敏感词解析系统整体带 Legacy interface对应打印机这类老设备。这一步在文档里通常画成一张机制对照表两列分析类、涉及机制。它的作用是给后续的类设计加约束凡是标了 Persistency 的类类图上必须能对应到一张实体表凡是标了 Security 的类顺序图里必须出现信息保护层的校验消息。分析类涉及机制orderlistPersistency、SecurityorderPersistency、SecuritydishPersistency、DistributionuserPersistency、SecurityguestPersistency、SecurityfavoritePersistency、Communicationnotice-boardPersistency、CommunicationcommentPersistency、ParsingsystemPersistency、Legacy interface3.3 九个关键类与多重性的取值依据关键抽象定为九个guest、user、system、dish、orderlist、order、favorite、comment、notice-board。多重性标注是这份模型里含金量最高的部分因为每一个 0..* 和 0..1 背后都对应一条业务规则。guest 与 comment 是 0..* 对 0..1一个游客可以发零到多条评论实际系统里通常要求登录后才能评论这里保留游客浏览语义一条评论只属于一个发布者。user 与 order 是 0..* 对 0..1一个用户可以有多张订单一张订单只属于一个用户0..1 表示订单尚未生成时用户可以没有订单。order 与 dish 通过 orderlist 建立 0..* 对 0..1 的间接关联一张订单包含多条明细一条明细对应一个餐品。user 与 favorite 是 0..* 对 0..1收藏条目必须挂在用户名下。dish 与 comment 是 0..* 对 0..1一个餐品可以有多条评论。容易标错的是 order 与 dish 之间。如果直接画成多对多就会丢掉「买了几个」这个信息正确做法是引入 orderlist 作为关联类把数量、单价、折扣放进去。这也是后面建表时订单主表加订单明细表两张表的模型依据。关系多重性业务含义user—order0..* 对 0..1一人多单单归一人order—orderlist0..* 对 0..1一单多明细orderlist—dish0..* 对 0..1明细指向具体餐品user—favorite0..* 对 0..1一人多收藏dish—comment0..* 对 0..1一菜多评论guest—comment0..* 对 0..1一条评论一个发布者3.4 类图落地属性、方法与可见性对照原模型的类属性里存在明显的类型误用比如 telephone 写成 int、time 写成 int。落在文档里要修正telephone 用字符串因为要保留前导零和区号时间用 datetime价格用 decimal 而不是 double避免浮点误差。dish 类的 markprice 是市场价、dishprice 是网订价两个价格字段并存是为了展示折扣discount 不单独存由两个价格相除得出。方法部分按职责给user 类提供 register、login、logout、updateProfile、changePassworddish 类提供 search、list、updateorder 类提供 create、cancel、confirmorderlist 类提供 addItem、removeItem、clear、calcTotal。可见性上属性一律 private方法对外 public只在 calcTotal 这类内部计算上用 private。这套约定写进文档后面写代码就能直接照着实现。4. 用例实现从顺序图的消息编号到控制层与信息保护层的落地顺序图是把模型翻译成实现的最后一公里。十条主流程每条都要有图但图的骨架是一致的左边参与者中间控制层右边信息保护层最右数据库或外部设备。消息必须编号编号顺序就是调用顺序也是后面排查问题的依据。4.1 三层边界界面层、控制层、信息保护层界面层只做两件事采集输入、展示结果。所有判断都不放在这里。控制层是业务大脑负责参数校验、状态判定、调用持久化。信息保护层是唯一的数据库入口做 SQL 组织、事务控制、加解密。一个典型错误是把「验证用户名是否已存在」画在界面层。正确的位置是控制层收到注册请求后先调信息保护层的 queryByUsername拿到结果再决定返回成功还是提示重名。顺序图上这条消息的编号一般是 2 到 5 之间顺序是提交信息、校验格式、查重、写库、返回。4.2 注册与登录消息编号与校验顺序注册的顺序图固定七步用户选择注册界面、填写注册信息、提交、控制层做字段校验、信息保护层查重并写入、返回保存结果、回显注册成功。校验顺序不能乱先做本地格式校验再做数据库查重因为格式不符的请求不应该打到数据库。登录同理先校验验证码再校验账号密码最后写登录日志把最便宜的校验放最前面。密码存储这一层在模型里体现为 Security 机制挂到 user 类上实现时对应的是信息保护层里的加密方法。文档里不需要写具体算法但要写明「密码不以明文落库注册时加密、登录时比对摘要」这条写进去答辩时就是加分项。# 注册请求处理控制层校验顺序不能颠倒 def handle_register(form): # 1. 本地格式校验不碰数据库成本最低 for field in (username, password, email, telephone, security_question): if not form.get(field): return {code: 400, msg: f{field} 不能为空} # 2. 长度与格式规则避免超长字段写入 if not (6 len(form[username]) 20): return {code: 400, msg: 用户名长度需在 6 到 20 之间} if not re.match(r^1[3-9]\d{9}$, form[telephone]): return {code: 400, msg: 手机号格式不正确} # 3. 查重放在最后只有格式合法的请求才访问数据库 if user_dao.find_by_username(form[username]): return {code: 409, msg: 该用户名已被注册} # 4. 密码摘要后落库明文不进入持久层 user_dao.insert( usernameform[username], password_hashhash_password(form[password]), emailform[email], telephoneform[telephone], security_questionform[security_question], ) return {code: 200, msg: 注册成功}这段代码对应顺序图里控制层的前四条消息hash_password 和 user_dao 分别落在信息保护层的两个职责里。参数上要注意 username 唯一索引、telephone 用 varchar(20)这两个在建表时就要定死否则后面改表代价很大。4.3 餐品选购与订单结算合并规则与总价计算购物车是这份设计里逻辑最密的地方。基本流五步加入餐品、移除餐品、清空、价格统计、结算生成订单。关键的合并规则是同一餐品重复加入不新增条目只把数量累加。这一条不写清楚实现时就会出现同一菜品两行明细的翻车现场。结算时把购物车快照写进订单明细而不是只存 dish_id。原因很实在餐品价格会变订单要保留成交时的价格。这条规则在类图上体现为 orderlist 冗余存储单价字段在表结构上体现为订单明细表同时存 dish_id、dish_name、unit_price 三个快照字段。-- 订单主表一次结算一条 CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0, -- 0待发 1已发 2已完成 3已撤销 receiver VARCHAR(32) NOT NULL, telephone VARCHAR(20) NOT NULL, address VARCHAR(200) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_status (user_id, status, created_at) ); -- 订单明细表价格与名称做快照餐品下架不影响历史订单 CREATE TABLE order_item ( item_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, dish_id BIGINT NOT NULL, dish_name VARCHAR(64) NOT NULL, unit_price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL DEFAULT 1, KEY idx_order (order_id) );idx_user_status 这个联合索引对应的是管理员端「按状态分类检索、按生成时间降序」这个需求索引里 created_at 放最后正好支撑 order by 的排序不走文件排序。这是模型层看不出来、实现层必须补的一笔。4.4 管理员订单管理五态流转与不可逆约束订单状态在设计里定四态加一个初始态待发、已发、已完成、已撤销。流转规则是单向的待发可以转已发或已撤销已发可以转已完成或已撤销已完成和已撤销是终态不能再变。撤销后的订单不从记录里删除只改状态这样历史查询还能查到。# 订单状态机把允许的流转写死非法流转直接拒绝 ALLOWED_TRANSITION { 0: {1, 3}, # 待发 - 已发 / 已撤销 1: {2, 3}, # 已发 - 已完成 / 已撤销 2: set(), # 已完成是终态 3: set(), # 已撤销是终态 } def transit(order_id, target_status): current order_dao.get_status(order_id) if current is None: return {code: 404, msg: 订单不存在} if target_status not in ALLOWED_TRANSITION[current]: # 典型场景已完成的订单想撤销必须拒绝 return {code: 409, msg: f状态不允许从 {current} 流转到 {target_status}} order_dao.update_status(order_id, target_status) return {code: 200, msg: 状态更新成功}用户侧和管理员侧的撤销权限要分开用户只能在管理员发货前撤销也就是待发态管理员可以撤销待发和已发两态但已发撤销要留操作日志。这条规则不写进状态机就会变成线上事故。5. 避坑与排查六个让模型和实现对不上的高发问题5.1 建模阶段的三个坑现象一用例图画了十二个椭圆类图只剩七个类顺序图想画却找不到对象。原因是用例是按页面切的不是按业务行为切的。解决办法是把每个用例回溯到它的主实体一个用例至少对应一个关键类对应不上的说明它只是一个页面跳转合并到父用例里。现象二多重性全标成 0..* 对 0..*看起来通用一建表全是中间表。原因是作者没想清楚业务上的一对多关系。解决办法是逐条问三个问题一条 A 能不能属于多条 B、一条 B 能不能属于多条 A、这条关联上有没有需要携带的属性。第三个问题答「有」就说明要引入关联类比如 orderlist。现象三顺序图里界面层直接连数据库或者控制层自己拼 SQL。原因是图是照着功能写的不是照着架构写的。解决办法是先定死三层边界界面层只发消息给控制层控制层只发消息给信息保护层画完之后拿这个规则扫一遍每张图越界的连线全部重画。5.2 数据与状态阶段的三个坑现象四删除餐品时把历史订单里的菜名一起删没了。原因是订单明细只存了 dish_id没有做快照。解决是在明细表里冗余 dish_name 和 unit_price删除餐品只做逻辑删除改状态字段物理行不动。现象五注册接口被刷数据库里出现几十条同用户名记录。原因是查重和插入之间没有唯一约束兜底。解决办法是给 username 加唯一索引代码里查重是为了给友好提示数据库约束才是最后一道防线两者不能互相替代。现象六用户已完成的订单被撤销金额对不上账。原因是状态流转没有写死。解决是把状态机抽成常量表任何状态变更都走同一个 transit 函数非法流转直接返回 409不允许在其他地方直接 update status。排查顺序建议固定为四步先看顺序图里消息编号是否连续、有没有跳跃再核对类图多重性和表结构的外键是否一致然后检查状态字段的取值集合和代码里的常量是否对得上最后扫一遍权限矩阵确认每条接口的角色校验都落到了信息保护层而不是前端。提示评审最常问的三个问题是「这个 0..1 为什么不是 1..1」「删除餐品后历史订单还能不能查」「管理员能不能从前台登录」。三个都答得上来模型基本就站住了。6. 验收与答辩用一张对照表证明模型能驱动实现验收这件事别等最后一页 PPT 才想起来。我的做法是在文档定稿前自己先做一张「模型—实现」对照表横轴是模型产物纵轴是实现产物逐行填填不满的行就是要在答辩前补的洞。模型产物对应实现产物验收要点用例图十个用例十个接口或页面入口每个用例能找到至少一个入口角色权限矩阵接口级角色校验越权请求返回 403类图九个类九张表或实体类属性名、类型能一一对上多重性标注外键与索引0..* 侧建索引0..1 侧建外键顺序图消息编号控制层方法调用链编号顺序与调用栈一致状态流转规则状态机常量表非法流转被拒绝并有日志分析机制对照表加密、事务、打印适配层每项机制有落点代码填表时有个小技巧从右往左填。先列出你实际写了哪些接口、建了哪些表再回到模型里找对应项找不到的就是模型缺失找到两个以上对应的就是模型冗余。这个方法比从左往右填更容易发现「图很好看但没落地」的问题。答辩陈述按四段走每段控制在一分半。第一段讲清楚三类角色和权限边界用权限矩阵那页第二段讲架构四节点和三层边界重点强调客户端不直连数据库第三段挑一条主流程从用例规约讲到顺序图再讲到建表注册或下单都行讲完这条流程可信度就有了第四段主动暴露一个设计取舍比如「订单明细做价格快照是因为餐品会调价」主动讲比被问出来强得多。被追问时别急着解释图先回答业务规则再回到图上指位置。评审问「为什么这个关联是 0..1」实质是在问业务上允许不允许为空答「订单未生成时用户没有订单所以是 0..1」比答「UML 规范这么定义」有用得多。注意文档里所有类型错误都要提前修掉。telephone 写成 int、时间写成 int 这类问题一眼就会被看出来修起来只要十分钟不修就是整份文档的专业性被打折。我第一次交这份作业时类图上标了漂亮的多重性建表却全写成外键非空答辩时被问「游客没有订单怎么插数据」当场卡住。从那以后我每次做完模型都强制走一遍「模型—实现」对照表填不满的行绝不往下推。希望帮到你。本文还有配套的精品资源点击获取
