基于javaweb的每日鲜牛奶订购系统的设计与实现论文

摘要：

本文针对当前每日鲜牛奶订购系统建设中存在的问题，对当前系统建设中存在的问题进行了研究。首先，通过对以往鲜牛奶订购系统体系中已有的设计模式进行梳理，归纳出与自身技术相适应、易于实现的鲜牛奶订购系统，并选择 SpringBoot架构进行开发的系统，将该技术应用到鲜牛奶订购系统中。Eclipse是用于开发的软件， MySQL是用于数据库的软件。该系统采取 B/S架构，面向 Web开发，并以 Tomcat为 WEB服务，并运用 Spring、 Mybatis等技术进行开发。
每日鲜牛奶订购系统的实施，使牛奶购买可以更好地利用其信息技术，大大加快了对商品销售的日常工作的进程。同时，使用者方面也能更好地感受到信息技术的使用方便。该体系可以平稳、有效地工作。而且还可以大大提高用户界面的可操作性。
本文主要阐述了主流在线每日鲜牛奶订购系统的设计方案，主要包括系统管理、用户管理、商品管理、商家管理、公告管理、数据统计等业务分析及它们的功能需求，并进一步简化了用户管理的流程，降低了沟通成本。在需求分析的基础上，给出了整个架构的设计方案、功能模的划分、以及其他核心功能的设计。软件开发成功后，不仅降低了了商家的运营成本，而且能间接减少商品销售的压力，提高商家的经济效益。
关键词：数据库系统，商品，信息系统，Java，B/S

1 系统设计

3.1需求分析
3.1.1系统功能性需求分析
每日鲜牛奶订购系统根据使用权限的角度进行功能分析，并运用用例图来展示各个权限需要操作的功能。
图3.5即为管理员用例图，管理员权限操作的功能包括管理商家，管理商家星级信息，管理用户，管理商品等。

图3.5 管理员用例图
图3.6即为商家用例图，商家权限操作的功能包括管理商品，回复商品评价，管理商品订单等。

图3.6 商家用例图
图3.7即为用户用例图，用户权限操作的功能包括查看商家，购买商品，提交订单，管理商品订单等。

图3.7 用户用例图

3.2 业务需求
3.2.1用户用例分析
表3.1 用户查看商品详情用例描述表
用例用例名称名称： 用户查看商品信息
参与者： 用户
前置条件： 用户已经登录系统，点击商品，选择商品进行查看。
后置条件： 点开商品信息，系统跳转到商品的信息列表，可以查看商品详情信息。
主事件流（主成功场景/基本路径）：
2a 用户选择商品信息，跳转到详情界面。
3a 用户如果不点击商品信息，系统跳转详情界面失败。

表3.2 在线支付用例描述表
用例用例名称名称： 用户在线支付
参与者： 用户
前置条件： 用户已经登录系统，点击商品选择合适的商品进行添加购物车，并选择支付方式进行支付。
后置条件： 用户点开商品的详细信息，系统跳转到商品的信息列表，可以选择适合的商品进行购买，选择支付方式等操作。
主事件流（主成功场景/基本路径）：
2a 用户选择支付方式进行支付操作。
3a 不选择支付方式，支付失败。

3.2.2 管理员用例分析
管理员模块是每日鲜牛奶订购系统的重要组成部分，它可以帮助管理员进行高效的系统管理和维护。
（1）商品管理功能分析
商品管理功能用例描述如表3.3
表3.3商品管理功能用例描述
用例名称 管理商品
用例描述 管理员进行商品管理
参与执行者 管理员
前置条件 管理员成功登录
后置条件 管理员对商品进行管理
基本事件流
参与者行为 系统行为
1.管理员点击商品管理；

3.管理员点击修改或删除；

5.管理员填写要修改的商品信息；
2.系统显示商品管理页面；

4.系统根据管理员的选择显示修改的商品页面；

6.提交成功修改商品；
备选事件流
2a. 如果该管理员没有权限进行商品管理，则需要进行验证或提示。
3a. 如果某个商品正在被其他管理员处理，则给出相应提示信息。
4a. 如果商品信息填写不完整或有误，则进行标识或提示。

（2）用户管理功能分析
用户管理功能用例描述如表3.4所示。
表3.4用户管理功能用例描述
用例名称 用户管理
用例描述 管理员进行用户管理
参与执行者 管理员
前置条件 管理员成功登录后台
后置条件 管理员进行用户管理操作
基本事件流
参与者行为 系统行为
1.管理员点击用户管理；

3.管理员进行点击修改；

5.管理员选择要修改的用户；
2.系统显示用户管理页面；

4.系统根据管理员的点击显示修改页面；

