第一章 绪论
1.1 研究背景和意义
近些年来，由于国内酒店行业持续扩张以及服务模式的多样化发展，信息化建设已经成为提高企业竞争力的主要手段1。传统的酒店会员点餐方式大多采用人工记录、线下沟通的方式，会造成订单信息传递延误、数据统计不及时、管理效率低下的问题。大量的分散信息流很容易造成误单、漏单等问题，严重损害客户的体验。随着客户数量和需求服务标准的不断增加，手工操作已经不能达到高效、精确的要求了。互联网以及移动技术飞速发展促使餐饮服务智能化转型，自动化、数字化管理成了业界普遍推崇的发展趋向2。现代化酒店急需具有适应线上线下的融合趋势的点餐管理系统，从而改善会员服务流程、提高运营效率、提高决策水平。基于Spring Boot的酒店会员点餐系统应运而生，是满足市场需要、实现信息管理科学化的一种方式。
系统开发应用促使酒店点餐管理方式由原来的传统的手工操作转变为智能化的信息化。采用Spring Boot技术架构可以实现订单、会员、菜品等数据之间的快速交互和精确处理，明显加快了订单响应速度，降低了人工操作失误率，很好地改善了顾客的用餐体验。系统给酒店创建了统一的数据管理平台，为酒店的日常经营决策提供数据支撑，促使管理流程趋于规范。智能化的点餐系统可以提高酒店的整体服务水平，促进行业发展与技术创新，对于提高客户的满意度和忠诚度起到积极作用。该系统有较好的扩展性、适应性，可以满足不同类型的酒店个性化的需求，也符合社会对智慧服务、智能管理的要求，有重要的实际应用价值和社会意义。
1.2 国内外研究现状
1.2.1 国内研究现状
国内酒店数字化服务的研究主要是对会员运营和在线点餐业务的耦合展开的，研究的重点也从以前的功能实现转变成稳定性、可扩展性和一致性控制。技术路线从单体应用走向分层架构、服务化架构，后端主要使用Spring Boot作为主要的开发框架来提高开发效率和控制交付。业务侧从简单的前台点餐和后厨出品的单一联动发展到现在的会员积分、权益核销、优惠叠加、营销活动联动等多重场景的复合联动。数据层由简单的记录变成订单行为和会员画像的不断积累，用实时同步、事务边界、多端一致体验为主要的工程化方法体系。
酒店会员点餐应用在国内的落地起点主要是通过浏览器访问和收银终端录入来实现，业务逻辑主要集中在单体代码上，订单生成、菜品管理、桌台状态、后厨打印形成了闭环，会员体系大多停留在手机号绑定和基本折扣规则上，跨门店共享和权益核销的覆盖度较低。移动互联网普及使点餐入口向小程序和移动端集中，扫码点餐、免排队取餐造成并发访问增加，系统要针对高峰时段的连接管理、缓存策略、异步处理机制进行优化，后台开始使用Spring Boot构建分层架构来降低耦合度、加快迭代速度3。业务扩展造成价格体系和促销组合更加复杂，满减、会员价、套餐拆分和加料规则需要价格计算具有可测试性和可追溯性，订单状态机和支付回调处理成为稳定性的重要环节，面向幂等控制和补偿机制的工程实践得到加强4。门店运营开始重视会员生命周期管理，积分获取、积分抵扣、等级成长、权益包发放和核销要和订单事件保持一致，数据一致性从单库事务扩展到分布式事务边界管理，以事件驱动的订单消息和会员账户变更为主流方案5。多门店、连锁化场景提高了数据隔离和权限模型的要求，商品主数据、库存、后厨工位配置等需要支持门店维度的差异，系统在权限体系、租户隔离、配置中心等方面形成了可以复用的组件，配合接口网关、统一鉴权来提高访问的安全性和治理能力6。数据驱动运营使系统趋于综合服务形态，点餐行为和会员活跃度用来创建偏好标签和复购预估，推荐和营销触达同订单链路慢慢融合起来，依靠日志收集、埋点治理以及报表体系的塑造加强了经营分析水平，系统越发重视可观测性、灰度发布以及弹性扩缩容这些工程指标7。
1.2.2 国外研究现状
国外有关研究更加重视面向服务的体系化设计以及业务生态的协同，技术路线一般会使用云原生架构、领域驱动设计和事件流处理来达到多地域部署和高可用的目的。主要研究支付链路合规、订单编排、履约可追踪性，会员体系、营销自动化用标准化接口和第三方生态集成。应用模式是以多端统一体验为方向，线上点餐、到店自助、外卖聚合和门店运营工具在一个业务平台上相互配合。工程实践中SpringBoot、微服务框架常被用于创建可以组合的服务单元来降低各个场景的交付成本。
国外酒店和餐饮点餐系统形态演进具有很强的平台化特点，早期以网页端和门店终端协同完成下单、支付、出品，接口设计越来越标准化，并且与支付网关、税务计算、发票服务形成了稳定的集成，订单数据也开始向多渠道汇集并统一对账8。移动端的普及使自助点餐、无接触服务成了常态，系统用统一的身份和会员账户实现跨门店消费记录、权益的同步，服务端大多使用云托管和容器化部署，依靠弹性伸缩来吸收高峰流量，保持低延迟体验9。数据驱动能力在国外的落地更注重实时性以及可解释性，订单事件、支付事件和履约事件经由消息中间件进入到流处理链路当中，从而产生实时的监控以及异常的检测，会员画像和优惠策略借助规则引擎实现联动投放，并且能够进行回溯评价10。跨渠道经营使平台和外卖聚合、预订系统、客户关系管理工具深度融合，统一菜单和价格策略要适应多渠道的差异，系统对多语言、多币种、时区处理有成熟的机制，依靠API治理和契约测试来降低外部依赖带来的变更风险11。工程上讲求端到端的可观测性以及合规审计，日志、链路追踪和指标告警构成一个闭环系统，数据最小化和访问控制贯穿会员数据的全部生命周期，零信任以及密钥管理的安全体系加上业务连续性方案一起支持规模化运行12。
1.3 主要研究内容
本文主要研究怎样提高酒店会员点餐服务的信息化水平，创建一个基于Spring Boot和Vue.js的酒店会员点餐系统，主要实现了前后端分离架构下多角色协同点餐、订桌、订单管理等主要业务。研究工作从实际酒店运营需求入手，对普通用户的点餐、预订、评论管理、购买等各个环节，管理员的各类角色、员工、餐桌、订单、美食管理等功能需求进行综合分析，为系统的设计打下基础。在此基础上，使用Spring Boot做为后端开发框架，用Vue.js搭建前端界面，数据持久层使用MySQL数据库，系统的架构符合RESTful接口规范，保证高可维护性以及可扩展性。设计时就对权限控制、业务流程梳理、数据一致性等重要问题进行了研究，并且根据模块化思想把系统结构细化为用户端和管理端两个子系统。研发阶段主要针对核心功能模块进行开发实现，给出高并发环境下数据交互、安全性的技术方案。测试环节主要是对系统的功能是否完整、交互是否稳定进行检验，保证系统在实际运行环境下可以使用。本文主要针对点餐相关功能进行实现，并没有涉及到酒店整体运营的财务、客房管理等模块。期望成果为一个可以实现线上点餐、餐桌预定和后台管理等各项功能的可以部署的系统，从而提高酒店的服务效率以及会员的体验。整体方法路径以需求驱动开发为线索，采用主流开源技术加分层架构的方式，努力做到系统性能好、易使用，在实现酒店点餐业务数字化转型的过程中，整体方法路径把酒店点餐业务分为用户端、管理员端和服务端三部分，每个模块分别进行独立的开发工作。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot框架以约定优于配置为组织原则，把依赖管理、自动装配、运行环境集成到统一的工程结构里，使后端服务可以围绕业务对象形成清晰的分层边界。系统在处理美食点餐和订单管理等主要请求的时候，要在控制层、服务层和持久层之间维持稳定的调用路径，Spring Boot依靠Starter机制来缩减组件装配的成本，削减环境不同造成的部署偏差，加强开发阶段的可重复性。其内部的嵌入式容器以及配置体系使得接口服务可以以统一的方式进行启动和治理，13所采用的自动配置思想在工程实施时表现为对模块组合的更加可控以及手动接线减少。
对于并发访问来说，Spring Boot和Spring MVC请求处理模型可以把参数绑定、校验和异常处理融合在一起，防止业务代码被太多样板逻辑所覆盖。以Bean的生命周期和依赖注入为机制，可以将会员等级管理等规则变成可以测试的服务单元。配合AOP的横切能力，权限控制、日志追踪、事务边界可以与业务实现的耦合度低，接口演进时容易进行维护，也可以更易对关键路径进行性能观察和问题定位。
2.2 Vue.js框架
Vue.js框架依靠响应式数据绑定和组件化组织方式创建前端界面，利用虚拟DOM和依赖追踪机制把状态改变转译成最简小的视图更新，前端交互的繁杂程度被限定在可以被复用的组件范围之内。系统美食点餐页面和评论管理界面经常要处理列表渲染、筛选条件和表单输入等交互状态，Vue.js双向绑定和计算属性可以使得界面状态和业务数据保持一致，避免由于手动同步而产生的错误。就单页应用的路由和状态管理来说，14所阐述的组件驱动思想可以使界面根据业务场景拆分重组，从而提高页面交互的一致性和可扩展性。
在前后端分离的接口调用模式下，Vue.js和异步请求库一起可以将数据获取、加载态和错误态都放在同一个交互反馈链路上，不会造成页面逻辑分散。它的模板语法、指令系统在保证可读性的基础上可以实现条件渲染、事件响应等功能，使餐桌预订等流程页面用较少的代码实现校验提示和步骤流转。借助搭建的工具链对资源实施打包，并按照需要动态加载，可以对首屏渲染及路由切换体验加以调节，在控制范围内改进多终端访问的稳定性。
2.3 MySQL数据库
MySQL数据库用关系模型来表示实体之间的约束关系，依靠成熟的事务机制和索引体系支持高频读写场景下的数据一致性。系统需要对用户的、会员等级的、订单的、预订的这些结构化数据进行持久化存储，表结构的设计依靠主键、外键、唯一约束来体现业务规则，事务隔离级别用来控制并发过程中的可见性以及更新冲突。对于订单管理这样的关键写入路径，InnoDB的行级锁以及崩溃恢复的能力可以减少由于异常中断造成的数据风险，15中关于事务和锁机制的论述给并发控制策略提供了一个可以落地的技术支撑。查询侧使用联合索引和覆盖索引来减少回表次数，使得列表检索和条件筛选都可以达到一个可以接受的响应时间。
当数据量增大或者访问方式发生变化的时候，MySQL的执行计划以及慢查询分析可以找出热点SQL，从而利用索引的调整和语句的重写来提高性能。对评论管理等追加写入较多的表，用合理化的字段类型、规范化的设计来减少存储膨胀、提高缓存命中率。采用配合备份和主从复制的策略来规划数据可用性和恢复能力，从而保证系统的迭代过程中有稳定的数据库底座。
2.4 前后端分离框架
前后端分离框架用接口契约为中心来组织协作边界，把界面渲染和业务服务解耦，形成独立演进的交付链路。后端用REST风格接口对外提供资源访问能力，前端用统一的请求层消费接口并驱动界面状态，接口文档和参数校验是联调阶段的主要约束。系统对于承载美食点餐以及餐桌预定这类跨页面操作时，采用分离式的架构，这样可以保证页面的改动不会影响到服务端的渲染逻辑，而且服务端也可以把注意力放在领域规则、权限判定和数据一致性这些事情上。16对于分离式Web架构的描述主要讲到了接口稳定性和团队并行效率，工程实践上用版本化的接口、统一错误码和可追踪的请求链路来体现。
分离式部署形态需要对跨域访问、鉴权和会话保持进行统一的设计，一般用Token或者会话标识来传递身份信息，配合网关或者拦截器来进行权限控制和审计。接口层的幂等性设计和限流策略可以减少重复提交给订单管理造成的影响，日志、链路追踪让问题更容易定位到服务调用、数据访问这些环节上。利用环境配置隔离、自动化构建发布的方式，前端静态资源和后端服务可以独立扩容或者回滚，从而使得系统在访问量波动的时候保持更好的交付节奏以及运行状态。
第三章 系统需求分析
3.1 可行性分析
3.1.1 技术可行性
本系统使用目前主流的开发技术，前后端分离架构可以有效地提高开发的灵活性以及运行的效率。所选框架稳定、扩展性强，数据库选取满足高并发、数据一致性的要求。整体结构合理、开发环境成熟，有利于平台在用户量增加、业务功能扩展时保持良好的运行状态。
3.1.2 操作可行性
系统界面设计以简洁直观为原则，功能分类清楚，普通用户和管理员都可以较快地掌握主要的操作流程。用户在完成点餐、预订、评价等一系列操作的时候所经过的步骤被清晰地展示出来，减少了由于不必要的页面跳转而造成的影响，提升了操作的速度。整体菜单层次设置合理，交互逻辑符合餐饮管理业务实际，可以减少新用户的使用难度，使系统能够在实际环境中得到广泛的应用。
3.1.3 经济可行性
本系统开发及运行所用的技术、硬件资源较为常见，可以较好地控制开发周期和项目成本。开发团队规模小、项目管理有条理，节省人力和时间。后期维护工作量小，日常升级、优化和数据管理的开销较小。因此系统投入和预期收益相匹配才能达到高校科研应用和中小餐饮企业信息化建设的经济性要求。
3.2 功能需求分析
3.2.1 普通用户功能
普通用户可以在系统中浏览美食信息，发起美食点餐操作，选择菜品规格和数量之后提交购买请求，完成支付并产生订单记录。用户可以对餐桌进行预定，输入到店时间、人数和联系方式后查看预订情况并取消预订。用户可以在我的订单里查看订单详情、支付状态以及配送或者出餐进度，发起退订或者确认收货等操作。用户可以在评论管理里对已经完成的订单进行评价，填写文字和评分，查看历史评论并进行删除。普通用户角色的用例图如图3-1所示。
图3-1普通用户用例图
3.2.2 管理员功能
管理员对系统中的角色进行维护，设置不同的岗位权限范围和账号角色。管理员对餐桌预订进行管理，查看预订列表、核对到店信息、调整桌位安排、更新预订状态。管理员对员工信息进行管理，录入员工资料、更新任职信息、启用或者停用账号。管理员对会员等级设置等级规则、增加权益内容、设定升级条件等操作，对会员等级数据进行更新。管理员对美食点餐管理中菜品信息及上架状态进行维护，对订单管理中订单详情进行查询，对支付和退款记录进行处理，对出餐或者完成状态进行更新。管理员角色用例图如下图3-2所示。
图3-2管理员用例图
第四章 系统设计
4.1 系统架构设计
系统采用前后端分离分层结构，用户界面层使用Vue.js来实现点餐、餐桌预订、购买、订单查询、评论管理等互动界面，管理员端有角色管理、员工管理、会员等级管理、点餐管理、预订管理、订单管理入口。应用服务层采用Spring Boot实现业务编排、权限校验、订单和预订流程、会员等级计算和评论审核，接口规范参考17。数据持久层使用MySQL来存储订单、菜品、餐桌、会员和员工等数据，并且使用事务控制以及ORM映射。系统支持层有登录认证、日志审计、参数校验、异常处理。系统架构图如下图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
基于SpringBoot的酒店会员点餐系统主要为普通用户和管理员两种角色提供服务。普通用户可以进行美食点餐、餐桌预定、美食购买、查看、管理我的订单、发表评论等个性化点餐、预订需求的满足。管理员主要对系统进行整体的运营工作，即角色管理、餐桌预订管理、员工信息管理、会员等级管理、美食点餐管理、订单管理等的管理，保证系统的正常运行。各个功能模块涵盖了酒店点餐和管理的主要业务流程，使用户和后台管理相结合。该系统的功能结构图如图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 数据库设计
4.4.1 概念模型设计
概念模型把现实世界转换成信息系统时，对业务对象进行提炼，把系统中的实体、属性、联系用E-R图表现出来，从而达成数据间的关联。本系统从数据库表结构出发，以用户账户、普通用户、员工信息等主体对象，购物车、订单、美食点餐、餐桌预订等业务过程对象，商品信息、文章等业务内容对象为依据，构建起可以支持业务闭环的数据视图。在建模时先找出各个表所对应的具体实体，再根据主键和用户编号等字段建立实体之间的联系，使信息的组织达到一致性和可扩展性的目的，为之后的逻辑结构设计和实现打下基础，相关建模方法可以参考文献18。全局E-R模型如图4-8所示。
图4-8全局ER图
根据系统的分析，系统的主要实体有用户账户、普通用户、员工信息、商品信息、购物车、订单、美食点餐、餐桌预订、文章、评论等，各个实体的具体属性如下图所示。
(1)用户账户实体主要包括用户账户id、用户名、密码、手机号码等。用户账户实体属性如图4-9所示。
图4-9用户账户实体属性图
(2)普通用户实体主要包括普通用户id、用户ID、用户姓名、审核状态等。普通用户实体属性如图4-10所示。
图4-10普通用户实体属性图
(3)员工信息实体主要包括员工信息id、员工姓名、员工工号、部门名称等。员工信息实体属性如图4-11所示。
图4-11员工信息实体属性图
(4)商品信息实体主要包括商品信息id、产品ID、标题、卖价等。商品信息实体属性如图4-12所示。
图4-12商品信息实体属性图
(5)购物车实体主要包括购物车id、商品id、数量、总价等。购物车实体属性如图4-13所示。
图4-13购物车实体属性图
(6)订单实体主要包括订单id、订单号、订单状态、总价等。订单实体属性如图4-14所示。
图4-14订单实体属性图
(7)美食点餐实体主要包括美食点餐id、标题、卖价、商品库存等。美食点餐实体属性如图4-15所示。
图4-15美食点餐实体属性图
(8)餐桌预订实体主要包括餐桌预订id、预订日期、预订人数、审核状态等。餐桌预订实体属性如图4-16所示。
图4-16餐桌预订实体属性图
(9)文章实体主要包括文章id、标题、正文、文章描述等。文章实体属性如图4-17所示。
图4-17文章实体属性图
(10)评论实体主要包括评论id、内容、来源ID、回复评论ID等。评论实体属性如图4-18所示。
图4-18评论实体属性图
4.4.2 数据库逻辑设计
本系统逻辑结构设计以概念模型为基础，把用户账户、普通用户、员工信息等主体数据，以及购物车、订单、美食点餐、餐桌预订等过程数据落地到关系表中；各个表用主键唯一标识记录，用用户ID、商品ID、来源ID等字段建立关联，保证数据的一致性和可追溯性。字段类型统一规范为int、bigint、varchar、datetime等，兼顾查询性能和扩展空间，对状态、审核、上架等字段使用枚举式存储方便统计分析，保留关键时间字段支持审计和运维。19
(1)用户账户表主要是用来管理系统登录与账号基础信息。主要包括用户账户id、邮箱、密码、手机号码、昵称、创建时间等字段。用户账户表如表4-1所示。
表4-1用户账户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | user_account_id | bigint | - | 用户账户id |
| 2 | avatar_url | varchar | 200 | 头像地址 |
| 3 | varchar | 100 | 邮箱 | |
| 4 | email_verified | varchar | 10 | 邮箱认证 |
| 5 | points | int | 11 | 积分 |
| 6 | last_login_time | datetime | - | 上次登录时间 |
| 7 | nickname | varchar | 50 | 昵称 |
| 8 | password | varchar | 100 | 密码 |
| 9 | mobile | varchar | 20 | 手机号码 |
| 10 | mobile_verified | varchar | 10 | 手机认证 |
| 11 | create_time | datetime | - | 创建时间 |
(2)普通用户表主要是用来记录普通用户的实名与审核等信息。主要包括普通用户id、用户ID、用户姓名、用户性别、用户年龄、审核状态等字段。普通用户表如表4-2所示。
表4-2普通用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | normal_user_id | bigint | - | 普通用户id |
| 2 | user_id | bigint | - | 用户ID |
| 3 | user_name | varchar | 50 | 用户姓名 |
| 4 | user_gender | varchar | 2 | 用户性别 |
| 5 | user_age | int | 11 | 用户年龄 |
| 6 | audit_status | varchar | 20 | 审核状态 |
| 7 | visible_member | varchar | 20 | 可见会员 |
| 8 | create_user_id | bigint | - | 创建用户ID |
| 9 | create_time | datetime | - | 创建时间 |
| 10 | update_time | datetime | - | 更新时间 |
(3)员工信息表主要是用来维护员工档案与在职状态等管理信息。主要包括员工信息id、员工姓名、员工工号、部门名称、联系电话、在职状态等字段。员工信息表如表4-3所示。
表4-3员工信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | staff_info_id | bigint | - | 员工信息id |
| 2 | staff_name | varchar | 50 | 员工姓名 |
| 3 | staff_no | varchar | 30 | 员工工号 |
| 4 | department_name | varchar | 100 | 部门名称 |
| 5 | contact_phone | varchar | 20 | 联系电话 |
| 6 | staff_gender | varchar | 2 | 员工性别 |
| 7 | staff_age | int | 11 | 员工年龄 |
| 8 | home_address | varchar | 200 | 家庭住址 |
| 9 | job_status | varchar | 20 | 在职状态 |
| 10 | remark_info | varchar | 200 | 备注信息 |
| 11 | create_time | datetime | - | 创建时间 |
(4)商品信息表主要是用来存储商品内容、库存与定价等信息。主要包括商品信息id、产品ID、描述、卖价、商品库存、上架状态等字段。商品信息表如表4-4所示。
表4-4商品信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | product_info_id | bigint | - | 商品信息id |
| 2 | product_id | varchar | 50 | 产品ID |
| 3 | description | varchar | 200 | 描述 |
| 4 | content | varchar | 255 | 正文 |
| 5 | cover_image | varchar | 200 | 封面图 |
| 6 | click_count | int | 11 | 点击量 |
| 7 | points | int | 11 | 积分 |
| 8 | stock | int | 11 | 商品库存 |
| 9 | sale_price | double | - | 卖价 |
| 10 | shelf_status | varchar | 20 | 上架状态 |
| 11 | create_time | datetime | - | 创建时间 |
(5)购物车表主要是用来记录用户加入购物车的商品与数量、价格等信息。主要包括购物车id、商品id、数量、单价、总价、状态等字段。购物车表如表4-5所示。
表4-5购物车表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | cart_id | bigint | - | 购物车id |
| 2 | product_id | bigint | - | 商品id |
| 3 | title | varchar | 100 | 标题 |
| 4 | image_url | varchar | 200 | 图片 |
| 5 | spec | varchar | 100 | 规格 |
| 6 | quantity | int | 11 | 数量 |
| 7 | unit_price | double | - | 单价 |
| 8 | origin_price | double | - | 原价 |
| 9 | total_price | double | - | 总价 |
| 10 | status | varchar | 20 | 状态 |
| 11 | create_time | datetime | - | 创建时间 |
(6)订单表主要是用来管理用户下单后的收货与发货等订单信息。主要包括订单id、收件地址、联系人姓名、联系人手机、发货状态、创建时间等字段。订单表如表4-6所示。
表4-6订单表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | order_id | bigint | - | 订单id |
| 2 | full_purchase | varchar | 20 | 全额购买 |
| 3 | receive_address | varchar | 200 | 收件地址 |
| 4 | contact_email | varchar | 100 | 联系人邮箱 |
| 5 | contact_name | varchar | 50 | 联系人姓名 |
| 6 | contact_mobile | varchar | 20 | 联系人手机 |
| 7 | delivery_status | varchar | 20 | 发货状态 |
| 8 | cancel_reason | varchar | 200 | 取消订单原因 |
| 9 | description | varchar | 200 | 描述 |
| 10 | product_id | bigint | - | 商品ID |
| 11 | product_image | varchar | 200 | 商品图片 |
| 12 | create_time | datetime | - | 创建时间 |
(7)美食点餐表主要是用来展示点餐菜品内容与价格、库存等信息。主要包括美食点餐id、描述、封面图、卖价、商品库存、积分等字段。美食点餐表如表4-7所示。
表4-7美食点餐表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | food_order_id | bigint | - | 美食点餐id |
| 2 | content | varchar | 255 | 正文 |
| 3 | description | varchar | 200 | 描述 |
| 4 | cover_image | varchar | 200 | 封面图 |
| 5 | main_image1 | varchar | 200 | 主图1 |
| 6 | main_image2 | varchar | 200 | 主图2 |
| 7 | main_image3 | varchar | 200 | 主图3 |
| 8 | points | int | 11 | 积分 |
| 9 | stock | int | 11 | 商品库存 |
| 10 | sale_price | double | - | 卖价 |
(8)餐桌预订表主要是用来记录用户餐桌预订申请、人数与审核结果等信息。主要包括餐桌预订id、预订日期、预订编号、预订人数、审核状态、手机号码等字段。餐桌预订表如表4-8所示。
表4-8餐桌预订表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | table_booking_id | bigint | - | 餐桌预订id |
| 2 | booking_date | date | - | 预订日期 |
| 3 | booking_remark | varchar | 200 | 预订备注 |
| 4 | booking_no | varchar | 50 | 预订编号 |
| 5 | create_user_id | bigint | - | 创建用户ID |
| 6 | create_time | datetime | - | 创建时间 |
| 7 | audit_reply | varchar | 200 | 审核回复 |
| 8 | audit_status | varchar | 20 | 审核状态 |
| 9 | mobile | varchar | 20 | 手机号码 |
| 10 | booking_people | int | 11 | 预订人数 |
| 11 | normal_user | varchar | 50 | 普通用户 |
| 12 | update_time | datetime | - | 更新时间 |
(9)文章表主要是用来发布与管理文章内容、分类与互动数据。主要包括文章id、标题、正文、文章描述、来源、文章分类等字段。文章表如表4-9所示。
表4-9文章表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | article_id | bigint | - | 文章id |
| 2 | title | varchar | 100 | 标题 |
| 3 | content | varchar | 255 | 正文 |
| 4 | article_desc | varchar | 200 | 文章描述 |
| 5 | click_count | int | 11 | 点击数 |
| 6 | cover_image | varchar | 200 | 封面图 |
| 7 | like_count | int | 11 | 点赞数 |
| 8 | source | varchar | 100 | 来源 |
| 9 | tag | varchar | 100 | 标签 |
| 10 | category | varchar | 100 | 文章分类 |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | datetime | - | 更新时间 |
(10)评论表主要是用来记录用户评论内容、来源关联与回复关系。主要包括评论id、内容、来源ID、来源表、回复评论ID、是否隐藏等字段。评论表如表4-10所示。
表4-10评论表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | comment_id | bigint | - | 评论id |
| 2 | avatar_url | varchar | 200 | 头像地址 |
| 3 | content | varchar | 500 | 内容 |
| 4 | nickname | varchar | 50 | 昵称 |
| 5 | reply_comment_id | bigint | - | 回复评论ID |
| 6 | source_field | varchar | 50 | 来源字段 |
| 7 | source_id | bigint | - | 来源ID |
| 8 | source_table | varchar | 50 | 来源表 |
| 9 | is_hidden | varchar | 10 | 是否隐藏 |
| 10 | is_top | varchar | 10 | 是否置顶 |
| 11 | create_time | datetime | - | 创建时间 |
| 12 | update_time | 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.2 管理员功能实现
5.2.1 角色管理功能实现
角色管理功能是对系统用户权限和角色类别进行配置的功能，系统可以设置不同的角色以及对应的权限。管理员可以对现有的角色信息进行管理或者调整。该功能完成的是对角色相关配置数据的变更以及同步。角色管理界面如下图5-6所示。
图5-6角色管理界面
5.2.2 餐桌预订管理功能实现
餐桌预订管理功能是对平台上的所有餐桌预约信息进行统一管理，该模块可以实现管理员对所有的餐桌预约记录进行查询和修改。管理员能够对预订数据执行审核、更新等操作。系统对所有的变更做数据维护以及统一的状态跟踪。餐桌预订管理界面如图5-7所示。
图5-7餐桌预订管理界面
5.2.3 员工信息管理功能实现
员工信息管理功能是对平台员工相关信息的录入、修改和查询等操作，系统给管理员提供员工数据的录入、修改和查询等功能。管理员可以对员工的基本信息进行管理。系统对员工状态、信息变更等实行实时处理并加以记载。员工信息管理界面如下图5-8所示。
图5-8员工信息管理界面
5.2.4 会员等级管理功能实现
会员等级管理功能主要是对会员用户等级属性进行设置，系统给管理员提供会员分级、等级调整的操作。管理员可以对会员等级进行添加、修改等操作。系统会自动同步等级设置和变动信息。会员等级管理界面如图5-9所示。
图5-9会员等级管理界面
5.2.5 美食点餐管理功能实现
美食点餐管理功能主要对系统中的美食内容进行设置管理，该模块可以实现管理员对菜品信息及配置的修改。管理员可以在功能页面上进行美食信息的增加和修改。系统对所有的更改操作都做数据同步、校验处理。美食点餐管理界面如图5-10所示。
图5-10美食点餐管理界面
5.2.6 订单管理功能实现
订单管理功能是对订单处理流程、状态进行集中管理，目前模块可以实现系统级订单查询、审核。管理员可以查看、管理全部订单的各项详情。系统对订单状态变化自动执行对应的数据处理逻辑。订单管理界面如图5-11所示。
图5-11订单管理界面
第六章 系统测试
6.1 系统测试目的
系统测试的主要目的就是检验基于SpringBoot的酒店会员点餐系统各个业务场景下功能实现是否符合设计要求，重点考察全链路数据的一致性以及系统交互的准确性，用一系列测试活动来发现可能存在的缺陷，并对重要模块的行为和业务流程进行验证。经过系统的测试，可以保证各个模块的闭环，所有的主要业务逻辑都可以在预期的边界内稳定地运行，从而有效地控制上线的风险20。
6.2 系统测试的原则与方法
系统测试过程按照黑盒测试的原则进行，主要对系统的外部表现以及用户的实际操作体验进行关注。测试活动包含登录权限、数据传递、功能适配、异常处理等主要部分，对于正常的流程以及异常分支都会设置检测点。用等价类划分法、边界值分析法、因果图法和正反向场景构造法对各项业务功能进行全方位的验证，可以及时发现逻辑漏洞和实现偏差。本策略重视业务流程整合，按阶段推进测试工作，形成闭环保证体系，把需求层、功能层的映射关系都考虑进去，从而达到和设计的一致性目的。
6.3 测试用例
(1)美食点餐功能
美食点餐功能是给用户多种菜品选择，完成下单的模块，美食点餐功能测试见表6-1。
表6-1美食点餐功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 菜品列表显示 | 进入点餐页面 | 显示所有可点菜品及分类信息 | 符合预期 |
| 添加菜品至购物车 | 选择特定菜品并添加数量 | 购物车信息实时更新 | 符合预期 |
| 提交订单 | 完成选择后生成订单 | 订单被创建并展示在我的订单中 | 符合预期 |
(2)餐桌预订功能
餐桌预订功能是给用户预约用餐座位，提高用餐体验的功能，餐桌预订功能测试如下表6-2所示。
表6-2餐桌预订功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 可用餐桌查询 | 选择日期与时间查询空闲餐桌 | 显示所有可用餐桌信息 | 符合预期 |
| 餐桌预约提交 | 选择餐桌输入基本信息预约 | 生成预约记录并返回确认信息 | 符合预期 |
| 预约订单查看 | 进入预约记录查询界面 | 展示当前用户所有历史与当前预约 | 符合预期 |
(3)订单管理功能
订单管理功能用来实现订单的统一维护、状态变更和异常处理，订单管理功能测试见表6-3。
表6-3订单管理功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 订单列表分页 | 管理员登录后查看订单列表 | 正确分页并显示详细订单信息 | 符合预期 |
| 订单状态流转 | 选择订单进行状态修改 | 状态修改后订单流转正常 | 符合预期 |
| 异常订单标记 | 对异常订单进行处理并标记 | 异常订单显示明显标识 | 符合预期 |
(4)评论管理功能
评论管理功能是用户对美食品评进行统一管理、评论管理功能测试如下表6-4所示。
表6-4评论管理功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 评论发布 | 用户选择菜品后填写并提交评论 | 评论信息存入系统并即时可见 | 符合预期 |
| 评论列表展示 | 进入评论管理界面分页浏览 | 显示所有评论内容与用户归属 | 符合预期 |
| 评论审核 | 管理员对评论内容进行审核 | 未通过审核评论不展示 | 符合预期 |
(5)角色管理功能
角色管理功能是规范系统内部权限的分配，保证各个用户之间的操作边界，角色管理功能测试结果见表6-5。
表6-5角色管理功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 角色列表查看 | 访问角色管理页面 | 显示所有角色及关联权限 | 符合预期 |
| 角色新增 | 添加新角色并分配权限 | 新角色可在列表中展示并生效 | 符合预期 |
| 角色修改 | 编辑已存在角色信息 | 变更后角色信息立即生效 | 符合预期 |
6.4 测试结果分析
酒店会员点餐系统全部功能模块测试结果均满足预期，业务流程中每一个环节都可以按照设计要求执行预定的操作，系统具有较好的稳定性以及高容错能力。各个功能间数据一致性以及交互准确性的检验已经完成，系统具备了正式运行的条件，为之后上线使用打下了良好的基础。