受疫情影响，学校将授课方式改为了线上教学。为了有效的预防新冠病毒，提倡非必要不要聚集的要求，但在食堂点餐时难免会增加人员聚集情况，为了解决这一问题有必要设计一套点餐系统，点餐只需在线上完成，避免了到食堂人与人接触传播的风险。由学校食堂提供外卖，学生可在寝室用餐，直接解决了人群聚集的问题，缓解食堂用餐人员压力，降低病毒感染风险。
校园点餐的系统使用了B/S的架构形式，利用浏览器作为商家操作界面，使商家能够通过浏览器直接访问系统，完成商品添加、修改等工作。利用小程序的方便快捷的特点，给同学一个友好的用户界面，在小程序里面可以完成点餐功能。本文主要对系统的功能结构进行设计，采用SpringBoot+Mybatis开发后台管理系统，小程序实现用户操作功能。为同学们提供一个方便快捷的点餐方式。
关键词
疫情；点餐系统；校园点餐；SpringBoot；Mybatis；小程序
Abstract
Due to the epidemic, the school changed its teaching method to online teaching. In order to effectively prevent novel coronavirus, the requirement of not gathering together unless necessary is advocated, but it is inevitable that people will gather together when ordering food in the canteen. In order to solve this problem, it is necessary to design a meal ordering system, which can only be completed online to avoid the risk of person-to-person contact transmission in the canteen. Takeout is provided by the school canteen, and students can have meals in the dormitory, which directly solves the problem of crowd gathering, alleviates the pressure of dining staff in the canteen, and reduces the risk of virus infection.
Campus ordering system uses B/S architecture, using the use the browser as the interface, so that users can directly access system through the browser to complete the work of adding and modifying goods. Make use of the convenient and quick features of wechat mini program, give students a friendly user interface, in the mini program can complete the ordering function. This paper mainly designed the functional structure of the system, using SpringBoot+Mybatis development background management system, small program to achieve user operation functions. To provide students with a convenient and quick way to order food.
Key words
Ordering system; SpringBoot; Mybatis; Small program; epidemic; Campus order
目录
第一章 前言
随着互联网的不断发展，使得生活变得越来越方便。在20世纪这个勇于创新的年代，经过无数科学家的努力、钻研和变革后，如今的我们可以在家里、户外等任何场所使用手机、平板、电脑等互联网终端设备进行工作，完成学习、购物、社交娱乐等各种人类社会发展的相关活动。通过“互联网+”这一模式，让我们生活与互联网之间的关系变得更加紧密。这一切彻底打破了人们对固定工作和学习的老旧思想，使整个世界成为互通有无的信息共同体，真正的把人们带入了“足不出户，已知天下”的新时代——互联网信息时代。各种店铺也实现了线上销售线上配送的新模式，越来越多的店铺不断上线，为消费者展示着一种迅速、便捷的全新购物体验。让消费者可以足不出户购买到天南海北的各种商品，给消费者带来了非常丰富的购物体验。
受疫情冲击，自2020年开局传统线下消费需求大幅萎缩，而网络团购、网络生鲜、智能配送等“无接触消费”快速兴起，1-2月上海商品类网络购物交易额同比增长31.2%。某生鲜电商疫情期间网上订单数量成倍增长，在全国实行“无接触配送”。某外卖平台帮助餐饮企业复工复产，已为数万家中小商户新上线外卖功能，订单量增长迅猛，已在全市多个商圈商务楼宇中设置智能配送柜，加快快递末端设施集成建设。多家生活服务类互联网平台企业等提出针对生活服务类企业网点多而分散的特点，进一步将“一照多址”改革拓展到全市。疫情期间，“无接触配送”、小区门口自提成为主要的消费交互方式。
“无接触消费”的消费模式快速兴起，为阻隔疫情传播做出一定的贡献。在学校食堂内有时还是会出现聚集情况的发生。为了减少这一现象的发生做一个点餐管理系统是很有必要的，可以降低聚集情况的发生。这样也为阻隔疫情传播风险贡献了属于自己的一份微小的力量。
随着智能手机和网络的覆盖越来越广，人们已近进入信息化时代。几乎所有成年人都人手一部智能手机，网络已经掌握在了人们的手中。各种网上商店也琳琅满目，线上消费也变得更加的普通。通过根据国家统计局的数据进行分析得到，在2021年，全国范围内的网上商品售卖的零售额达到了131000亿元，和去年同期相比增长了14.1%，增长速度比上年的增长速度加快了3.2个百分点。在这些网上售卖零售额中，通过购买实物商品的网上销售零售金额达到了108000亿元，在近些年来首次突破了100000亿元，与去年相比增长了12.0%，网上销售零售金额占全国社会消费品的全国零售总金额的比重为24.5%，网上销售金额对我国社会消费品的零售总金额增长的贡献率为23.6%。
随着互联网+模式的兴起，传统饮食行业与互联网结合使得外卖行业飞速发展，形成一条完整产业链并逐步完善和壮大，让国内的餐饮外卖行业逐步走向成熟。而在疫情的影响下，消费者更依赖于外卖，消费习惯进一步养成，这在很大程度上助推了外卖餐饮行业的发展。餐饮外卖行业起源于电话订餐，依托互联网发展开拓出了网络订餐的模式。经过多年的发展餐饮外卖形成了完整的产业链，上游由餐饮用户和外卖骑手组成;中游主要是各类外卖平台，在国内比较流行的平台主要为美团和饿了么等外卖平台;下游的消费者主要是广大青年和在校大学生为主要力量。
O2O就是一种通过互联网吸引客户到自己的店中体验的一种销售方式，国外早在2010年就首先提出了这个概念 。这是一种营销模式的创新通过互联网与实体店相结合为产品销量的增加提供了一种新颖的模式。据研究机构Iresearch调查分析，在未实现这一模式时美国的餐饮行业所销售的收入规模就达到6363亿美元，所拥有的餐饮企业就有98万多家，当O2O这是一模式一经使用就让外卖的量级规模突破670亿美元，而大多数还处在电话外卖模式中缺乏效率和规范化，说明在线订餐的潜在发展动力不可限量。另一方面，发展至今，美国的外卖O2O市场基本成熟，表明外卖O2O模式可以复制与因地制宜，移动互联网端外卖O2O未来发展趋势更人性化，营销带入强，内容化。国外的外卖平台有McDonald's、Kentucky Fried Chicken等。
校园点餐是一个方便大家在运营时间内，在校园范围的任意一个地方进行点餐的应用。极大地方便了同学们的点餐需求，减少食堂的排队拥挤现象。它为同学们提供了一个便捷的点餐平台，更好的服务同学，降低了同学前往食堂就餐的时间，减轻食堂的短时间大量聚集的拥堵情况。
由于现在学校还是传统的食堂就餐方式，暂无一个好的平台为学校食堂服务。经过调查发现同学们对不能进行线上点餐深感遗憾，食堂就餐由于就餐时间统一导致短时间内食堂人员密集，在食堂门口出现拥堵等情况。所以开发一款点餐的软件就能很好得解决这一现象，减轻食堂座位不够和排队拥挤等现象的发生，更好的为同学服务。
由于疫情具有传播风险，提倡非必要不要集聚的要求，但在食堂点餐时难免会有人员聚集的情况发生。为了方便疫情期间同学们的就餐方便和避免大量人员在食堂集聚，就决定结合自己实际开发一款方便同学使用的校园点餐系统。点餐只需在线上完成，减少了同学们食堂点餐时的密切接触和排队等待点餐时间长的问题，缓解食堂用餐拥挤压力，降低病毒传播风险。
通过对各种技术的综合分析，决定在本系统的开发过程中使用Java作为开发语言，由于它的各种特性比较优秀所以它是开发人员的不错选择。在开发时由于项目有小程序端，所以使用了uniapp作为小程序的开发框架，这框架只需一端开发可达到多端使用的目的，使用也比较简洁。 Java语言作为静态面向对象编程语言的代表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程[1]。
这四层结构根据其的不同的特性分别作用在不同的部位上。事实上，sun设计J2EE的初衷是为了解决两层模式(client/server)的弊端,在传统模式中，客户端担当了过多的角色而显得臃肿,在这种模式中,第一次部署的时候比较容易,但难于升级或改进,可伸展性也不理想,而且经常基于某种专有的协议,通常是某种数据库协议[2]。
J2EE四层经典的结构：
1、在本地客户端上运行的客户层。
2、在各种服务器上运行的Web层。
3、在各种服务器上运行的业务层。
4、在各种服务器上运行的 数据库层。
Spring Boot框架是大多数开发人员都比较喜欢使用的一个框架。在它的内部配置了大量常用的信息，从而使的开发者不需要过分的去自己重新配置这些信息，使用这一框架有着约定大于配置的准则，很好的简便了开发过程中一些繁琐而且复杂的配置工作，开发者只需要根据自己的需要去增加所需的配置就可以了。
SpringBoot所含有的主要的特征有：
1、可以将项目创建为JAR和WAR；
2、内嵌Tomcat或Jetty等Servlet容器；
3、提供自动配置，简化Maven配置；
4、尽可能自动配置Spring容器；
MyBatis-Plus(opens new window)，是一个基于MyBatis(opens new window)的增强工具，是通过在MyBatis的基础上简化开发的过程、增强代码的编写效率产生的数据库查询工具。MyBatis是一款深受广大开发人员喜爱和使用的持久层框架。MyBatis 几乎避免了所有的复杂而繁琐的操作过程只需开发人员通过简单操作就可获取对应的相关内容。是apache的一个开源项目iBatis,2010年这个项目由apache software foundation迁移到了google code[3]。
1、简单易学：体积小，没有第三方依赖，使用简单，学习方便。
2、利用简单SQL语句就可以操作数据库。
3、实现代码分离增加代码的可阅读程度。
4、提供映射标签，支持对象与数据库的orm字段关系映射
5、提供对象关系映射标签，支持对象关系组建维护
MySQL是一个常用的关系型数据库，它在 WEB 应用方面，拥有良好的应用基础，由于其简单易学，深受广大开发者的使用。它将不同的数据保存在不同的表中，通过特定的SQL语句进行数据获取，增加了系统获取数据的速度。
通过对系统要解决的主要问题和论文结构的分析可以全面的对整个项目进行一定的了解，从而减少系统的开发时间和做好相应的准备工作。
本系统主要是为了方便同学在校点餐而开发的，主要分为两大模块。用户可以通过手机进行商品信息的浏览并进行下单操作，当用户余额不足时，可以通过支付宝进行储值，从而完成消费。当用户的订单完成后可以对订单进行评论操作，方便商家对所评价的信息进行相应操作。商家可以通过pc端进行登录后查询用户订单和修改所上架的商品信息，也可阅读用户所提交的各种评论信息，为之后更好的服务用户提供一定的基础。
校园点餐系统的论文主要由五大章节组成，通过对每一章节的分析可以清晰全面的了解整个论文的行文脉络，以及系统的各种设计过程。具体如下：
第一章前言：通过对所要开发系统的国内外现状以及现存使用较广的类似项目进行分析，全面的了解了项目的研究意义和开发技术。
第二章需求分析：根据项目的背景调查后，对项目进行各种可行性分析，从而制作出一个能够满足用户需求和可行的项目。
第三章系统设计：从用户的各种需求和项目的基本功能的分析结果中获取项目的具体功能要求，并根据需求完成系统结构设计和数据库表设计。
第四章系统详细设计与实现：根据系统设计结构对项目进行开发并描述出每个功能的详细设计过程以及实现结果。
第五章系统测试：对已完成功能进行测试，从而找出系统中存在的问题，并根据问题对其进行修改，从而使系统能够正常的满足用户需求。
通过对现有的各大网络线上点餐平台的调查与分析，确定了该系统的基本系统需求。该系统主要以手机端为用户显示购买端，pc端为商家管理端，为用户提供点餐服务。为食堂内的所有商家提供一个线上销售平台。为达到更好的用户体验，整个系统不仅保持简洁美观操作方便，还应保障整个系统的稳定性，并为用户信息安全提供保护。
可行性分析就是开发人员在开发软件前为软件开发过程做的一系列准备工作，在这一过程中开发人员通过对与软件开发的各个细节以及在开发过程中可能遇到的包括但不限于研究经费和技术手段以及用户使用难度等各个角度对系统进行分析，从而创造出一个让用户满意让公司和工作人员得到收获的过程，并为开发过程提供一些建议和意见，所以在进行可行性分析时一定要满足它的可靠和科学性，为下一步的开发做好该做的准备工作。
该系统采用Java语言作为开发语言，Java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点[4]。它还有良好的开发框架支持，开发难度低、效率快。数据库采用的是关系型数据库MySQL，它也是一种上手难度低，易于使用的一种常见的数据库。所以从技术上来说完成该系统的功能还是能很好实现的，从技术可行性上说该系统能成功完成。
经济可行性分析就是在开发项目时从项目的开发工作中获取到项目开发是否能够达到公司要求的利益和软件开发过程中的研发经费是否超标的一项任务。其根本任务是从国民经济角度，通过全面的成本效益的分析，通过多方案的比较来确定建设项目是否接受和推荐最佳的投资方案，为决策者做出投资决策提供科学依据[5]。
该系统采用的技术大多都是开源的，使用从经济方面来看系统几乎是零成本。所以预期经济与实际经济应该差距不打，所以从经济可行性分析该系统能够完美完成。
操作可行性就是判断系统功能是否能够正常操作是否能够方便用户使用的研究分析，通过分析用户的体验和反馈判断用户是否容易接受。使用本软件无需任何培训，操作简单容易上手。管理人员也无需太多的技术需求。操作人员只需使用后就可以掌握使用流程。从操作可行性分析得出操作简单易于使用的结果。
通过对系统功能需求的研究，对用户的需求分析后根据用户的要求开发出能够正常运行而且能够满足用户需求的功能，通过这一步骤使各个工作人员明白自己负者的具体模块为快速开发做好准备工作。
通过对多家线上点餐平台的实际使用分析，对校园点餐的功能需求如下：
1、用户端
（1）可以一键登录注册
（2）可根据要求修改个人信息
（3）可以根据需要点餐
（4）可以查看购买记录
（5）可以对已定商品进行评价
2、管理员端
（1）可以添加、修改商品信息
（2）可以修改个人信息
（3）可以查看销售额
（4）可以查看订单
（5）可以管理用户信息
用例图（英语：use case diagram）是方便使用者了解系统交互过程的一种简单表达方式，通过对用例图的研究可以清晰的看出用户和其相关用例之间的详细联系。用例图也经常和其他图表配合使用[6]。通过对国内的美团、饿了么等外卖平台进行分析，决定将系统分成两个部分。手机端为用户操作环境，pc端为管理员操作环境。不同的角色所能进行的操作也大不相同。用户的操作记录被存储进数据库，对应的信息也被反馈给用户，两者间存在动态关联。
管理人员用例主要包括有登录、管理个人信息、管理商品信息、管理相应的订单信息、管理评论信息、退出等[7]。
管理员用例图如图2-1所示。
图2-1 管理员用例图
用户的用例图包括登录、浏览商品、添加商品进入购物车、修改个人信息、添加地址、查看历史订单、评论订单等。
用户用例图如图2-2所示。
图2-2 用户用例图
测试用例(Test Case)就是通过对软件进行测试的一些具体过程进行描述。一般用例的主要内容包括用例名称、主要参与者、前置条件、触发流程和基本流程等，最终形成文字表格。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求[8]。
该用例主要是系统维护员对商户信息的管理用例，用例描述如表2-1所示。
表2-1 店铺信息管理用例描述表
| 用例条目 | 描述 |
| 用例名称 主要参与者 其他参与者 描述 前置条件 后置条件 触发流程 基本流程 代替流程 结束 实现约束和说明 待解决问题 | 店铺信息管理 系统管理员 无 管理员根据要求添加店铺信息 管理员登录 无 点击管理店铺
无 店铺信息维护结束 店铺信息不存在重复项 无 |
该用例主要是商家对所售商品信息进行管理的用例，用例描述如表2-2所示。
表2-2 商品信息管理用例描述表
| 用例条目 | 描述 |
| 用例名称 主要参与者 其他参与者 描述 前置条件 后置条件 触发流程 基本流程 代替流程 结束 实现约束和说明 待解决问题 | 商品信息管理 商户 系统维护员 商户根据要求更改商品信息 能够进入管理界面 无 按下商品管理按钮 1、登录成功 2、对商品信息进行操作 无 商品信息维护结束 商品信息不存在重复项 无 |
这一用例主要是维护管理人员通过要求对一些用户的信息进行整改的详细用例，用例描述如表2-3所示。
表2-3 用户信息管理用例描述表
| 用例条目 | 描述 |
| 用例名称 主要参与者 其他参与者 描述 前置条件 后置条件 触发流程 基本流程 代替流程 结束 实现约束和说明 待解决问题 | 用户详细信息管理 系统维护员 无 系统维护员根据需求更改用户信息 成功登录进入系统 无 在主页面按下用户管理按钮
无 用户信息操作成功 不可对用户进行密码查看 无 |
该用例主要是商户对使用者提交的订单管理的用例，用例描述如表2-4所示。
表2-4 订单管理用例描述表
| 用例条目 | 描述 |
| 用例名称 主要参与者 其他参与者 描述 前置条件 后置条件 触发流程 基本流程 代替流程 结束 实现约束和说明 待解决问题 | 订单信息管理 店铺管理员 无 管理员根据订单要求完成产品后对修改订单 管理员登录 无 点击接单列表 管理员登录后对订单进行操作 无 订单操作成功 无 无 |
本章通过对系统的可行性和用户需求分析初步建立起项目的各种功能，通过完成这些功能的用例分析为接下的系统结构设计提供基本保障。
系统设计是根据用户需求对系统进行设计的过程在这过程中应该在满足用户需求的同时也要为后续的开发和维护做好准备一个好的设计应该具备兼容性和一个好的可扩展性，从而实现一个好的设计过程。系统设计内容，包括确定系统功能、设计方针和方法，产生理想系统并做出草案，通过收集信息对草案做出修正产生可选设计方案，将系统分解为若干子系统，进行子系统和总系统的详细设计并进行评价，对系统方案进行论证并做出性能效果预测[9]。
本系统主要分为前后端两大操作部分。用户通过在前端对数据进行操作将数据存入数据库，系统管理员通过对数据的整理获取有用的信息并按要求进行操作。
用户通过手机端可以进行商品的浏览、将商品添加购物车、对订单进行备注、查看个人订单信息、对已完成订单进行评论、修改个人资料等功能。
当商户通过登录进入后台后可以通过对用户所提交的订单信息进行查看并制作相应的食物，可以对已成功支付用户提交的订单信息详情进行查看。
校园点餐具有的功能结构如图3-1所示：
图3-1 系统功能结构图
数据库设计(Database Design)就是根据用户功能需求设计出一个能够满足并且能够存储用户在系统中所产生的数据的一个设计过程。在进行数据库设计是应该要满足数据存储完整的同时协调好表之间的关系，为开发过程做一个好的准备，通过优秀的数据库设计减少开发对数据库的访问次数，减小数据库的访问量，降低数据库的使用率，好让用户能够快速流畅的使用系统[10]。
一个好的数据库不仅能简化开发、使用稳定、易于管理还能方便维护与扩容，所以在开发设计数据库时应满足以下的条件。
1、一对一设计原则
2、独特命名原则
3、双向使用原则
4、字段长度合理
5、关系、用途明确
设计数据库过程中，实体间有一个或多个对应关系，我们应该按照实体间的逻辑关系建立实体，防止出现不必要的错误。
本系统的E-R图如图3-2所示：
图3-2 系统E-R图
在数据库的设计过程中，一个实体可以对应一个或多个实体，实体之间这种对应的逻辑关系是我们编写程序的基础[11]。
- 店铺实体如图3-3所示：
图3-3 店铺实体属性图
- 订单实体属性图如图3-4所示：
图3-4 订单实体属性图
- 订单详情实体属性图如图3-5所示：
图3-5 订单详情实体属性图
- 商品详情实体属性图如图3-6所示：
图3-6 商品详情实体属性图
- 用户详情实体属性图如图3-7所示：
图3-7 用户详情实体属性图
- 用户地址详情实体属性图如图3-8所示：
图3-8 用户地址详情实体属性图
该系统采用MySQL数据库进行数据存储，将用户信息存入其中，通过对表之间的关系连接，保证数据库良好的设计逻辑关系。
店铺表（dc_merchant）用来存放系统添加的店铺信息。如表3-1所示。
表3-1 店铺信息表（dc_merchant）
| 列名 | 数据类型 | 长度 | 主键 | 是否为空 | 注释 |
| id | int | 11 | Y | N | 商家id |
| sort image name is_show useruuid password realname createTime phone | int varchar varchar int varchar varchar varchar datetime varchar | 11 255 255 11 255 255 255 0 30 | N N N N N N N N N | Y Y Y Y Y Y Y Y Y | 排序 商家图片 商家名称 是否显示 商家账号 商家密码 真实姓名 创建时间 联系电话 |
用户信息表（dc_user）用来存放用户具体信息，如表3-2所示。
表3-2 用户信息表（dc_user）
| 列名 | 数据类型 | 长度 | 主键 | 是否为空 | 注释 |
| customerid | varchar | 255 | Y | N | 用户id |
| nickname mobilePhone gender balance content password Aid createTime order_id | varchar varchar varchar decimal varchar varchar int datetime varchar | 255 255 255 11 255 255 11 0 30 | N N N N N N N N N | Y Y Y Y Y Y Y Y Y | 姓名 电话 性别 余额 个性签名 用户密码 地址id 创建时间 订单id |
商品信息表（dc_product）用来存放商品信息，如表3-3所示：
表3-3 商品信息表（dc_product）
| 列名 | 数据类型 | 长度 | 主键 | 是否为空 | 注释 |
| id | int | 11 | Y | N | 商品id |
| is_sell price image stock name contenr mid | int decimal varchar int varchar varchar int | 11 10 255 11 255 255 11 | N N N N N N N | Y Y Y Y Y Y Y | 是否出售 价格 商品图片 库存 商品名称 商品描述 店家id |
用户地址表（dc_addresses）用于存放用户地址信息，如表3-4所示：
表3-4 商品信息表（dc_product）
| 列名 | 数据类型 | 长度 | 主键 | 是否为空 | 注释 |
| id | int | 11 | Y | N | 地址id |
| name phone street door_number created_time update_time | varchar varchar varchar varchar datetime datetime | 255 255 255 255 0 0 | N N N N N N | Y Y Y Y Y Y | 姓名 电话 详细地址 门牌号 创建时间 修改时间 |
订单表（dc_order）用于存放订单信息，如表3-5所示：
表3-5 商品信息表（dc_ order）
| 列名 | 数据类型 | 长度 | 主键 | 是否为空 | 注释 |
| order_id | varchar | 11 | Y | N | 订单id |
| order_amount order_status pay_status createtime order_type | decimal int int datetime int | 10 11 11 0 11 | N N N N N | Y Y Y Y Y | 订单总价 订单状态 支付方式 创建时间 订单类型 |
| sort_num remark user_id mid | varchar varchar varchar int | 255 255 30 11 | N N N N | Y Y Y Y | 取餐号 订单备注 用户id 商家id |
订单详情表（dc_orderdetail）存放订单详细信息，可以根据此表查询出关于订单详情的信息，如表3-6所示：
表3-6 订单详情表（dc_ orderdetail）
| 列名 | 数据类型 | 长度 | 主键 | 是否为空 | 注释 |
| detaile_id | varchar | 30 | Y | N | 订单详情id |
| order_id product_id name price number created_time postscript mid | varchar int varchar decimal int datetime varchar int | 30 11 255 10 11 0 255 11 | N N N N N N N N | Y Y Y Y Y Y Y Y | 订单id 商品id 商品名称 商品单价 商品数量 创建时间 备注 商家id |
本章节通过从系统的总体结构和数据库方面对系统进行了一个详细的分析，通过对这些信息的分析，为接下来系统开发做好准备。
本章节主要是对校园订餐系统的主要功能的实现部分进行描述，用户通过前端将数据请求传给后端并存入数据库。管理员在后端通过管理功能对用户数据进行管理。
该系统使用两种不同的客户端供不同的使用人员使用，用户端通过手机小程序登录后可以对所售商品进行购买，当用户选择外卖时须填写送餐地址，方便商家配送产品，当用户选择自取时，即可根据订单的取餐号码到店进行取餐。PC端是为了方便商家使用，当商家登录系统后，会自动进入接单列表，当有用户下单后，系统会播报有新的订单信息，并弹出提示框，商家即可根据用户需求进行制作，当制作完成后根据用户要求进行配送或打包。
系统为小程序用户提供了一个注册页面，当用户进行提交购物车操作时或使用需要登录成功后的一些功能时如果发现用户未登录，那么系统就会转到用户登录界面，当用户输入对应的登录信息后即可成功访问。
用户注册功能时序图如下图4-1所示：
图4-1 用户注册时序图
用户注册页界面如下图4-2所示：
图4-2 用户注册页
用户注册流程图如下图4-3所示：
图4-3 用户注册流程图
用户通过登录后根据所浏览的商品信息并选择合适食物和需要的数量加入购物车，选择去结账就可完成一次购物功能。
购物功能时序图如下图4-4所示：
图4-4 购物功能时序图
购物功能实现图如图4-5所示：
图4-5 购物功能实现图
订单界面的实现图如下图4-6所示：
图4-6 订单功能实现图
用户购物流程如下图4-7所示：
图4-7 购物功能流程图
当用户成功进行下单操作后，可以在主页面点击我的按钮然后选择我的订单，在我的订单列表中就可以看到用户的订单信息详情。订单的历史详情时序图如图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所示：
图4-15 用户配送地址实现图
用户配送地址功能流程图如图4-16所示：
图4-16 用户配送地址流程图
系统后台主要是为管理员和商家使用开的，当系统完成后直接在数据库中添加一个管理员身份，由于系统使用范围只是在学校，所以商户不是太多，系统后台就不用注册功能，当学校内有新的商品需要在平台上售卖时，只需将相关文件给平台管理者人工审核完成后，由管理员添加一个商户，并将生成的用户登录号，发送个商家。商家拿到登录号后，即可登录系统，完成销售商品的添加和对自己信息的修改。
当管理员或商家访问后台系统时进行身份验证匹配，经过成功匹配就能进入系统后台界面，登录过程的时序图详情如图4-17所示：
图4-17 后台登录时序图
后台登录功能实现如图4-18所示：
图4-18 后台登录实现图
后台登录流程如图4-19所示：
图4-19 后台登录流程图
当商家管理员登录后选择商品管理就可以进入商品管理列表，在这一页面即可实现对所售商品的增加、删除和修改等基本操作，还可以根据特定条件搜索对应的商品信息，当收到商品库存不足时在此页面可以修改对应的库存信息，也可对商品进行上下架操作。商品信息管理功能的时序图如图4-20所示：
图4-20 后台登录时序图
商品信息列表实现图如图4-21所示：
图4-21 商品信息列表实现图
商品信息编辑实现图如图4-22所示：
图4-22 商品信息编辑实现图
商品信息编辑流程图如图4-23所示：
图4-23 商品信息编辑流程图
商品信息添加功能实现图如图4-24所示：
图4-24 商品信息添加实现图
商品信息添加功能流程图如图4-25所示：
图4-25 商品信息添加流程图
当商家成功登录后在主页面点击订单信息管理按钮，就可以在页面上看到所属该商家的所有订单详情，点击详情可以看到订单配送方式和订单详细内容。订单信息功能的详细时序图如图4-26所示：
订单信息管理功能的实现图如图4-27所示：
图4-27 订单信息管理实现图
订单信息管理流程图如图4-28所示：
图4-28 订单信息管理流程图
订单详情实现图如图4-29所示：
图4-29 订单详情实现图
当管理员登录系统后选择店铺管理即可获取到所有的商家信息，可再此进行商家的添加、修改和删除操作，当管理员点击商家详情时可以得到商家所售商品列表，可对其所售商品信息进行对应操作，商家信息详细管理功能时序图如图4-30所示：
图4-30 商家店铺管理时序图
商家店铺管理实现图如图4-31所示：
图4-31 商家店铺管理实现图
商家店铺管理流程图如图4-32所示：
图4-32 商家店铺管理流程图
本章节通过对项目的实现和流程图进行了介绍，反映了每个功能的具体实现和实现流程以及时序图，通过这些功能实现图能够大致的了解整个项目的主要功能，通过本章节能够更直观的了解本系统。
系统测试是通过对整个系统的每一个功能对其进行详细的测试，让整个系统不至于出现非常重大的错误信息，让整个系统变得更加的流程和让使用人员的使用体验更加良好，通过对系统进行系统测试找出隐藏于不同位置的错误信息，并根据错误对这些功能进行修改。再例如，压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等情况下是否还能正常地工作[12]。通过详细测试可以发现系统中开发时存在的一些细小的问题，通过对这些问题进行修改即可保证系统的稳定和系统的流程以及系统的信息安全性。
软件测试是软件开发人员对系统进行人工和使用工具测试的一种方法，通过对系统进行软件测试可以很大概率的降低系统软件和系统页面中出现的问题，并将问题整理成一个文档，交付给开发人员，让开发者根据测试人员通过对软件测试出现的问题进行修改从而降低软件的使用错误，在这个测试过程中软件测试人员可以使用工具或自行对软件流程分步骤进行测试一般的测试方法分为静态测试和动态测试。静态测试主要有结构分析、代码检查、代码质量度量等。动态测试由3部分组成：构造测试实例、执行程序和分析程序的输出结果[13]。
在本系统中主要使用的测试方法是黑盒测试，对系统各个功能进行测试找到其中的错误，为系统的正式使用做好准备[14]。测试时不需要对代码进行了解，只需对所实现的功能进行全面的测试即可，并将测试过程中出现的问题整理成文档记录下来，然后根据记录的文档对系统错误进行修改，从而使系统达到一个完美的状态，方便用户的使用，给用户带来一个良好的体验[15]。
测试代码：C00001
测试目的：测试当用户登录时所输入的信息不同带来的不同结果。
测试前提：可以通过登录验证。
详细测试如表5-1所示：
表5-1 系统登录功能测试用例
| 序号 | 输入测试 | 操作及步骤 | 预期结果 | 实际结果 | |
| 1 | 用户名：45625834 密码：15485651a | 在后台登录界面输入相应的数据 | 显示登录成功的提示 | 与预期效果一致 | |
| 2 3 4 5 6 | 用户名： 密码：15485651a 用户名：45625834 密码： 用户名： 密码： 用户名：￥@121828 密码：15485651a 用户名：45625834 密码：@12842942# | 在后台登录界面输入密码不输入用户名 在后台登录界面输入用户名不输入密码 在后台登录界面都不输入用户名和密码 在后台登录页面输入错误的用户名和密码 在登录页面输入正确的用户名和错误密码 | 显示必填的项不能为空 显示必填的项不能为空 必填项不能为空 用户名或密码错误 用户名或密码错误 | 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 | |
| 7 | 手机号：19845069999 密码：123456 | 在前台登录界面输入相应的数据 | 显示登录成功的提示 | 与预期效果一致 | |
| 8 9 10 11 12 13 14 | 手机号： 密码：15485651a 手机号：19845069999 密码： 手机号： 密码： 手机号：1984506 密码：15485651a 手机号：19845069999 密码：@12842942# 手机号：#12232@ 密码：123456 手机号：123456789111 密码：123456 | 在前台登录界面输入密码不输入手机号 在后台登录界面输入手机号不输入密码 在后台登录界面都不输入手机号和密码 在后台登录页面输入错误的手机号和密码 在登录页面输入正确的手机号和错误密码 在登录页面在手机号输入框内输入特殊字符 在登录页面中输入错误的手机格式 | 手机号不能为空 密码不能为空 必填的项不能为空 手机号不正确 用户名或密码错误 无法在手机号输入框内输入特殊字符 提示手机号格式错误 | 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 | |
测试结果：经过详细测试，所达到的效果与预期的效果基本一致，当用户输入错误信息时也正常提示用户的错误信息，系统反馈及时使用效果通过测试修改后得到一个良好的提升。
测试代码：C00002
测试目的：检验商家登录后是否能对所添加的商品信息详情进行管理操作。
测试前提：商户能够正常进入管理界面。
商品信息详情管理功能测试如表5-2所示：
表5-2 商品信息管理功能测试用例
| 序号 | 输入测试 | 操作及步骤 | 预期结果 | 实际结果 | |
| 1 | 商品名称：冰红茶 商品价格：3 商品库存：10 商品介绍：清凉解渴 | 在商品列表页面点击添加商品，输入对应的信息点击添加 | 提示添加成功，在页面列表显示 | 与预期效果一致 | |
| 商品图片：上传张图片 | |||||
| 2 | 商品名称：冰红茶 商品价格： 商品库存： 商品介绍： | 在商品列表页面点击添加商品，输入对应的信息点击添加 | 提示必填的项不能为空 | 与预期效果一致 | |
| 3 4 | 商品名称：冰红茶 商品价格：3 商品库存： 商品介绍： | 在商品列表页面点击添加商品，输入对应的信息点击添加 在商品列表页面点击相应商品信息后点击删除按钮 | 提示必填的项不能为空 提示是否确认删除 | 与预期效果一致 与预期效果一致 | |
测试结果：经过对商品列表的详细测试，当商家选择不同的操作时所提示的信息也各不相同，测试过程中系统使用流畅提示信息友好，测试结果与预期一致，测试通过。
测试代码：C00003
测试目的：检验商家登录后是否能查看所销售的订单详情。
测试前提：通过登录进入主界面。
订单功能测试用例如表5-3所示：
表5-3 订单信息管理功能测试用例
| 序号 | 输入测试 | 操作及步骤 | 预期结果 | 实际结果 | |
| 1 2 3 4 | 订单号： 16508807281421045 订单状态：已完成 订单号： 订单状态： | 在订单列表页面输入订单号点击搜索 在订单列表页面选择订单状态点击搜索 在订单列表页面选择对应的订单点击详情按钮 在订单列表页面不输入订单号和选择订单状态点击搜索 | 显示改订单号的订单信息 显示所有已完成订单 显示该订单下的所有商品信息和价格 显示所有的订单信息 | 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 | |
测试结果：经过对订单列表的详细测试，可以更为直观的体验不同操作的不同结果，测试结果与预期一致，测试通过。
测试代码：C00004
测试目的：当商家登录后修改自己的信息检验是否出错。
测试前提：系统登录成功。
详细信息功能测试用例如表5-4所示：
表5-4 商户基本信息功能测试用例
| 序号 | 输入测试 | 操作及步骤 | 预期结果 | 实际结果 | |
| 1 2 3 | 店铺名称：重庆小吃 原密码：123 联系电话：19845666666 原密码：456 | 商家登录后点击个人信息，输入相应的数据点击修改 商家登录后点击个人信息，输入错误密码 无任何输入 | 提示个人信息修改成功 显示输入的原密码错误 无提示 | 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 | |
测试结果：经过对商家个人信息功能的详细测试，并未从中发现非常特别错误，测试结果与预期要求结果基本一致，测试通过。
测试代码：C00005
测试目的：当用户登录后对自己的收货地址进行各种操作，检验是否正确。
测试前提：能够进入页面。
具体的功能测试用例如表5-5所示：
表5-5 用户收货地址功能测试用例
| 序号 | 输入测试 | 操作及步骤 | 预期结果 | 实际结果 | |
| 1 2 3 | 收货人：小明 联系电话：19845061 收货地址：哈尔滨 门牌号:1b213 收货人：小明 收货人：小明 联系电话：19845061 | 用户登录后点击收货地址信息，输入新增地址信息点击提交 手机端登录后按下收货地址按钮，输入新增地址收货人信息，其他信息都不输入 输入对应的信息，其余不输入 | 提示地址添加成功 提示必填的项不能为空 提示必填的项不能为空 | 与预期效果一致 与预期效果一致 与预期效果一致 | |
测试结果：经过对用户的收货地址进行详细的测试，发现有一定的问题，当用户什么都不输入直接点击添加，页面跳转并显示空白信息，经过修改与调整后，实现测试结果与预期一致，测试通过。
测试代码：C00006
测试目的：当用户登录后对自己的已购商品进行评论操作，检验是否正确。
测试前提：能够进入页面。
具体的功能测试用例如表5-6所示：
表5-6 用户订单评论功能测试用例
| 序号 | 输入测试 | 操作及步骤 | 预期结果 | 实际结果 | |
| 1 2 3 4 | 订单服务：5 服务：5 订单速度：5 商品满意: 5 评论信息：真的挺好 订单服务：5 服务：5 订单速度： 商品满意: 评论信息：还行 评论信息：很好 | 用户登录后点击我的订单选择要评价的订单信息，输入对应的服务星级，点击提交评论 用户登录后点击我的订单选择要评价的订单信息，输入对应的服务星级，点击提交评论 用户登录后点击我的订单选择要评价的订单信息，什么都不输入直接点击提交评论按钮 只输入评论信息，其它的都不输入 | 提示订单评论成功 提示必填的项不能为空 提示必填的项不能为空 提示必填的项不能为空 | 与预期效果一致 与预期效果一致 与预期效果一致 与预期效果一致 | |
测试结果：通过用户对订单评论功能的详细测试，在这一过程中发现当提交评论时提示信息不展示或者是延时展示这一情况，根据这一现象对代码进行修改后达到测试结果与预期一致的目的，测试通过。
本章通过对系统已完成的功能进行黑盒测试，从而发现系统中出现的问题，并通过对这些错误进行修改使整个项目更加适合用户使用。
在本次的校园点餐的设计与实现中，通过对已有资料的研究与调研，了解了传统行业与现代科技相结合的新产物，不仅方便商家更好的制作商品也为顾客提供了良好的点餐环境，通过对美团、饿了么等外卖网站的简要分析，从中提取它们的优点，和对它们进行了一部分的优化操作，根据用户需求制作需求分析文档，从而满足各种用户的需求。通过对已有的国内外外卖平台的分析制作出国内外的外卖行业发展现状，大多都已经脱离传统的进店点餐就餐的形式，而是依托飞速发展的互联网来进行各种点餐服务，实现了居家就能享受到进店用餐的感觉。通过对已有外卖平台的分析结合实际情况制作了能够基本存载各种信息的数据库，详细的分析并完善E-R图，从而使所用的数据能够很好的保存，在系统功能上尽量满足各种该有的功能，并将其分为各种模块，通过对其的分类，方便了开发的过程，以及对系统开发的进度有了一个明确的识别方法。当系统完成后，通过对其功能的详细测试，完善了系统中的一些小的细节错误，保证了系统的完整性和功能的流畅性。
本系统已基本满足用户的业务要求，但由于时间和技术的有限，系统相对单一还有的辅助功能还为实现，该系统的存在以下不足：
1、用户支付功能由于个人无法申请，所以就只接入了支付宝的测试沙箱以实现储值功能。
2、在用户信息中无法上传图片。
3、没有实现配送接单送餐功能，只能通过商家自行送餐。
[1] 李刚.疯狂Java讲义[M].第2版.电子工业出版社,2014:2.
[2] 杜振兴.昆明中铁维修系统设计与应用[D].云南,2012.
[3] 田浩.“两个责任”动态监管平台的设计与实现[D].南京,2018.
[4] 赵景晖.Java 程序设计[M].北京机械工业出版社,2005:1-2.
[5] Huang Hanjiang.Investment Dictionary[M].Shanghai Academy of Social Sciences Press,2015.08:716.
[6] Gemino, A., Parker, D.(2009) "Use case diagrams in support of use case modeling: Deriving understanding from the picture", Journal of Database Management,20(1),1-24.
[7] 李明洁.基于云服务的校园资源共享系统的设计研究[D].中国优秀硕士学位论文全文数据库,2018.
[8] 李香菊,孙丽,谢修娟等.软件工程课程设计教程[M].北京邮电大学出版社, 2016.01:72.
[9] He Shengming.Dictionary of Finance and Economics[M].China Financial and Economic Publishing House,2015.12.
[10] 张运策.H省医院协会协同OA办公系统的设计与实现[D].中国优秀硕士学位论文全文数据库,2011.
[11] Dharmayanti Nlp Indi,Sendow Indrawati,Ratnawati Atik,Settypalli Tirumala Bharani K,Saepulloh Muharam,Dundon William G,Nuradji Harimurti,Naletoski Ivancho,Cattoli Giovanni,Lamien Charles E. African swine fever in North Sumatra and West Java provinces in 2019 and 2020, Indonesia.[J]. Transboundary and emerging diseases,2021.
[12] 张新长.城市地理信息系统[M].科学出版社,2013.
[13] 张涛,马春燕,郑炜等.软件技术基础实验教程[M].西北工业大学出版社, 2015.01:111.
[14] 赵悦然.地区物流信息管理系统设计与实现[D].哈尔滨信息工程学院,2014.
[15] 刘宇轩.软件测试方法研究[J].科技风,2018,(4):53.
转眼间就已经度过了一个又一个的春夏秋冬，大学四年的生活已悄然结束。马上我们就要各奔东西。我这次的设计实现及论文的撰写是在刘贵君老师的指导和帮助下完成的，同时，同学还给了我很多系统设计上的帮助以及建议。在这里，我要感谢对我的毕业设计给予我帮助的老师和同学，以及我这次论文所引用的各个书籍以及文章的作者们。
四年的学习生涯即将结束，在这四年里我的收获颇丰。我的每一次进步都离不开老 师的悉心教诲。
感谢学院给了我一个良好的学习环境，感谢和我一起工作和学习的同学们，是你们 在我遇到困难时给了我支持和帮助，因为有你们我的大学生活多了一份精彩。
感谢所有的任课老师，是你们给了我学业上的帮助。我要特别感谢我的班主任老师，他不仅在学习上给了我很多指导，而且还在生活和工作中给我很多帮助。在此，我向我的班主任老师致以诚挚的谢意。
感谢我的父母，是你们给了我如此安逸的生活，才能让我在生活和学习中有更多的 进步，是你们的细心关怀让我对我的未来充满了信心。
最后，衷心感谢学院的老师们，谢谢你们四年来的辛勤栽培！
376
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