6.提交修改信息，操作成功；
备选事件流
2a. 如果该管理员没有权限进行用户管理，则需要进行验证或提示。
3a. 如果某个用户已被封禁或是账号已过期，则需要作出相应处理并通知相关用户。

（3）商家管理功能分析
商家管理功能用例描述如表3.5所示。
表3.5 商家管理功能用例描述
用例名称 商家管理
用例描述 管理员进行商家管理
参与执行者 管理员
前置条件 管理员成功登录后台
后置条件 管理员对商家进行管理
基本事件流
参与者行为 系统行为
1.管理员点击商家；

3.管理员进行点击修改；

5.管理员选择要修改的商家；
2.系统显示商家管理页面；

4.系统根据管理员的点击显示修改页面；

6.提交修改信息，操作成功；
备选事件流
2a. 如果该管理员没有权限进行商家管理，则需要进行验证或提示。
3a. 如果某个商家正在被其他管理员处理，则给出相应提示信息。
4a. 如果该商家已过期或不再符合时效性，则可以将其标识为“已失效”或者删除。

（4）商品类型管理功能分析
商品类型管理功能用例描述如表3.6所示。
表3.6 商品类型管理功能用例描述
用例名称 商品类型管理
用例描述 管理员进行商品类型管理
参与执行者 管理员
前置条件 管理员成功登录后台
后置条件 管理员对商品类型进行管理
基本事件流
参与者行为 系统行为
1.管理员点击商品类型；

3.管理员进行点击修改；

5.管理员选择要修改的商品类型；
2.系统显示商品类型管理页面；

4.系统根据管理员的点击显示修改页面；

6.提交修改信息，操作成功；
备选事件流
2a. 如果该管理员没有权限进行商品类型管理，则需要进行验证或提示。
3a. 如果某个商品类型正在被其他管理员处理，则给出相应提示信息。
4a. 如果该商品类型已过期或不再符合时效性，则可以将其标识为“已失效”或者删除。

（5）公告类型管理功能分析
公告类型管理功能用例描述如表3.7所示。
表3.7 公告类型管理功能用例描述
用例名称 公告类型管理
用例描述 管理员进行公告类型管理
参与执行者 管理员
前置条件 管理员成功登录后台
后置条件 管理员对公告类型进行管理
基本事件流
参与者行为 系统行为
1.管理员点击公告类型；

3.管理员进行点击修改；

5.管理员选择要修改的公告类型；
2.系统显示公告类型管理页面；

4.系统根据管理员的点击显示修改页面；

6.提交修改信息，操作成功；
备选事件流
2a. 如果该管理员没有权限进行公告类型管理，则需要进行验证或提示。
3a. 如果某个公告类型正在被其他管理员处理，则给出相应提示信息。
4a. 如果该公告类型已过期或不再符合时效性，则可以将其标识为“已失效”或者删除。

3.3 可行性分析
3.3.1 技术可行性分析
本项目开发组，经过审慎思考，选择基于 MVC（Model-View-Controller）下的Springboot rest framwork 框架，使用 C/S 和 B/S 混合架构。本系统使用IDEA开发工具，开发技术采用目前流行框架，前端使用react.js框架，后端使用Springboot rest framwork Boot框架搭建，数据存储使用MySQL数据库，页面通过HTML5展示，并使用目前主流的前端技术react绘制前端界面的业务逻辑。
开发团队具有该每日鲜牛奶订购系统开发的能力，熟悉商家内部流程，开发出的系统考虑了商家、行业、商品的特性，更能满足商家的需求。
因此，在技术上是可行的。
3.3.2 经济可行性分析
商家自主开发，需要支出的费用比较少。硬件上，商家需商家一套本地服务器设备（含机架器、硬盘、机柜等），共需5-6万元。用户可使用商家所配的办公电脑，无需额外购买电脑等硬件设备。软件上，开发团队会开发并实施该系统，不需要向外支付费用。IT团队为现有的商家用户，无需增加额外的用户。后期系统维护、更新，也将由开发团队负责，无需对外支付费用。
综上所述，在经济上也是可行的。
3.3.3 营运可行性分析
商家在营运该管理系统上，IT团队用户开发并完成单元测试、系统测试；在系统整体测试期间，各相关部门选派代表用户参与测试，模拟正常使用情况，输入各种数据，并进行实际的操作。IT团队利用此机会，调试系统，对用户进行培训，同时收集问题点，进行相应的改善；在系统试运行期间，商家和用户开始使用该系统。根据以上计划，商家在各个方面各个环节都为该管理系统做了相应的准备，可确保系统平稳上线和运营。
3.4 开发模型
瀑布模型是最早期的一种软件开发模型，瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，每个阶段又可以用上一个阶段的工作结果作为工作的基础，如同瀑布流水逐级下落，因而成为软件开发和维护过程中一种非常有效的方式和方法[15]。但是这种开发方法也存在很大的问题和弊端，也就是说前期开发出现的问题再后期进行改正会为此支付高昂的费用[16]。
在实际的软件项目中存在着许多不稳定因素，例如，开发中的工作疏漏或通信误解；在项目实施中途，用户可能会提出一些新的要求。为了解决这些问题，考虑到许多实际项目中阶段之间有通信的需要使瀑布模型带有信息反馈环，能够逐级地将后续阶段的意见返回，并在问题解决之后，再逐级地将修正结果下传。原型在螺旋模型当中的作用主要是为了降低风险，相比较而言最重要的是，它能够让圆形方法应用于在产品演化当中的任何阶段。螺旋模型很像我们高中时候学习的四象限它分为制定计划，风险分析，实施工程和客户评估阶段，整个螺旋模型通过风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。螺旋模型同样有一些缺点，假设这个业务有一定的风险问题，但又没能够有效的发现，造成重大的损失也是在所难免的。由于这些问题的存在，后来的研究者开发了快速原型模型，使用者在软件计划时期可以选择快速开发模型。快速原型模型的特点是快速设计，快速原型模型存在优越之处，其加强了对处理模式的描述能力。此外，在资源管理、配置管理、系统确认和验证等多个方面均可以进行很好的控制，这样使得快速模型被广大计算机开发者所采用。

