第一章 绪论
1.1 研究背景与意义
外卖行业的规模不断增大，传统的以人工接单、派送为主的配送方式已经不能满足市场的需要了。商家依靠电话或者社交软件下单，信息传递出现失误情况时有发生，在高峰时段的订单量会堆积起来。配送过程中没有对配送过程进行可视化的监控，用户不能随时知道餐品的位置，从而影响到用户的满意度。数字化外卖平台把商品展示、订单生成、配送跟踪、售后服务等环节都纳入到一个系统化的管理当中去。詹婧等人认为平台站点组织支持对零工就业者的就业职业幸福感有明显的影响，外卖骑手的工作体验同平台系统是否稳定、透明有关1。肖明魁等人的研究认为，新能源电车和AI的结合可以提高外卖系统的竞争力，技术集成成了提高外卖系统竞争力的重要途径2。徐培镪利用UTAUT模型分析得出用户对于智能化外卖服务的接受度比较高，系统功能设计的好坏直接决定着用户的使用意愿3。利用SpringBoot以及Vue技术栈搭建出一个外卖系统，整合用户端、商家端、配送端、管理端这四种角色，并且可以很好地解决传统模式下出现的信息孤岛和流程断裂的问题，给本地生活服务提供技术支持。
该系统价值是经过重新构建的操作流程和合理调配的资源这两个方面来体现的。传统的模式下商家要三个人工来分别完成接单、核对和配送调度这三个步骤，系统的自动化处理把这三个步骤简化成了一个操作节点，因此人工错误率也降低了。订单信息由用户提交到后厨打印过程中没有发生任何错误。配送路径的人工经验分配变成了系统的智能调度，配送员的负载均衡度得到了提高。就行业来说，平台使中小型餐饮企业可以实现线上化转型，降低了数字化工厂进入这个领域时的门槛。商家不需要自建技术团队就可以获得标准化的外卖管理工具，整个行业的信息化程度得到提高。多角色协同设计给本地生活服务平台提供了一种可以复用的架构模式，类似于社区团购、上门维修等场景可以参考该系统权限分离和状态流转的机制。在实际应用中解决了用户催单焦虑、商家漏单等问题，也提高了配送员的效率和外卖交易的社会效率。
1.2 国内外研究现状
国内外的卖平台由最初的只是提供信息展示功能，发展到现在的可以提供全流程服务。早期的门户时代外卖频道是以商家信息的罗列为主，用户是通过电话来完成订单，交易数据的积累比较困难。垂直社区兴起之后，论坛形式的餐饮评价系统产生了用户互动的需求，评论和推荐机制也进入了平台的架构之中。移动互联网爆发时期，美团外卖、饿了么这些平台用LBS定位、实时配送跟踪、智能调度算法这些手段大幅度加强了订单处理能力。苏雪等人根据自然骑行数据创建了外卖骑手画像分析系统，配送行为数据成了改进调度方案的参照3。张敏娜认为数字经济中劳动异化现象的产生是由技术架构所决定的，需要在效率和骑手权益之间找到平衡4。徐培镪用UTAUT模型得出结论，用户对新外卖技术的采纳行为是由感知有用性和感知易用性共同决定的5。邱果对物流无人机配送成本效益进行测算，低空经济的发展给外卖配送带来了新的思路6。王璇对餐时间、订单相似性等影响路径优化的因素进行了研究，从而使得算法得到了改进，成为行业的研究热点7。
国外的外卖平台发展道路是靠技术推动的。早期的Grubhub和DoorDash等平台主要是依靠社交媒体来吸引用户，用户生成的内容在平台生态系统中占有很大的比重。数据驱动阶段之后，实时订单分配系统代替人工调度，预测模型被用来做配送时间的估计。Uber Eats把出行调度算法搬到外卖领域之后，就形成了一个整体，即动态定价和配送员激励系统。Chen J对商户自营配送的订单规划公平策略进行研究，配送计划的优化会直接影响到多方的利益8。Hu D把订单履行时点当作预测模型的输入变量来改进系统的可解释性9。中青年在研究外卖餐盒回收系统时使用了循环经济理论来进行指导，从而设计出外卖餐盒的可持续发展体系。关于订单分配和路径规划之间的协同优化机制，Guofeng S对多目标决策问题进行过研究11。Global Foam Trays Market研究报告揭示外卖系统增长带动产业链上游需求扩张12。
1.3 研究内容
本文的主要工作就是设计并实现一个基于SpringBoot和Vue技术栈的外卖系统，包括用户、商家、配送员、管理员这四种角色的需求。工作从需求分析开始，整理出各个用户所处的操作环境以及数据的流转路线。系统架构设计阶段决定使用什么技术进行前后端分离，确定各个层次的职责范围。模块实现时分别创建了用户端商品浏览、订单提交、商家端商品管理、订单处理、配送员端配送任务管理、管理员端系统配置、数据监控等各个功能模块。数据库设计按照第三范式来划分出用户账户表、商家信息表、商品表、订单表、配送表这些主要的实体。测试验证阶段就是功能完整性检验、边界条件处理、数据一致性保证的过程。本文主要对多角色权限控制机制、订单状态机状态转移逻辑、购物车数据在会话期的持久化方式等进行研究。预期得到一个可以运行的系统原型、数据库设计文档、测试报告和用户操作手册。整体采用敏捷开发的方式进行开发，分阶段进行功能模块的开发，保证各个模块之间的接口协议统一。
第二章 相关技术介绍
2.1 SpringBoot框架
SpringBoot框架是基于Spring生态系统创建出来的，它的设计目的就是简化传统的Spring应用项目的配置工作。该框架用自动配置的方式处理大量的默认设置，开发者只需要声明starter依赖就可以引入所需要的功能模块13。在Web服务开发的场景下，SpringBoot内嵌Tomcat容器，将应用打包成独立的JAR文件之后可以直接运行。框架主要使用了两种编程范式，分别是依赖注入、面向切面编程。控制反转容器来管理对象间的依赖关系。启动时，框架会扫描类路径下配置的类以及标注有@Component注解的bean。请求处理流程从前端控制器开始，经过处理器映射找到具体的控制器方法，参数解析器把HTTP请求参数转换成方法参数。响应阶段消息转换器把返回值序列化成JSON格式的响应。在订单信息存储的时候，SpringBoot把数据访问层集成进来之后就会拥有事务管理的能力，从而保证多表操作的数据一致性。日志记录使用框架自带的门面模式进行输出，便于找出问题。单元测试可以减少频繁部署容器来检验容器内代码。
该框架的自动配置原理依靠条件化的注解，配置类里声明了许多Condition接口的实现类。类路径下存在特定类文件的时候，相关的配置才会起作用。错误处理机制统一处理控制器抛出的异常，用全局异常处理器返回标准的错误码。跨域请求配置可以使得不同的源的Vue前端调用接口，满足前后端分离部署的需求。拦截器在请求到达控制器之前就对请求进行权限验证，没有登录用户请求会受到拦截并且显示身份失败信息。异步请求处理返回一个Callable对象，释放容器线程来处理其他的请求。
2.2 Vue前端框架
Vue使用渐进式JavaScript框架的思想，只做视图层的编写，依靠官方提供的路由、状态管理等库来构建起整个前端应用。该框架使用虚拟DOM技术来提高页面渲染的效率，模板编译的过程把声明式的模板转换成渲染函数14。数据响应式系统使用Object.defineProperty方法拦截数据的读写操作，组件的渲染是由依赖收集机制来驱动的。组件化开发把用户界面拆分成可以独立复用的单元，每一个组件都有模板、脚本和样式这三个部分。在商城中心页面展示的时候，商品列表组件会接收父组件传过来的数据参数，独立处理内部的选中状态。路由配置管理各个页面之间跳转的逻辑，路径改变时对应的组件就会被渲染和销毁。导航守卫对路由切换前的权限进行检查，未登录用户访问订单详情页的时候会强制跳转到登录页面。
生命周期钩子函数在不同的阶段会执行不同的逻辑，在创建的时候请求商品分类信息来获取数据。计算属性依靠响应式依赖缓存来完成计算结果的重新计算，从而缩减了重复计算的开销。侦听器监听数据的变化，购物车数量发生改变的时候就重新计算价格。指令系统扩展HTML语法，条件渲染指令控制元素的显示和隐藏，列表渲染指令生成商品列表结构。自定义指令封装DOM操作逻辑，输入框自动获取焦点功能就是通过这种方式来实现的。混入对象分发可以复用，分页逻辑在不同的视图组件中是相同的。过渡动画给列表的增删操作加上视觉上的反馈效果。
2.3 MySQL数据库
MySQL是基于关系模型来组织数据，数据存储在行和列组成的二维表里。结构化查询语言是数据操作接口，可以进行创建、检索、更新、删除这四种基本操作15。存储引擎上，InnoDB引擎具有事务处理和行级锁的功能，MyISAM引擎以读取性能为主。索引结构使用B+树算法，非叶结点存放键值和指向下一个结点的指针，叶结点存放完整的数据行。订单查询操作依靠创建订单号索引来保证其响应时间是毫秒级的。事务处理按照ACID设计原则来执行，隔离机制可以避免由于并发操作造成的数据不一致情况发生，可重复读隔离级别采用多版本并发控制的方法来保证。在订单生成的场景中，商品库存的扣减和订单记录的插入是放在同一个事务的范围内，任何一个操作失败就会导致整个事务回滚。
外键约束保证表之间的引用完整性，订单表中的用户编号必须在用户表的主键列中。查询优化器分析SQL语句，选择执行计划，根据代价来决定使用哪种索引以及如何连接。视图机制把复杂的查询结果虚拟成一张表，商家端订单统计功能就用到了这一点。触发器是在一定数据操作前后执行预设逻辑的，订单状态变更新增物流记录的操作是通过触发器自动完成的。将多条SQL语句一起存入到一个存储过程中，从而对多个订单的状态进行批量更新。
2.4 MyBatis持久层框架
MyBatis把Java对象和SQL语句建立起映射关系，开发者编写原生的SQL语句来控制参数绑定以及结果集的处理过程。框架的核心就是动态代理来生成数据访问接口的实现类，SQL语句定义在XML配置文件或者注解中16。参数映射阶段把预编译语句中占位符替换为Java对象的属性值，类型处理器把Java数据类型转换成JDBC类型。商品分类检索的时候，将分类名称作为一个参数传递给映射语句，框架会先将类型转换后再发送到数据库执行。结果集映射就是将查询得到的列值填充到实体对象中，单表查询使用自动映射功能，关联查询用resultMap定义嵌套对象的装配规则。
动态SQL机制根据条件来拼接查询语句，如果参数为空，则使用if标签判断，多余的连接词用where标签处理。分页插件拦截待执行的SQL语句，利用数据库方言生成限制查询条数的物理分页语句。一级缓存作用域是SqlSession对象，同一个会话内执行相同的查询可以得到缓存的结果。二级缓存作用域为Mapper接口，不同的会话共享同一个查询结果缓存，缓存失效的触发条件可以是时间间隔也可以是更新操作。批量操作支持insert语句的多值提交，在订单明细插入的时候用批量执行可以减少数据库连接的数量。延迟加载配置在查询主表之后按照需要加载关联表的数据，订单和配送信息的关联查询只有访问配送属性的时候才会进行第二次查询。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
SpringBoot框架给Web开发提供了一个完整、自给自足的方案，可以减少项目搭建的复杂度。Vue前端框架具有组件化开发的特点，前后端用JSON数据格式来交互。MySQL数据库可以进行事务处理以及并发控制，可以满足外卖系统数据一致性的要求。开发环境使用IntelliJ IDEA集成工具，Maven管理项目的依赖，各个技术组件的版本兼容性好。系统使用的是三层架构，即表现层、业务逻辑层、数据访问层之间用接口来交互，从而减小模块之间的耦合程度。该技术栈已经相当成熟且稳定，社区文档比较齐全，对于开发过程中遇到的技术问题，可以快速地得到解决。
3.1.2 经济可行性
系统开发所用到的软件工具都是开源或者社区版本，IntelliJ IDEA是免费的社区版。MySQL数据库使用的是开源协议许可，不需要支付授权费。前后端框架所用到的依赖库为Mentral中央仓库免费提供，没有需要购买的第三方商业组件。硬件环境使用个人计算机就可以完成开发和测试，生产环境可以部署到云服务器低配实例上。系统上线之后的运维成本主要为服务器租用和域名购买，单月支出在百元以下。开发周期内的人力投入属于主要成本项，但是作为毕业设计项目不包含商业运营支出，经济投入在合理范围内。
3.1.3 操作可行性
用户端界面按照移动端的设计规范来设计，底部导航栏分为商城、购物车、订单三个主要的入口。商家端使用的是卡片式布局，待处理订单和商品管理功能的入口一目了然。配送员端的接单、配送状态切换只需一次点击即可完成。管理员端有数据仪表盘，统计图表和配置项分块。不同的角色登录之后看到的功能菜单会有所区别，不会造成信息的干扰。订单提交过程在三个页面之内完成，商品选择、地址确认、支付操作的步骤依次进行。系统整体学习成本低，用户经过短暂的试用就可以掌握基本的操作方法。
3.2 功能需求分析
UML用例图是描述系统功能需求的图形化工具，用例图通过显示系统与外部参与者之间的交互关系来说明系统的功能。用例图以用例来表示系统能完成的特定功能，参与者则是与系统交互的各类用户或者外部系统。用例图可以在分析和设计阶段使用，保证系统的功能完整、正确，让开发者和客户有共同的语言。用直观的图示，UML用例图给出了系统功能与角色间的关系。本文将按照角色模块对系统进行需求分析。
3.2.1 普通用户用例图
普通用户在系统中执行商品浏览、订单管理、个人信息维护三类操作。商品浏览模块包括按分类查看商品列表、关键词搜索商品、点击商品查看详情、查看网站公告与新闻资讯。订单管理模块涵盖将商品加入购物车、修改购物车商品数量、提交订单、查看历史订单、跟踪订单配送状态。个人信息维护模块包括管理收货地址、修改个人资料、查看收藏商品。普通用户用例图如图3-1所示。
图3-1普通用户用例图
3.2.2 商家用户用例图
商家用户执行商品管理、订单处理、店铺信息维护三类核心操作。商品管理模块包括发布新商品、编辑商品信息、设置商品上下架状态、管理商品分类。订单处理模块涵盖查看新订单、确认接单、更新订单制作进度、处理退款申请。店铺信息维护模块包括编辑店铺基本信息、查看通知消息、设置营业时间。配送管理模块包括分配配送员、查看配送状态。商家用户用例图如图3-2所示。
图3-2商家用户用例图
3.2.3 配送用户用例图
配送用户在系统中执行订单配送相关的操作。配送任务管理模块包括查看待配送订单列表、接取配送任务、更新配送状态为已取餐、标记订单为已送达。工作记录模块涵盖查看个人配送历史、统计配送完成数量。通知查看模块包括接收系统推送的配送提醒消息。配送用户用例图如图3-3所示。
图3-3配送用户用例图
3.2.4 管理员用例图
管理员执行系统运维层面的配置与监控操作。内容管理模块包括发布网站公告、管理新闻资讯、配置首页轮播图。商家管理模块涵盖审核商家入驻申请、管理商家账户状态。用户管理模块包括查看所有用户列表、冻结异常账户、分配角色权限。数据监控模块包括查看订单统计图表、分析商品销售排行、监控系统运行日志。管理员用例图如图3-4所示。
图3-4管理员用例图
第四章 系统设计
4.1 系统架构设计
外卖系统使用前后端分离的B/S架构模式，前端Vue应用部署在Nginx静态服务器上，后端SpringBoot应用运行在独立的容器里17。用户界面层负责页面的渲染以及用户的交互事件，用axios库进行异步请求到后端接口。应用服务层接到请求之后就会开始执行业务逻辑，控制器层会对参数展开校验，并把数据装进服务层，服务层则负责处理订单状态机的变动以及库存的减少工作。数据持久层使用MyBatis框架执行SQL，事务管理保证了订单的创建以及支付记录的原子性。系统支持层使用MySQL数据库来实现数据存储的功能，用Redis做为缓存热点商品数据，从而减小对数据库的压力。各个层之间用接口来约定契约，前端根据Swagger生成的API文档去对接后端接口。系统架构图如下图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
系统用四个用户角色来创建功能模块。普通用户端有商品浏览、购物车管理、订单管理、个人中心四个模块。商家用户端分为商品管理、订单处理、店铺设置、通知查看这四个部分。配送用户端有任务接取、配送更新、历史记录这三个部分。管理员端有用户管理、商家审核、内容发布、数据统计四个模块。商品浏览模块可以按照分类进行筛选和关键词搜索，购物车模块可以对商品的数量进行修改，并且可以对订单进行预结算。订单管理模块对订单的提交到签收全过程都有体现。该系统的功能结构图如下图4-2所示。
图4-2系统功能结构图
4.3 系统流程设计
4.3.1 总体业务流程图设计
用户提交订单后系统执行库存预扣减操作。商家接收订单通知并确认接单，后厨开始制作餐品。制作完成后商家分配配送员，系统推送任务给附近配送员。配送员接单后到店取餐，取餐确认后系统更新订单状态为配送中。用户收到配送信息并实时查看配送员位置。送达后用户确认签收，系统完成交易并将资金结算给商家。配送员获得配送费用，订单流程终结。总体业务流程如图4-3所示。
图4-3总体业务流程图
4.3.2 商品浏览流程设计
用户进入商城中心后系统加载商品分类列表。用户选择某个分类后系统筛选对应商品并展示。用户输入搜索关键词后系统在商品标题与描述中进行模糊匹配。搜索结果按销量或价格排序展示。用户点击商品卡片后系统跳转到详情页面展示完整信息。商品浏览流程如图4-4所示。
图4-4商品浏览流程图
4.3.3 购物车管理流程设计
用户在商品详情页点击加入购物车按钮，系统将商品添加到购物车列表。用户进入购物车页面查看已选商品集合。用户修改某个商品的数量时系统重新计算小计金额。用户删除购物车商品时系统刷新列表并更新总价。用户点击结算按钮时系统验证库存充足性。购物车管理流程如图4-5所示。
图4-5购物车管理流程图
4.3.4 订单处理流程设计
用户提交订单后系统生成唯一订单号并记录订单信息。商家端收到新订单提醒，商家查看订单详情后点击接单。系统更新订单状态为待取餐并通知用户。商家制作完成后标记订单为待配送，系统将该订单加入配送池。配送员接单后到店取餐并确认取走。系统更新状态为配送中并向用户推送配送员位置。订单处理流程如图4-6所示。
图4-6订单处理流程图
4.3.5 配送管理流程设计
配送员登录系统后查看待配送订单列表。配送员选择一个订单点击接取任务，系统锁定该订单避免重复接单。配送员到达商家后扫描订单二维码确认取餐。系统记录取餐时间并更新状态为配送中。配送员到达用户地址后点击送达按钮，上传送达凭证照片。用户确认收到餐品后系统将配送完成状态同步给商家。配送管理流程如图4-7所示。
图4-7配送管理流程图
4.4 数据库设计
数据库设计遵循关系模型规范化原则，通过主键与外键约束维护数据完整性18。系统采用第三范式设计，非主属性完全依赖于候选键避免传递依赖。各类业务实体之间的关联通过外键实现，数据操作依托事务机制保证原子性。订单模块涉及用户、商品、配送三张表的联动更新，并发控制采用乐观锁机制避免超卖现象。
4.4.1 概念设计
普通用户实体主要包括用户编号、用户名、密码、手机号码、邮箱、头像地址、昵称、注册时间、上次登录时间、账户状态、用户组等属性。实体属性图如图4-8所示。
图4-8普通用户实体属性图
商家用户实体主要包括商家用户编号、用户编号、商家名称、商家地址、负责人员、资质证明、审核状态、创建时间等属性。实体属性图如图4-9所示。
图4-9商家用户实体属性图
商品信息实体主要包括商品编号、标题、描述、卖价、原价、商品库存、销量、点击量、上架状态、正文内容、封面图等属性。实体属性图如图4-10所示。
图4-10商品信息实体属性图
购物车实体主要包括购物车编号、用户编号、商品编号、标题、图片、单价、原价、数量、总价、规格等属性。实体属性图如图4-11所示。
图4-11购物车实体属性图
订单实体主要包括订单编号、买家编号、商品编号、商家编号、商品标题、商品图片、价格、总价、数量、规格、订单状态、发货状态、联系人姓名、收件地址、联系电话、邮政编码等属性。实体属性图如图4-12所示。
图4-12订单实体属性图
物流配送实体主要包括物流配送编号、订单号、配送订单号、普通用户、商家编号、配送员编号、商品名称、购买数量、交易总额、收货地址、配送状态、签收状态、发货日期、联系人名字、配送员名字等属性。实体属性图如图4-13所示。
图4-13物流配送实体属性图
配送用户实体主要包括配送用户编号、用户编号、人员姓名、人员年龄、人员性别、审核状态等属性。实体属性图如图4-14所示。
图4-14配送用户实体属性图 
图4-15系统E-R图
4.4.2 数据库表设计
数据库逻辑设计阶段将概念模型转换为关系数据库所支持的表结构形式，依据实体间联系确定主外键约束与参照完整性规则。普通用户表主要是用来存储系统注册账户的基本信息与认证状态。主要包括用户编号、用户名、密码、手机号码、账户状态等字段。如表4-1所示。
表4-1普通用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 用户编号 | int | 11 | 是 | 是 | 用户ID |
| 2 | 用户名 | varchar | 16 | 是 | 否 | 用户名 |
| 3 | 密码 | varchar | 64 | 是 | 否 | 密码 |
| 4 | 手机号码 | varchar | 11 | 否 | 否 | 手机号码 |
| 5 | 邮箱 | varchar | 64 | 否 | 否 | 邮箱 |
| 6 | 头像地址 | varchar | 255 | 否 | 否 | 头像地址 |
| 7 | 昵称 | varchar | 16 | 否 | 否 | 昵称 |
| 8 | 账户状态 | smallint | 6 | 是 | 否 | 账户状态 |
| 9 | 用户组 | varchar | 32 | 否 | 否 | 所在用户组 |
| 10 | 创建时间 | timestamp | - | 是 | 否 | 创建时间 |
商家用户表主要是用来存储入驻商家的资质信息与审核状态。主要包括商家用户编号、用户编号、商家名称、商家地址、审核状态等字段。如表4-2所示。
表4-2商家用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 商家用户编号 | int | 11 | 是 | 是 | 商家用户ID |
| 2 | 用户编号 | int | 11 | 是 | 否 | 用户ID |
| 3 | 商家名称 | varchar | 64 | 否 | 否 | 商家名称 |
| 4 | 商家地址 | varchar | 64 | 否 | 否 | 商家地址 |
| 5 | 负责人员 | varchar | 64 | 否 | 否 | 负责人员 |
| 6 | 资质证明 | varchar | 255 | 否 | 否 | 资质证明 |
| 7 | 审核状态 | varchar | 16 | 是 | 否 | 审核状态 |
| 8 | 创建时间 | datetime | - | 是 | 否 | 创建时间 |
商品信息表主要是用来存储外卖商品的详细描述与销售属性。主要包括商品编号、标题、卖价、商品库存、销量、上架状态等字段。如表4-3所示。
表4-3商品信息表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 商品编号 | int | 11 | 是 | 是 | 产品ID |
| 2 | 标题 | varchar | 125 | 否 | 否 | 标题 |
| 3 | 描述 | varchar | 255 | 否 | 否 | 描述 |
| 4 | 卖价 | double | - | 是 | 否 | 卖价 |
| 5 | 原价 | double | - | 是 | 否 | 原价 |
| 6 | 商品库存 | int | 11 | 是 | 否 | 商品库存 |
| 7 | 销量 | int | 11 | 是 | 否 | 销量 |
| 8 | 上架状态 | smallint | 6 | 否 | 否 | 上架状态 |
| 9 | 正文内容 | longtext | 4294967295 | 否 | 否 | 正文 |
| 10 | 封面图 | text | 65535 | 否 | 否 | 封面图 |
购物车表主要是用来暂存用户加入但未结算的商品条目。主要包括购物车编号、用户编号、商品编号、标题、数量、总价等字段。如表4-4所示。
表4-4购物车表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 购物车编号 | int | 11 | 是 | 是 | 购物车ID |
| 2 | 用户编号 | int | 11 | 是 | 否 | 用户ID |
| 3 | 商品编号 | int | 11 | 是 | 否 | 商品id |
| 4 | 标题 | varchar | 64 | 否 | 否 | 标题 |
| 5 | 图片 | varchar | 255 | 是 | 否 | 图片 |
| 6 | 单价 | double | - | 是 | 否 | 单价 |
| 7 | 数量 | int | 11 | 是 | 否 | 数量 |
| 8 | 总价 | double | - | 是 | 否 | 总价 |
订单表主要是用来记录用户提交的购买请求与交易状态。主要包括订单编号、买家编号、商品编号、商家编号、总价、订单状态、收件地址等字段。如表4-5所示。
表4-5订单表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 订单编号 | int | 11 | 是 | 是 | 订单ID |
| 2 | 买家编号 | int | 11 | 是 | 否 | 买家ID |
| 3 | 商品编号 | int | 11 | 是 | 否 | 商品ID |
| 4 | 商家编号 | int | 11 | 是 | 否 | 商家ID |
| 5 | 总价 | double | - | 是 | 否 | 总价 |
| 6 | 订单状态 | varchar | 16 | 是 | 否 | 订单状态 |
| 7 | 收件地址 | varchar | 255 | 否 | 否 | 收件地址 |
| 8 | 联系电话 | varchar | 11 | 否 | 否 | 联系人手机 |
| 9 | 创建时间 | timestamp | - | 是 | 否 | 创建时间 |
物流配送表主要是用来跟踪订单的配送进度与配送员信息。主要包括物流配送编号、订单号、配送员编号、配送状态、签收状态等字段。如表4-6所示。
表4-6物流配送表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 物流配送编号 | int | 11 | 是 | 是 | 物流配送ID |
| 2 | 订单号 | varchar | 64 | 否 | 否 | 订单号 |
| 3 | 配送员编号 | int | 11 | 否 | 否 | 配送员ID |
| 4 | 配送状态 | varchar | 64 | 否 | 否 | 配送状态 |
| 5 | 签收状态 | varchar | 64 | 否 | 否 | 签收状态 |
| 6 | 配送详情 | longtext | 4294967295 | 否 | 否 | 配送详情 |
| 7 | 发货日期 | date | - | 否 | 否 | 发货日期 |
| 8 | 创建时间 | datetime | - | 是 | 否 | 创建时间 |
配送用户表主要是用来存储配送人员的身份信息与工作状态。主要包括配送用户编号、用户编号、人员姓名、人员年龄、人员性别等字段。如表4-7所示。
表4-7配送用户表
| 序号 | 字段名 | 类型 | 长度 | 是否非空 | 是否主键 | 备注 |
|---|---|---|---|---|---|---|
| 1 | 配送用户编号 | int | 11 | 是 | 是 | 配送用户ID |
| 2 | 用户编号 | int | 11 | 是 | 否 | 用户ID |
| 3 | 人员姓名 | varchar | 64 | 否 | 否 | 人员姓名 |
| 4 | 人员年龄 | varchar | 64 | 否 | 否 | 人员年龄 |
| 5 | 人员性别 | varchar | 64 | 否 | 否 | 人员性别 |
| 6 | 审核状态 | varchar | 16 | 是 | 否 | 审核状态 |
| 7 | 创建时间 | datetime | - | 是 | 否 | 创建时间 |
第五章 系统实现
5.1 普通用户角色功能实现
5.1.1 网站公告查看功能
网站公告查看功能主要负责向用户展示平台发布的重要通知信息。用户进入系统首页后页面底部区域展示最新三条公告标题。用户点击更多公告链接时系统跳转到公告列表页面。系统从公告表中按创建时间倒序查询所有公告记录，每条公告展示标题与发布时间。用户点击某条公告标题时系统进入详情页面展示完整正文内容。系统在公告详情页底部设置返回列表按钮方便用户继续浏览其他公告。网站公告查看界面如图5-1所示。
图5-1网站公告查看界面
5.1.2 新闻资讯查看功能
新闻资讯查看功能主要负责向用户推送餐饮行业动态与平台活动信息。用户进入新闻资讯页面后系统默认展示最新发布的资讯列表。每条资讯卡片包含标题、封面图片、摘要内容、发布时间四个元素。用户点击资讯卡片时系统跳转到详情页面，正文内容支持图片与文字混合排版。系统在资讯详情页底部展示点赞按钮与收藏按钮，用户点赞后按钮状态变为高亮。新闻资讯查看界面如图5-2所示。
图5-2新闻资讯查看界面
5.1.3 商城中心查看功能
商城中心查看功能主要负责展示所有上架状态的商品信息。用户进入商城中心页面后系统以网格布局展示商品卡片。每个商品卡片包含商品图片、标题、售价、月售数量四个核心信息。系统默认按商品创建时间倒序排列，优先展示新上架商品。用户滚动到页面底部时系统自动加载下一页商品列表。商城中心查看界面如图5-3所示。
图5-3商城中心查看界面
5.1.4 商品分类与搜索功能
商品分类与搜索功能主要负责帮助用户快速定位目标商品。系统在商城中心页面顶部展示横向滚动的分类标签栏，标签内容从商品分类表中读取。用户点击某个分类标签时系统重新请求该分类下的商品集合，高亮显示当前选中分类。用户在搜索框输入关键词后系统在商品标题与描述字段中进行模糊匹配。搜索结果页面展示匹配的商品列表，未匹配到时显示暂无数据的占位提示。商品分类与搜索界面如图5-4所示。
图5-4商品分类与搜索界面
5.1.5 我的购物车查看功能
我的购物车查看功能主要负责展示用户已添加的待结算商品条目。用户点击底部导航栏购物车图标时系统进入购物车页面。系统从购物车表中查询当前用户的所有未结算商品，每个商品展示缩略图、标题、单价、数量、小计金额。页面底部展示商品总数量与订单总金额。用户勾选商品前的复选框时系统实时更新底部合计金额。我的购物车查看界面如图5-5所示。
图5-5我的购物车查看界面
5.1.6 我的订单查看功能
我的订单查看功能主要负责展示用户历史订单记录与当前订单状态。用户进入我的订单页面后系统按订单创建时间倒序展示订单列表。系统将订单按状态分为待付款、待发货、待签收、已完成四个选项卡。每个订单卡片展示订单号、商品图片、商品标题、总金额、订单状态五个信息。用户点击订单卡片时系统进入订单详情页面展示完整信息。我的订单查看界面如图5-6所示。
图5-6我的订单查看界面
5.1.7 订单配送状态查看功能
订单配送状态查看功能主要负责实时展示订单的配送进度。用户在订单详情页面点击查看配送状态按钮时系统进入配送跟踪页面。系统展示配送状态进度条，状态节点包括待取餐、已取餐、配送中、已送达四个阶段。当前所处的状态节点以高亮颜色标注，已完成的状态节点显示对勾图标。系统每三十秒轮询后端接口获取最新配送状态并更新进度条。订单配送状态查看界面如图5-7所示。
图5-7订单配送状态查看界面
5.2 商家用户角色功能实现
5.2.1 商城中心管理功能
商城中心管理功能主要负责商家对本店铺商品的全流程管理。商家进入商城中心管理页面后系统以表格形式展示本店铺所有商品。表格列包含商品图片、商品标题、售价、库存、销量、上架状态六个字段。商家点击新增商品按钮时弹出表单对话框，填写商品基本信息后提交。系统将商品信息写入商品表并将商家编号关联到该商品记录。商家点击编辑按钮时系统加载商品原有数据到表单中，修改后保存时更新对应字段。商城中心管理界面如图5-8所示。
图5-8商城中心管理界面
5.2.2 商品分类管理功能
商品分类管理功能主要负责商家自定义商品归类体系。商家进入商品分类管理页面后系统以树形结构展示现有分类层级。商家点击添加分类按钮时弹出输入框填写分类名称与上级分类。系统对同一父级下的分类名称进行唯一性校验，重复时提示修改。商家点击编辑按钮可修改分类名称，点击删除按钮时系统检查该分类下是否关联商品，存在商品时禁止删除。商品分类管理界面如图5-9所示。
图5-9商品分类管理界面
5.2.3 订单管理功能
订单管理功能主要负责商家对用户订单的处理与跟踪。商家进入订单管理页面后系统展示待处理订单列表，新订单以红色角标标注。每个订单卡片展示订单号、商品清单、用户信息、订单金额、下单时间五项内容。商家点击接单按钮时系统将订单状态从待确认更新为待取餐。商家点击完成制作按钮时系统将订单状态更新为待配送并将订单推送到配送池。商家点击拒绝按钮时需填写拒绝原因，系统将该订单状态更新为已拒绝并通知用户。订单管理界面如图5-10所示。
图5-10订单管理界面
5.2.4 通知消息查看功能
通知消息查看功能主要负责接收系统推送的各类业务提醒。商家登录后消息中心图标显示未读消息数量。商家点击消息中心时系统展示消息列表，消息类型包括新订单提醒、用户催单提醒、退款申请通知。系统将每条消息按发送时间倒序排列，未读消息的标题字体加粗显示。商家点击某条消息后系统自动将该消息标记为已读，加粗样式消失。通知消息查看界面如图5-11所示。
图5-11通知消息查看界面
5.2.5 订单配送管理功能
订单配送管理功能主要负责商家对接配送资源完成订单交付。商家进入配送管理页面后系统展示所有待配送订单列表。每个订单卡片展示收货地址、联系人电话、商品清单三部分信息。商家点击分配配送员按钮时弹出配送员选择列表，系统展示当前可用配送员及其接单数量。商家确认分配后系统将订单信息推送给指定配送员并更新配送状态为待取餐。订单配送管理界面如图5-12所示。
图5-12订单配送管理界面
5.3 配送用户角色功能实现
5.3.1 订单配送功能
订单配送功能主要负责配送员执行从取餐到送达的全流程操作。配送员登录后进入配送任务页面，系统分为待接单、待取餐、配送中、已完成四个选项卡。待接单列表展示所有未被接取的订单，按距离由近到远排序。配送员点击接单按钮时系统将该订单状态锁定并写入配送员编号。配送员到达商家后点击取餐确认按钮，系统要求输入订单号后四位进行核实验证。配送员到达用户地址后点击送达确认按钮，系统更新订单状态为已送达并记录完成时间戳。订单配送界面如图5-13所示。
图5-13订单配送界面
5.4 管理员角色功能实现
5.4.1 数据分析功能
数据分析功能主要负责展示平台运营的核心指标统计结果。管理员进入数据看板页面后系统默认展示今日订单总量、今日交易总额、今日新增用户数三个核心卡片。系统通过折线图展示最近七天的订单数量变化趋势，横轴为日期纵轴为订单数量。系统通过柱状图展示各商家的销售额排行，鼠标悬停在柱子上时显示具体数值。管理员选择月份筛选条件时系统重新请求统计数据并刷新全部图表组件。数据分析界面如图5-14所示。
图5-14数据分析界面
5.4.2 角色管理功能
角色管理功能主要负责配置不同用户组的操作权限范围。管理员进入角色管理页面后系统以表格形式展示所有角色记录，角色包括普通用户、商家用户、配送用户、系统管理员。管理员点击权限分配按钮时弹出权限树对话框，树节点按模块划分包含商品管理、订单管理、用户管理等权限点。管理员勾选某个权限点后系统更新角色权限关联表，该角色下的所有用户即时获得相应操作权限。角色管理界面如图5-15所示。
图5-15角色管理界面
5.4.3 轮播图管理功能
轮播图管理功能主要负责配置首页顶部展示的宣传图片。管理员进入轮播图管理页面后系统以缩略图列表形式展示现有轮播图。每条轮播图记录包含图片预览、标题文字、排序序号、链接地址、启用状态五个字段。管理员点击新增轮播图按钮时上传图片文件并填写跳转链接与排序序号。管理员拖拽排序序号调整轮播图的展示顺序，前端首页按序号从小到大依次展示。轮播图管理界面如图5-16所示。
图5-16轮播图管理界面
5.4.4 网络公告管理功能
网络公告管理功能主要负责发布与维护平台级通知消息。管理员进入公告管理页面后系统分页展示已发布公告列表，每条公告显示标题、发布时间、发布人三个字段。管理员点击新增公告按钮时填写标题与富文本正文内容，提交后系统将公告记录写入公告表并设置创建时间。管理员点击置顶操作时系统将该公告的排序字段置为最大值，该公告出现在公告列表最顶部。管理员点击删除按钮时系统物理删除该公告记录，前端首页同步移除该公告显示。网络公告管理界面如图5-17所示。
图5-17网络公告管理界面
5.4.5 新闻资讯管理功能
新闻资讯管理功能主要负责维护平台对外发布的资讯内容。管理员进入新闻资讯管理页面后系统以列表形式展示所有资讯记录。每条资讯记录包含标题、封面图、摘要、发布时间、点赞数、点击数六个字段。管理员点击编辑按钮时进入富文本编辑器修改资讯正文内容，保存时系统更新资讯表对应字段。管理员设置资讯的推荐状态后该资讯在首页资讯区域置顶展示。新闻资讯管理界面如图5-18所示。
图5-18新闻资讯管理界面
5.4.6 商城中心管理功能
商城中心管理功能主要负责监督平台上所有商家的商品运营情况。管理员进入商城中心管理页面后系统展示全部商家所有商品的汇总列表。表格列包含商家名称、商品标题、售价、库存、销量、上架状态六个字段。管理员点击违规商品的下架按钮时系统将该商品状态强制更新为下架，商家端该商品变为不可见。管理员点击商品详情按钮时查看商品完整信息与历史编辑记录。商城中心管理界面如图5-19所示。
图5-19商城中心管理界面
5.4.7 商品分类管理功能
商品分类管理功能主要负责维护全平台统一的商品归类体系。管理员进入商品分类管理页面后系统以树形表格展示所有分类节点。每个分类节点显示分类名称、分类图标、显示顺序、状态四个字段。管理员添加一级分类时系统将该分类的父级ID设置为0，添加子分类时需选择所属父级分类。管理员调整分类顺序后系统更新所有分类的排序值，用户端分类标签栏按新顺序展示。商品分类管理界面如图5-20所示。
图5-20商品分类管理界面
5.4.8 订单管理功能
订单管理功能主要负责监控全平台所有订单的交易状态。管理员进入订单管理页面后系统支持按订单号、用户手机号、商家名称、订单状态四个条件组合筛选。表格展示订单行包含订单号、用户信息、商家信息、订单金额、状态、下单时间六个维度。管理员点击异常订单的强制完结按钮时系统跳过后续流程直接将订单状态更新为已完成。管理员点击退款审批按钮时查看用户提交的退款凭证并决定通过或驳回。订单管理界面如图5-21所示。
图5-21订单管理界面
5.4.9 订单配送管理功能
订单配送管理功能主要负责监控配送环节的时效与异常情况。管理员进入配送管理页面后系统以时间轴形式展示每个订单的配送节点时间戳。节点包括订单创建时间、商家接单时间、配送员接单时间、取餐时间、送达时间五个关键点。系统自动标记超时订单，当前时间超过预期送达时间时该订单行背景变为浅红色。管理员点击重新分配按钮时系统将超时订单重新放回待接单池并通知原配送员。订单配送管理界面如图5-22所示。
图5-22订单配送管理界面
第六章 系统测试
6.1 测试目的
系统测试主要是对外卖平台的各项业务逻辑是否符合需求规格说明书的要求进行检验。测试活动主要就是对订单全流程数据一致性保证机制进行检验，当并发的时候库存扣减动作是否正确。角色权限隔离功能属于测试范畴之内，保证普通用户不能访问商家端的操作界面。边界条件测试包含购物车里没有商品时的结算情况、搜索框里没输入关键词时的列表展示逻辑等。配送状态机的状态转移路径要包含从待接单到已经送达的全部过程19。业务规则匹配度用正向用例和反向用例两方面的验证来衡量。系统架构的稳定通过持续运行测试来评价内存使用情况。
6.2 测试方法
系统测试采用黑盒测试方法，关注输入与输出之间的映射关系而不关注内部实现细节。功能测试基于用例图编写的测试用例，覆盖每个角色的核心操作路径。集成测试验证订单模块与库存模块之间的数据交互正确性，确保事务回滚机制在异常发生时能够撤销已执行操作。界面测试检查页面元素布局一致性，不同分辨率下组件是否出现错位或遮挡缺陷。异常测试模拟网络请求超时场景，验证系统是否给出明确错误提示而非白屏或崩溃。
6.3 测试用例
（1）商品浏览功能测试如表6-1所示
表6-1商品浏览功能测试表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 分类筛选 | 选择某个商品分类标签 | 只展示该分类下商品 | 符合预期 |
| 2 | 关键词搜索 | 输入商品名称部分文字 | 展示匹配商品列表 | 符合预期 |
| 3 | 空结果处理 | 搜索不存在的商品 | 展示暂无数据提示 | 符合预期 |
（2）购物车管理功能测试如表6-2所示
表6-2购物车管理功能测试表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 添加商品 | 商品详情页点击加入购物车 | 购物车增加该商品 | 符合预期 |
| 2 | 修改数量 | 修改购物车商品数量输入框 | 总价自动更新 | 符合预期 |
| 3 | 删除商品 | 点击商品右侧删除按钮 | 商品从列表移除 | 符合预期 |
（3）订单提交功能测试如表6-3所示
表6-3订单提交功能测试表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 正常提交 | 选择地址后点击提交订单 | 生成订单记录 | 符合预期 |
| 2 | 库存不足 | 提交数量超出库存的订单 | 提示库存不足 | 符合预期 |
| 3 | 无收货地址 | 未选择地址时提交订单 | 提示选择地址 | 符合预期 |
（4）订单确认功能测试如表6-4所示
表6-4订单确认功能测试表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 商家接单 | 商家点击接单按钮 | 订单状态变为待取餐 | 符合预期 |
| 2 | 拒绝订单 | 商家点击拒绝按钮并填写原因 | 订单状态变为已拒绝 | 符合预期 |
| 3 | 重复接单 | 已接单订单再次点接单 | 接口返回操作失败 | 符合预期 |
（5）配送状态更新功能测试如表6-5所示
表6-5配送状态更新功能测试表
| 序号 | 测试功能 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| 1 | 接取订单 | 配送员点击接单 | 配送员ID写入订单表 | 符合预期 |
| 2 | 确认取餐 | 到达商家后点击取餐 | 状态变为配送中 | 符合预期 |
| 3 | 完成配送 | 送达后点击确认送达 | 状态变为已签收 | 符合预期 |
测试结论
经过上述测试用例的执行验证，系统核心功能均达到预期目标。五个核心测试模块涵盖商品浏览、购物车操作、订单流转、商家接单、配送更新等主要业务链路。所有测试用例的实际结果与预期结果保持一致，未发现功能缺陷或数据不一致问题。边界条件测试结果显示系统能够正确处理库存不足、地址缺失等异常场景。配送状态机的状态迁移严格按照设计路径执行，未出现非法状态跳转。系统整体功能完整性与稳定性满足本科毕业设计验收标准。