springboot019食品安全管理系统(vue)

发布时间 2023-12-19 22:49:49作者: canccg

image



1  绪  论

1.1 课题研究背景及意义

1.2研究现状以及发展趋势

1.2.1研究现状

1.2.2发展趋势

1.3研究目标


2 相关技术介绍

2.1 Spring Boot介绍

Spring的全家桶,我想在Java开发领域大家都知道了吧,那么关于spring的框架,自从我们大学都开始学的,Java语言在基础知识当中不会涉及到框架,但一旦学到J2EE的时候,就一定会存在框架的整理。那么对于框架当中,Spring boot是目前最好用、最实用的一个Java框架,同样Spring Boot也是框架当中的一种。和其它框架相比而言它更加方便、简单,能够让开发者很加方便快速的熟悉Spring 框架的来龙去向。微服务是近些年来比较火热的架构方式,很多企业级的JAVA应用都会根据Spring Boot和Spring Cloud进行构建微服务。Spring Boot比起Spring框架来说更多的是资源的整合,它并不是一种全新的东西,而是在原有的基础之上进行了一些整合式的改动,可以让开发者变得更加方便。以前,对于java应用来说都需要进行tomcat的配置,但是有了Spring Boot之后它直接将tomcat内置,很多功能通过yml进行简单的配置即可,而且还去掉了让开发者非常头疼的XML,总而言之就是在框架的基础之上给开发者带来更多的便利。 不仅仅是这样的,那么关于spring boot也可以和其他框架进行一个融合,那么spring boot也代替了一些约定,成熟的规矩,比如说约定大于配置等等,这些都是我们开发者比较喜欢的。

2.2 IDEA简介

要说起工具,大家会介绍很多各种各样的工具,那么对于开发者来说,它的开发工具是他吃饭的一个根本就像筷子一样,在详细说明IDEA之前,首先对它进行一个全范围的大概说明。IDEA是一款功能强大的开发工具,它之所以定义为能称得上为一款强大的工具,就是因为我们的开发人员对于它的依赖程度实在是太过于强大了。功能强大的工具肯定是要比简陋的工具有意义,就像自行车和火车这两种交通工具来比速度一样,在IDEA的操作页面里不仅会有操作符的提示功能,还会有各种类或者方法的定义规范说明等等。当然就目前而言可能我们在学习某种语言的过程当中可以通过记事本工具来进行学习,但是如果到了真正项目上的话必然是需要这样一款强大的功能,它可以把软件全生命周期相关的组件工具集成进来,形成软件行业所特有的devops(开发、运维一体化)。Idea也有很多开源性的插件都可以供我们使用,但唯一不足的是我们如果使用的话,正式的商业版是需要付费的,如果自己找网上破解当然也可以实现,那么就需要我们隔一段时间进行一下破解。

2.3 MySQL数据库

今天信息化的发展,一是离不开语言开发技术,二就是离不开数据库的技术当然开发语言参差不齐,各种各样百花齐放,那么相对于数据库也是各种各样的都有。国产的、国外的、各种性能的、易用的。应用程序在其开发过程当中绕不开的就是数据的存储,一般情况下会将数据分为两种;一种是关系型数据库,另外一种那就是非关系型的了。今天我们所要介绍的就是关系数据库当中的一种——MySQL数据库。MySQL数据库经过了N多年的发展,已经成为了世界上主流数据库的一种。它的简单易学让每一位开发人员深深的喜欢上了它。当然仅仅只是这样还不够,它的强大功能也是一方面的体现。能够让每一位开发者喜欢的原因。如果仅仅他简单而言实现不了太多功能,其实在日常的开发中也是不够的,MySQL数据库正是拥有这两方面的特点:简单以及功能强大,所以他给开发者带来的感触是非常深的。

2.4 JAVA语言介绍

JAVA语言是一门家喻户晓的语言了吧,传统的一些JAVA历史和指标就都不需要进行一一的介绍了。JAVA语言之所以能够让这么多的开发者喜欢主要还是因为其开源、市场份额大。另外在语言的发展史上JAVA也是历史非常悠久的了,从SUN公司一直到Oracle JAVA语言也在一路上不断的完善和扩展,目前市面上用的比较广泛的还是jdk1.8 虽然说jdk17都已经有了,但成熟稳定而言还得是jdk1.8,更有甚者1.7和1.6都还在使用。我们本次的设计语言方面还是要考虑开源、功能强大。最主要的还要是大学里面所学习的,我们可以通过老师、同学来取得相关知识。同时,java的JVM还能够根据我们的需要在不同的平台上进行运行,这一点来说就可以干倒相同的只能在Window上部署的语言等。

3 需求收集与分析

3.1 系统开发框架