2 系统设计

4.1 系统架构设计
本系统的开发基于 B/S 体系架构。表现层是用户能直接看到的界面，即为网页浏览器所呈现的界面，既不负责处理业务逻辑也不需要储存数据。系统中所有的持久数据都将存储在数据库中，而数据访问层便是主要负责数据库的操作，数据库作为后台系统必不可少的模块，他的稳定性至关重要。业务层是B/S系统的核心，它负责根据业务规则来处理相应的业务逻辑，并且将所处理的结果传递给通过数据访问层保存，在数据交换中起到了承上启下的作用。本系统的总体架构图如图3-6所示。

图 3.6 系统架构图
4.2 功能结构设计
系统的可扩展性。考虑到用户的需求会不断的变化，相应的功能也会发生改变，因此灵活的系 统配置也是很重要的，系统采用模块化设计和结构化的开发[22]。软件系统开发专业技术性很强，涉及很多方面，需要有科学的方法和工具来辅助。
图4.1即为设计的管理员功能结构，管理员权限操作的功能包括管理商家，管理商家星级信息，管理用户，管理商品等。

图4.1 管理员功能结构
图4.2即为设计的商家功能结构，商家权限操作的功能包括管理商品，回复商品评价，管理商品订单等。

图4.2 商家功能结构
图4.3即为设计的用户功能结构，用户权限操作的功能包括查看商家，购买商品，提交订单，管理商品订单等。

图4.3 用户功能结构
4.3 数据库设计
4.3.1 数据库概念设计
在每日鲜牛奶订购系统模块分解之后，我们进行数据库设计，用来存储各种数据，满足应用系统和用户的各种需求。
本文采用ER图（实体-联系图）来建立该信息管理系统的概念模型，依据转换规则转换成关系模式，然后创建相应的数据表来存储数据记录。如图3-5所示。

图3-5 实体-联系图
（1）图4.4即为商品这个实体所拥有的属性值。商品有商品类型，商品现价，商品名称等。

图4.4 商品实体属性图
（2）图4.5即为商品订单这个实体所拥有的属性值。商品订单有订购数量，订单类型，收货地址等。

图4.5 商品订单实体属性图
（3）图4.6即为商家这个实体所拥有的属性值。商家有邮箱，营业执照，商家星级类型等。

图4.6 商家实体属性图
图4.7即为用户这个实体所拥有的属性值。用户有牛奶号，电子邮箱，用户头像等。

图4.7 用户实体属性图
图4.8即为上面介绍的实体中存在的联系。

图4.8 实体间关系E-R图

3 系统设计

5.1 管理员功能实现
5.1.1 公告信息管理
图5.1 即为编码实现的公告信息管理界面，公告信息包括了公告图片，公告类型，公告标题等，管理员在公告信息管理界面中可以对界面中显示的所有公告信息进行更改，查询，删除。

图5.1 公告信息管理界面
5.1.2 用户管理
图5.2 即为编码实现的用户管理界面，用户信息有性别，用户牛奶号，用户身份证号，用户头像等信息。管理员在用户管理界面中可以为本界面显示的所有用户信息进行查询，修改，删除，可以为用户的账号进行重置密码。

图5.2 用户管理界面
5.1.3 商家管理
图5.3 即为编码实现的商家管理界面，商家信息有营业执照，商家星级类型，商家名称等信息。管理员在商家管理界面中新增商家，更改商家的营业执照，商家星级信息等，可以删除需要删除的商家信息。

图5.3 商家管理界面