第一章 相关技术介绍1.1 Spring Boot框架Spring Boot是一个基于Spring框架的轻量级、开箱即用的Java企业级应用开发框架[10]。它显著简化了基于Spring的应用程序的初始搭建和开发过程通过约定大于配置的理念减少了大量繁琐的XML配置工作。Spring Boot内置了诸如Tomcat、Jetty等Web服务器支持独立运行开发者只需通过简单的依赖配置就能快速启动一个可独立部署的Web服务[11]。其自动配置机制能够根据项目引入的依赖自动装配所需的Spring组件为后端业务逻辑的实现提供了高效的环境。框架对MyBatis等持久层框架有良好的集成支持使得数据库操作变得简便。本校园点餐系统的后端服务完全采用Spring Boot构建。它负责处理来自微信小程序端的业务请求承担了用户认证、订单处理、支付状态管理、菜品数据维护、商家审核以及后台数据统计分析等一系列核心业务逻辑[12]。Spring Boot的模块化特性使得系统的业务层、控制层和数据访问层结构清晰。在数据处理方面通过集成MyBatis框架Spring Boot实现了对MySQL数据库的便捷访问。整个后端服务最终被封装成一个可独立运行的JAR包其内置的容器特性简化了部署流程为前端提供了稳定可靠的API接口支持[13]。1.2 微信小程序开发框架微信小程序是一种无需下载安装即可在微信平台上使用的应用形态。其开发框架基于MINA架构提供了一套特有的视图层描述语言WXML和WXSS以及基于JavaScript的逻辑层框架。视图层与逻辑层分离的设计实现了数据与界面的绑定数据变更能够实时驱动视图更新[14]。小程序框架封装了丰富的原生API包括网络请求、本地存储、媒体控制、位置服务等使得开发者能够便捷地调用设备能力。其组件化的开发方式有利于代码复用和项目管理提升了开发效率。在校园点餐系统的用户侧微信小程序框架用于构建面向学生的点餐客户端。框架的组件系统为构建菜品列表、购物车和订单详情页面提供了基础视图元素。WXML与WXSS的结合实现了用户界面在微信环境中的原生渲染效果保证了良好的交互体验[15]。小程序的JavaScript逻辑层处理用户的点击事件如前端的菜品搜索、购物车管理操作并通过wx.requestAPI将数据请求发送至Spring Boot后端服务器。小程序框架的本地存储API用于临时保存用户的登录状态和购物车信息。由于微信平台庞大的用户基础选择小程序框架使得用户无需安装新应用就能访问点餐服务降低了使用门槛。1.3 MySQL数据库MySQL是一个应用广泛的关系型数据库管理系统它采用SQL语言进行数据管理支持多线程、多用户并发访问。MySQL以其开源、体积小、速度快、成本低的特性著称支持事务处理、视图、存储过程等功能能够满足中小型Web应用的数据存储需求[16]。其ACID事务特性确保了在用户支付、库存扣减等并发场景下的数据一致性和完整性。作为数据库持久化层的核心MySQL通过建立数据表之间的关联来存储和组织系统的结构化数据为应用程序提供了稳定、高效的数据存取服务。本系统使用MySQL数据库存储所有的业务数据。数据库的设计围绕点餐业务的核心实体展开主要的数据表包括用户信息表、商家信息表、菜品信息表、订单主表和订单明细表、评价信息表等。用户通过小程序提交的订单详情、商家上架的菜品信息与图片路径、用户的支付状态以及历史评价内容都持久化存储在MySQL中[17]。在数据处理层面复杂的业务查询例如商家统计页面中特定时间段内菜品销售金额和数量的聚合计算均依赖MySQL的SQL查询语句来完成。数据库的索引优化提升了在菜品信息管理和订单信息管理等模块中进行大数据量查询的响应速度。其可靠的事务机制保障了用户下单时从库存扣减到订单生成的整个数据操作序列的原子性。1.4 前后端分离架构前后端分离架构是一种现代Web应用的设计范式。在这种架构下前端应用与后端服务是相互独立的两个项目它们通过定义清晰的接口进行通信。后端专注于业务逻辑的实现、数据持久化和API接口的提供通常以RESTful API的形式对外暴露服务[18]。前端则专注于数据的呈现、用户交互和用户体验通过HTTP协议调用后端API获取或提交数据。这种分离允许前后端技术选型独立并行开发并通过接口契约进行协作。校园点餐系统采用前后端分离架构进行设计与开发。后端使用Spring Boot构建部署在一台独立的服务器上它不直接生成任何HTML页面而是提供一套完整的JSON格式API这些API覆盖了用户登录、菜品查询、下单支付、商家管理和后台数据分析等所有功能。前端则基于微信小程序框架独立开发运行在用户的微信客户端中[19]。小程序通过调用后端的RESTful API来获取最新的菜品列表、提交新的订单数据或请求生成统计图表的数据。前后端之间的所有交互数据均遵循JSON格式确保了数据传输的轻量化和标准化。这种架构模式使得后端API可以被不同形态的客户端如小程序、Web管理端复用系统的可扩展性和维护性得到了增强。第二章 系统分析2.1 可行性分析2.1.1 技术可行性本系统在技术上有着成熟可靠的应用基础。系统使用浏览器/服务器结构以及前后端分离的设计方式服务端使用了Java语言配合Spring Boot框架来编写程序此技术方案在开发RESTful API与响应并发请求上有大量的应用实例在线订餐与管理订单的服务可以有保障地稳定运行。前端程序是在微信官方提供的小程序本地开发环境中进行编写小程序平台所提供的API接口与组件库为开发用户界面提供了原生的支持。所使用的MySQL数据库为一款关系型数据库软件其对事务的支持保证了订单、支付记录的数据一致性。开发软件过程中所需用到的IDE、版本控制系统与测试软件均为成熟的开源项目整个技术方案选择是完整可行的可以满足系统从研发直至上线的全过程需求。2.1.2 社会可行性该系统的开发顺应了目前校园生活服务的数字化潮流有较好的社会认可度。系统的服务人群是针对在校大学生和老师而这个群体对于移动端互联软件的接纳程度高用小程序订餐符合他们的生活习惯。系统致力于解决学校食堂高峰时期排长队拥挤嘈杂信息公开程度低的问题方便快捷地点餐付款的方式可以有效满足师生的需求。平台型模式连接了点餐者和食堂经营者以及管理者三方主体实现了信息互通和服务协作有利于打造一个更加有效的院校食堂服务体系生态。系统使用的场景具体明确功能围绕主要就餐环节展开有实用效益和社会推广价值。2.1.3 经济可行性此系统研发在经济上是合理的。开发主要是对人力的使用其中包括了服务端程序、微端程序以及数据库设计等方面的编写码工作人员工资占项目开支的比例最大。在软件上使用的开发技术栈各主要框架和工具都是开源免费的软件没有需要支付许可证的金钱开销。系统安装运行基于云计算平台的基础硬件设施之上以租用的方式进行收费前期投入资金少并且后期随着使用者数量增加的成本可以灵活伸缩。该系统的应用预计会提高学校食堂经营管理的工作效率减少用人成本长远来看它所带来的收益可以弥补甚至高于前期投入和以后的支出。2.2 功能需求分析UML用例图是一个可视化工具它用来描述一个系统的功能性需求显示系统与外界参与者之间的联系以此来确定系统的职责。用例图画出了由系统所能做的活动组成的用例以及系统所涉及的各种人员及其它系统扮演的角色。它可以被应用于在分析以及设计阶段使得开发者的团队和客户对系统所拥有的功能达成一致确保了所建立系统包含所有要求的功能并且是没有多余部分的功能。以可视化的图形方式UML用例图给出了系统所提供的功能和所涉及的角色的直观对应关系。我们将在此篇文章中对系统依照角色来进行划分来进行需求方面的研究。普通用户能够在菜品中心进行搜索菜品、浏览菜品信息、把菜品添加到购物车或者直接立即购买的操作。当客户选择立即购买或者从购物车下单的时候能够进行支付过程。在客户个人的订单界面可以看到所有订单取消尚未完成订单对未付款订单进行支付确认收获已完成配送订单删除历史订单。客户在完成订单收货之后可以对自己所购订单菜品进行评论。普通用户的用例图如下图3-1所示。图3-1普通用户用例图商家能浏览首页的销售统计数据。商家可对所收到的顾客评论进行检索及回复。商家可以检索菜品销量排名并且能查看详情。商家对菜品的信息进行增加、删除、修改以及查找的操作在编辑菜品的过程中必须上传照片并提交按钮。商家检索以及发送订单的操作。商家的角色用例图就是下图3-2。图3-2商家用例图管理员能够浏览平台首页用户的统计情况和商品销售统计。管理员对商户信息的增加、删除、修改、查询以及审核操作权限。管理员能浏览平台内全部订单的信息查询、批量删除和查看详情的操作权限。管理员对全部菜品信息可浏览查询、审核、查看评论的操作权限。管理员对于用户反馈的评论投诉有查询和删除操作权限。管理员的角色用例图如图3-3所示图3-3管理员用例图第三章 系统设计3.1 系统架构设计此项目为典型的模块化、前/后台相分离的设计结构以此达成高内聚低耦合的编码方式如图4-1所示为系统总体架构。当客户在微信小程序前台界面上产生互动行为时例如浏览餐品、下单支付等行为前台运用wxml以及wxss编写页面展示视图并借助微信小程序自带API发起http网络请求将用户的操作行为以json形式提交到后台服务器。而后台使用基于Springboot框架搭建的RESTfulapi服务其在接受前台请求之后会交由dispatcherServlet负责路径的转发具体的业务执行过程是在spring容器内的service层组件中展开比如下订单所涉及的创建订单、库存数减少或者各类统计工作等业务接着service层调用mapper层组件连接访问mysql数据库在其中对客户信息、菜品信息、订单日志和评价信息等主要业务数据实施存储与检索。同时数据库的设计符合关系数据库范式并通过事务处理来保障数据的一致性。整个体系结构明了分工明确保证了程序后期的可维护性并提升了数据查询效率。图4-1系统架构图3.2 系统结构功能设计本系统依托于微信小程序平台打造一个服务于大学校园餐饮场景的线上的订餐平台。系统的功能设计是以三种典型的角色为切入点普通用户商家以及管理员。其中针对普通用户的客户端着重关注消费过程主要的功能模块就是菜品中心和我的订单实现了浏览、下单选购、支付、售后/评论完整的闭环。而面向商家的商家端着重关注其对于自身的经营店铺的运营管理提供包括首页数据面板、评价投诉管理、菜品排行榜管理、菜品信息管理和订单信息管理等一系类功能来支持商家日常的店铺经营管理的过程。最后面向管理员的后端主要是对整个平台进行全局监控审核的功能提供平台监控首页、商家信息管理、订单信息管理、菜品信息管理和评价投诉管理等一系列的功能模块保障着整个平台的良好秩序和安全可靠的数据来源。系统的功能架构图如下图4-2所示。图4-2系统功能结构图3.3 系统流程设计3.3.1 普通用户下单支付流程设计顾客从餐品中心启动在线进行立刻购买或者放入购物车。系统检测订单详情之后指引客户进行付款步骤顾客同意付款即调起支付插口成功之后系统更新数据库中订单状态并完成流程。如果顾客拒绝支付则流程直接结束。普通消费者下单支付流程图如下图4-3所示图4-3普通用户下单支付流程图3.3.2 商家菜品上架流程设计商户在菜品管理模块中选择增加新菜品跳转到编辑页面录入相关信息并上传照片。提交之后系统判定提交成功则菜品处于等待审核的状态判定提交失败则退回上传照片这一步骤。商家也可以在编辑的时候对表单进行重置再次填报。商家菜品上架流程图如下图4-4所示。图4-4商家菜品上架流程图3.3.3 用户订单评价流程设计顾客在“我的订单”里查询已经完成的订单,系统判定订单状态为已签收方可对用户进行评价操作。客户在评价页面决定是否发表评论,提交后系统保存评价信息并结束流程,用户也可以取消评价直接结束流程。客户订单评价流程图如下图4-5所示。图4-5用户订单评价流程图3.3.4 商家订单处理流程设计商户登录之后浏览等待处理的订单列表。对于每一个新订单商户需要检查其所下的订单的信息有无不正确的地方。订单信息无误即进行相应的发货操作并将订单状态予以更新若发现订单信息出现错误则应及时联系客户进行确认沟通确认后再回到查询环节重新开始上述步骤。商家端订单处理流程如图4-6所示。图4-6商家订单处理流程图3.3.5 管理员审核商家入驻流程设计管理员查看所有的待审核商家入驻申请。针对每一个申请管理员需要审核申请者上传的文件是否完整、达标。达标则审核通过并为其开放后台操作权限不达标则驳回并且提醒商户上传相关文件。处理完后流程结束。管理员审核商家入驻流程图如图4-7所示。图4-7管理员审核商家入驻流程图3.4 数据库设计而在数据库的设计中ER图的设计有利于把概念结构转换到实际的数据库结构在这一步我们需要定义出每一个数据表的字段类型以及约束条件还有就是表间的联系从而为我们进行物理结构设计做好铺垫。之后我们还会进一步研究并优化对于数据存储的方式方法以便于使我们的系统保持高效率并且易于扩展[20]。3.4.1 E-R图设计E-R图即实体—联系图它是进行数据库结构建模的一个可视化工具用来表示实体及其所具有的属性、实体之间的相互关系等等。它以图形的方式来方便地对数据库的结构进行研究和规划制定确定这些数据之间的联系。利于我们以后对其进行数据库的编制与维护工作。下边将会给出系统的总体E-R图及相关实体的属性图。系统全局E-R图如图4-8所示。图4-8系统E-R图用户账号实体主要由用户账号id头像urlemailemail认证等组成。具体实体属性图如下图4-9所示。图4-9用户账户实体属性图普通用户实体主要由普通用户id联系电话建立用户id建立时间等组成。实体属性图如下图4-10所示。图4-10普通用户实体属性图商户客户体主要由商户用户ID、商户性别、商户名称、联系电话等构成。实体属性图如下图4-11所示。图4-11商家用户实体属性图商品信息实体主要由商品信息id正文创建时间自定义字段等组成。实体属性图如下图4-12所示图4-12商品信息实体属性图商品品类实体主要是由商品品类Id、上层分类Id、商品类别名、描述等组成。实体属性图如图4-13所示。图4-13商品类型实体属性图购物车实体主要由购物车id标题图片用户id组成等构成。属性图如下所示。如图4-14图4-14购物车实体属性图订单实体主要由订单id、订单编号、商品id、价格等构成。实体属性图如下图4-15所示。图4-15订单实体属性图菜品中心实体主要由菜品中心id、商户用户、审核状态、标题等组成。实体属性图如下图4-16所示。图4-16菜品中心实体属性图评论投诉主体主要是由评价投诉ID、创建者用户ID、建立的时间、反馈的内容等构成。实体属性图如图4-17所示。图4-17评价投诉实体属性图物流配送实体主要由物流配送id、订单编号、商品品名、购买数量等。实体属性如下图4-18所示。图4-18物流配送实体属性图3.4.2 数据库表设计数据库表格的设计是针对具体业务来明确数据库表的组成以及各字段类型以及他们之间的相互联系。规范化设计可以确保数据完整性和一致性和性能并且防止重复数据也使得将来对数据检索及储存还有维护有较为明晰的基础架构[21]。下面是系统中的数据库表格设计示例。用户账号表是用来存放用户账号的信息。主要包含用户账号id头像路径邮箱别名等等这些属性。如表4-1所示。表4-1用户账户表序号字段名类型长度是否非空是否主键备注1用户账户idint11是是用户ID2头像地址varchar255否否头像地址3邮箱varchar64否否邮箱4昵称varchar16否否昵称普通用户表主要负责存储用户的普通用户信息。主要有普通用户id、联系号码、建立时间、验证情况等字段。见表4-2。表4-2普通用户表序号字段名类型长度是否非空是否主键备注1普通用户idint11是是普通用户ID2联系号码varchar16否否联系号码3创建时间datetime-是否创建时间4审核状态varchar16是否审核状态商户用户表主要用于保存商户的用户信息主要包含商户用户id、商户姓名、联系电话、店铺名等多个属性如表4-3所示。表4-3商家用户表序号字段名类型长度是否非空是否主键备注1商家用户idint11是是商家用户ID2商家姓名varchar64是否商家姓名3联系号码varchar16是是联系号码4店铺名称varchar64否否店铺名称商品信息表主要的作用是储存商品具体内容信息。包含的商品信息有商品信息id正文商品库存卖价等列。如下表4-4所示。表4-4商品信息表序号字段名类型长度是否非空是否主键备注1商品信息idmediumint11是是产品ID2正文longtext255否否正文3商品库存int11是否商品库存4卖价double-是否卖价商品种类表主要负责存储商品的种类信息。主要有商品类型id、商品名称、描述、图标等字段。如表4-5所示。表4-5商品类型表序号字段名类型长度是否非空是否主键备注1商品类型idint11是是商品分类ID2商品名称varchar255否否商品名称3描述varchar255否否描述4图标varchar255否否图标购物车表主要用于保存用户在购物车内的商品信息。主要有购物车id标题图片用户id这些字段。如下表4-6所示。表4-6购物车表序号字段名类型长度是否非空是否主键备注1购物车idint11是是购物车ID2标题varchar64否否标题3图片varchar255是否图片4用户idint11是否用户ID订单表主要用于保存订单相关信息。主要包含订单id订单编号商品id单价等列。如表4-7所示。表4-7订单表序号字段名类型长度是否非空是否主键备注1订单idint11是是订单ID2订单编号varchar64否否订单号3商品idmediumint11是是商品ID4价格double-是否价格菜谱中心表主要用于保存商家菜品类目。主要有菜谱中心ID、商铺用户、审核状态、标题等字段组成。如表4-8所示。表4-8菜品中心表序号字段名类型长度是否非空是否主键备注1菜品中心idint11是是菜品中心ID2商家用户int11否否商家用户3审核状态varchar16是否审核状态4标题varchar125否否标题评价投诉表主要用于存储投诉和评价的信息。主要由评价投诉id、创建用户id、创建时间、反馈内容等属性组成。如表4-9所示。表4-9评价投诉表序号字段名类型长度是否非空是否主键备注1评价投诉idint11是是评价投诉ID2创建用户idint11是否创建用户ID3创建时间datetime-是否创建时间4反馈内容text255否否反馈内容物流配送表主要为了存放订单的物流配送的信息。包含物流配送id订单编号品名购买数量这些属性。如表410所示。表4-10物流配送表序号字段名类型长度是否非空是否主键备注1物流配送idint11是是物流配送ID2订单号varchar64否否订单号3商品名称varchar64否否商品名称4购买数量varchar64否否购买数量第四章 系统实现4.1 普通用户功能实现4.1.1 菜品中心浏览与下单功能实现该模块供用户查找与选购菜品。用户输入关键词对菜品库进行检索点击具体菜品查看其详情与价格。选择中意的菜品后用户可将其加入购物车或直接下单购买。系统将选中的菜品信息与价格汇总形成待支付订单完成从浏览到购物决策的核心闭环。菜品中心浏览与下单界面如图5-1所示。图5-1菜品中心浏览与下单界面4.1.2 订单管理与支付功能实现消费者在这个模块处理自己的下单事项。系统展示出消费者的历次订单及所处状态。消费者可对自己未完成的订单进行取消的动作、为等待付款订单发起线上支付行为。当收到货品之后由消费者签字验收之后才可在系统内允许消费者对自己已结束的订单写下评论。关于订单管理和支付页面如下图5-2所示图5-2订单管理与支付界面4.2 商家功能实现4.2.1 销售数据统计功能实现商户在首页数据看板浏览经营概况。此板块对区间内商品销售总金额、销售总数量进行即时性的运算并以图表的方式展现经营走向数据是经营者评判销售情况以及制定经营方案的数量基础。销售数据统计页面如下图5-3所示。图5-3销售数据统计界面4.2.2 互动与评价管理功能实现商家在这一板块回复顾客反馈。系统汇集了所有顾客对店铺菜品的评论商家可依次查看并对特定的评论内容进行答复与顾客交流。这是商家进行服务管理、提高顾客体验度的一个重要手段。互动及点评管理页面如下图5-4所示。图5-4互动与评价管理界面4.2.3 菜品与订单运营管理功能实现这是商业端的核心业务部分。经营者可以管理菜肴数据上传新增加的菜肴以及编辑已存在菜品种类的相关描述及图片。另一方面商户可以在收到用户下单之后进行查询并在准备好餐品后将订单状态改为已经发货来结束此次订单。菜品类别以及订单运营管理页面如下图所示图5-5菜品与订单运营管理界面4.3 管理员功能实现4.3.1 平台数据总览功能实现管理员首页概览平台整体核心数据。统计数据主要包括平台现有注册用户数及活跃度情况分布、每个商户的商品销售额和销售总量汇总信息等。此面板作为管理者对平台总体运行情况进行判断的数据依据来源之一。平台数据分析页面如下图5-6所示。图5-6平台数据总览界面4.3.2 商家入驻审核与管理功能实现管理员对平台商户进行入驻审核以及日常管理。新的商户提出入驻请求后管理员核实商户的相关资格信息并审批是否准入。管理员对所有已经入驻的商户信息都进行管理维护以保证入驻商户信息真实有效、符合要求。商户入驻审核及管理页面如下图5-7所示。图5-7商家入驻审核与管理界面4.3.3 订单与菜品内容监管功能实现管理者承担着管理平台内容监督的角色。管理者可以浏览到平台上全部订单的信息并对其中一些存在异常或者违反规定的订单做批量处理删除。并且管理者会对商户发布上线的所有餐品做内容检查以保证其合规性。订单及菜品内容监督管理界面如图5-8所示。图5-8订单与菜品内容监管界面4.3.4 用户评价监督功能实现管理员监管平台产生的一切用户评分内容。此功能提供了查询全部点评的一个接口管理员通过对点评进行浏览维持社区环境针对不合规则的点评作出删帖处理保证点评空间的真实性。用户评价监管页面如下图5-9所示。图5-9用户评价监督界面完整项目源码、论文参考、答辩 PPT 和演示视频已整理关注博主后私信领取