食品安全管理系统其实也是中小商店的一种进销存管理系统,那么只要是系统都会从开发开始进行一个框架,那么有架构设计和开发框架两种方式。系统开发框架呢,是通过开发框架将系统的一步一步实现的过程进行一个整理。系统的开发架构图主要描述的是在系统实现过程中我们所能做的开发架构,开发架构不仅仅简单,只是几张技术图表以及可扩展性的描述即可。他从开发的最低层基础层的基础技术体系进行一个罗列介绍,最终通过数据将数据呈现给用户作为介绍。那么此次涉及的开发架构当然是从需求调研的业务领域进行一个总体设计,通过数据架构和功能架构的整体罗列分析。我们从系统开发架构图中可以通过一个需求调研初步设计和详细设计以及完工维护等几个阶段,纵向和横向通过不同的实现来完成系统开发架构图。如下所示:

wps16

3.2 系统功能需求分析

食品安全管理系统功能主要是通过不同角色来进行区分的,分为用户和后台管理者。如下图所示:

wps17

3.4 可行性分析

3.4.1 经济可行性

经济可行性是写论文第一要素,为啥在介绍idea工具的时候就会提到是否商业版,商业版就是要收钱的,那么我们选择语言也是考虑是否是收钱的还是开源的,那么同样这就是经济可行性的一个衡量指标。无论是做项目也好,承担毕业设计也好。一定是在经济可行性允许的条件下进行实施,如果说要。采购的软硬件设备的费用会很高很高,那么确实不适合经济可行性。还好,在本次设计中,我们采用了B/S的浏览模式,在经济上只需要一台电脑当作开发环境和部署环境即可,先开发在这台电脑上,开发完成后继续在这台电脑上进行一个部署。那么这样一来的话,我们可以通过浏览器访问,在经济上就没有什么压力。

3.4.2 技术可行性

经济可行性是第一要素,那么技术可行性就是第二要素了,那么技术可行性是关于系统能不能实现的一个重要标准,别我们选一门技术语言,很多业务功能实现不了,那这样技术可行性不行的。而我们在大学中所学的语言也是主流的语言,比如说对于后台语言来说有PHP 、Java等,对于数据库来说有MySQL、SQL server等,这些都是在大学当中平常的课程,所以在技术方面。我们所接触的是主流开源技术。如果一旦遇到了。技术上有不懂的问题,那么也可以通过互联网或者是其他同学得到帮助,这样一来,技术上完全是可行的。

3.4.3 操作可行性

操作可行性方面就是要考虑用户的习惯了,那么什么样的设计可能让用户感觉头疼,什么样的设计又能让用户感觉友好程度很高呢。这就需要我们在操作可行性上有所体现。所体现出来的。就目前而言,市面上所有BS的应用来说,布局方式、操作方法都是常见的那几种,所以我们只需参考他人成功的经验即可。在操作上,只要不做出任何奇形怪状的操作,那么对于操作可行性来说是完全没有问题的。

3.4.4 法律可行性

软件设计的可行性中有许许多多。其中最常见的一种可行性就是法律可行性。法律可行性呢,通常是指的软件儿在法律条件下的设计可行性。比如说我们设计一款软件,首先是要对他的思想或者是解决的社会问题进行一个能量型的考核,如果是他对社会性的问题,带来一些负能量的话,这种软件通常是法律可行性是不通过的。对于我们本次而言呢,其实市面上已经存在了,这样许许多多行业当中非常优秀的软件。我们只是仅仅通过一个细节的扩展,来去满足我们本次的毕业设计。所以法律可行性方面我们是一定符合法律可行性的。

3.5 性能需求分析

我们都知道,一个好的系统不仅仅要考虑业务功能的实现,而且要考虑系统的性能,别在十个并发用户下和20个并发用户下可以用,等到业务量扩展50并发用户下就不能用了,那么系统的需求分析也就没有达到,性能需求这个词在一些软件系统中才有需要,并且还会有很多衡量性能需求的指标来进行判断,比如我们经常听到的并发数,或者在线人数等等,这些都是用来对性能需求分析进行体验的。除了这些以外,还有一些指标往往和页面访问时间或者数据查询请求时间来进行对比的,比如说在系统开发初期就会有些性能指标注明,统计性页面请求时间不超过几秒,非统计性页面请求不超过几秒等等。虽然在用户看来这些请求指标他们并不懂,但对于开发来说这些是衡量一个系统实力好坏的重要体现啊。所以我们在做系统的时候,也应该和用户聊清楚需求,在他们有一定业务增长量的情况下,能盖得住他们的性能需求。

4 数据库设计

4.1 E-R图

管理员信息属性有:用户名、密码、编号。如下图所示。

wps18

用户信息属性包括:编号,姓名,性别,年龄,电话,邮箱,地址,身份证号。具体如下图所示。

wps19

服务信息

wps20

wps21wps22wps23wps24

wps25wps26wps27wps28wps29

4.2 系统流程设计

系统的数据添加是有相关的验证的,并不是说谁想增加都可以增加,而且也不是每一种数据都可以随随便便的加进数据库当中,系统一旦有了数据的验证,我们还要进行的就是数据合法性的一些检查,比如说数字不可以输入字符串啦等这些常见的问题验证。如下图所示:

wps30

由于我们这次毕业设计所设计的不是一些商业数据,所以对其数据的删除做的是真正的物理删除,并不是将一个数据标记成一个状态,查询不出来,实际在后台都能存在的逻辑删除。所以在做物理删除的时候,首先要选择要删除的记录,那么还是操作流程进行一个删除,删除之后进行更新数据库。

wps31

4.3 数据库设计

经过前一阶段的E-R图设计之后基本上整理出来各实体之间的关系及属性字段情况,为进行了下一步的数据库设计有了更深层次的递进。数据库表的设计直接形式就是影响着系统功能的一个重要组成部分。各个表当中在形成表时严格按照E-R图来进行实现,避免形成冗余字段及数据行。现将其中的一些数据表总结如下。具体的设计数据表如下所:

Alluser表

字段名

类型

是否为空

长度

描述

ID

Int

否增编号

10

ID

name

VarChar

255

姓名

sex

VarChar

255

性别

Age

Int

10

年龄

sex

VarChar

255

sex

birthday

Date

255

出生日期

phone

VarChar

255

电话

address

VarChar

255

地址

Bz

VarChar

2000

备注

News表

字段名

类型

是否空

长度

描述

ID

Int

10

ID

name

VarChar

255

标题

newsType

VarChar

255

类型

author

VarChar

255

作者

makeTim

Date

255

创建时间

maker

VarChar

255

创建人

modiTime

VarChar

255

修改时间

products表

字段名

类型

是否空

长度

描述

ID

Int

10

ID

name

VarChar

255

名称

products

VarChar

255

品号

author

VarChar

255

作者

Back

VarChar

255

备注

Pepole

VarChar

255

使用者

makeTime

VarChar

255

创建时间

5 系统功能实现

5.1 系统实现

5.1.1 首页

在食品安全管理系统当中,不仅有首页,也有后台管理,那么首页就是能够让用户看到的界面。用户看到的界面要除了功能齐全之外,还要美观美丽。当然管理者可能不需要很美观,但用用户要看起来整整齐齐,舒服才能用的起来系统。如何能够让使用者一下就记住自己开的系统呢?首先要做的就是能够在首页让用户停留住,只有能够吸引到用户,那么用户才能进行详细的功能查看,把查看的功能也进行一一整理可以清清楚楚的认识到我们所要做的系统的样子。这样一来就能够把首页的主题突显出来了,如下图所示:

wps32

5.1.2 后台登录

用户的前台登录和后台登录完全不一样,后台登录是管理者来看数据的,要有一个入口,那么也要通过后台登录的用户名、密码来进行一个判别,当然还需要提供一个权限,是系统管理员还是供应商,这都是不一样的,食品安全管理系统都有详细的介绍。为了能够提供更好的后台管理功能,在后台管理入口处也进行了相关的管理员登录,通过账号、密码以及不同的管理权限来进行登录,风格上还是按照简洁的风格进行设计调整,这样一来我们就可以和应用相对保持统一。在UI风格上也是从一个应用中分离出来的登录页面。黄色的风景画页面能给人一种舒服的感觉,所以在登录页面中背景图选择了树叶儿。如下图所示:

wps33

5.1.3食品信息添加页面

食品安全管理系统中最重要的一个管理环节就是食品信息的还。那么在这个环节当中,我们不仅能够添加食品的信息,也能够进行一个简单的介绍,当然为了能够更加清楚,还做了一个附件关于食品图片以及价格的上传,这样一来可以清楚明了的把食品进行一个添加。任何信息系统都具备的功能就是信息的添加,如果没有了信息添加那么相对就没有了信息入口,这样的系统应用起来是完全没有什么意义的,本次设计呢也还是将这些添加信息的页面单通过功能来做出来,在信息的添加页面不仅仅只是看到的这些属性,还有一些暗藏的验证规划,只能都通过了才能进行保存。如下图所示:

wps34

5.1.4食品查询

查询的时候,为了能够清楚的看到,我就用了列表的形式,列表的形式中,列表的表格是食品的属性,这样有很多不同的属性就可以一目了然。当然能够操作的按钮我也用不同的颜色进行了区别,这样很快就可以看到。在信息的添加页面当中,除了一些必要的。属性之外还是提供编辑和删除的功能,同时也支持当数据量大时进行一个模糊搜索以及类别搜索,这样一来管理人员可以快速的定位到想要找的数据。如下图所示:

wps35

5.2 代码实现

5.2.1 食品添加代码实现

在上一个章节讲了许许多多系统的实现,那么这个章节就讲一下代码的实现,同样,前后台的代码形式也是通过不同的方式来实现的无论前面的业务的复杂程度是什么,到了后台代码阶段无非就是从上下文当中进行查询和保存,如下图所示:

wps36

5.2.2 查询信息代码实现

查询出来的属性是通过数据库再反馈给代码,代码进行编辑,再反馈给表格,能够让我们用户看到,在查询中进行直接赋值页面中就可以查到。如下图所示:

wps37