【《应急救灾物资采购子系统的设计与实现》15000字（论文）】

应急救灾物资采购子系统的设计与实现目录摘要 1第1章 绪论 41.1课题研究背景和内容 41.1.1研究背景 41.1.2研究内容 41.2国内外研究现状 41.3论文组织架构 5第2章 相关技术及开发环境 72.1Java语言 72.2SpringBoot+MybatisPlus框架 82.2.1SpringBoot 82.2.2MyBatisPlus 82.3MySQL数据库 82.4Redis缓存 92.5Vue+PrimeVue 92.6技术线路 10第3章系统分析 113.1系统总体需求 113.2系统功能性需求 113.2.1用户登录模块 123.2.2首页模块 133.2.3基础信息查询模块 143.2.4采购用户管理模块 153.2.5供应商管理模块 163.2.6物资采购模块 183.2.7采购计划管理 193.2.8采购订单审核模块 203.2.9订单查询模块 213.3系统可行性分析 223.3.1技术可行性 223.3.2经济可行性 223.3.3时间可行性 233.3.4操作可行性 23第4章系统设计 244.1系统总体设计 244.1.1系统三层架构 244.1.2 系统开发模式 244.2系统功能设计 244.2.1登录模块设计 244.2.2 首页设计 254.2.3 基础信息查询模块 264.2.4 采购用户管理模块 264.2.5 供应商管理模块 274.2.6 物资采购模块 284.2.7 采购计划管理模块 284.2.8 采购审核模块 294.2.9 订单信息查询模块 294.3系统数据库设计 304.3.1数据库ER图设计 304.2.10 数据库实体设计 31第5章系统实现 375.1系统前置功能实现 375.2用户登录模块实现 385.3用户登录状态的保持 405.4基础信息查询模块实现 415.5采购用户管理模块 435.6供应商管理模块实现 445.7采购模块 455.8采购计划管理模块实现 475.9订单管理模块 49第6章系统测试 516.1系统测试目的与测试范围 516.2系统测试方法 516.3系统测试用例 516.3.1登录模块测试 516.3.2采购模块测试 526.3.3后台管理模块测试 526.3.4采购计划管理模块 536.3.5订单审核模块 54第7章总结与展望 55摘要 随着科技的不断发展和进步，人们的生活质量也在不断的提高，在面对一些小型的自然灾害的时候，可以通过一些人为干预的方式来降低灾害带来的损失或者直接消除灾害。但是在面对大型的天灾的时候，人类显得还是如此的渺小。2021年7月20日，河南中北部出现特大暴雨，郑州、开封、新乡等地日降雨量突破历史极值，各地出现严重的洪涝灾害，因灾失踪死亡398人，造成的直接经济损失高达1200.6亿元。 为了在发生大型地质灾害的时候能够迅速分配应急救灾物资，并且可以通过各地的不同受灾情况分配不同的物资，救灾应急物资系统应用而生，本毕业设计是应急救灾系统中的采购子系统的设计与实现。 该系统大致上分为两个部分：管理员模块与普通用户模块。管理员登录以后可以进入管理员的用户界面，进行采购人员的管理、供应商管理、以及订单审核等。同时管理员也可以查看一些基础的信息，包括仓库信息和商品信息以及库存信息等。普通用户登录后进入普通用户的界面，进行基础信息查看、生成采购计划、提交采购计划以及查看采购订单等。 本系统的开发使用B/S架构，进行前后端的分离。后端使用SpringBoot+Mybaits-Plus，前端使用Vue以及PrimeVue。数据库使用MySQL。使用Redis实现分布式Session用于保持用户的登录状态。系统开发完成后经过测试，功能均可正常使用且符合软件的健壮性。 关键词：采购；Java；Vue；SpringBoot；MybatisPlus；MySQL 绪论1.1课题研究背景和内容1.1.1研究背景随着科技、经济的不断发展与进步，人类的社会正在发生翻天覆地的变化。尽管人类的科技水平已经到达很高的造诣，但是在面对各种天灾人祸的时候人类显得还是如此的渺小。2019年12月底，一种新型的冠状病毒在人类社会中蔓延开来，并迅速扩散到世界的各个角落。截止至2022年5月，全球累计确诊人数高达5亿人，累计死亡人数达600万人[1]；2021年7月20日，河南中北部出现特大暴雨，郑州、开封、新乡等地日降雨量突破历史极值，各地出现严重的洪涝灾害，因灾失踪死亡398人，造成的直接经济损失高达1200.6亿元[2]。在面对这样突如其来的疫情和灾难面前，人们所做的准备往往是不足的，例如在新冠肆虐期间，口罩库存不足，导致口罩的价格一度疯涨，甚至需要政府出面干涉。其中的缘由主要是在突如其来的灾害面前，人们所做的物资准备是不足的，而且对于不同区域的不同受灾情况分配的物资资源也是不均衡的。因此建立一个现代化的应急物资管理系统迫在眉睫，本系统是应急救灾管理系统中的采购子系统。1.1.2研究内容本系统作为采购系统，目的在于采购仓库里面不足的、需要的、即将过期的应急救灾物资，从而在突发灾难来临之时可以保证应急救灾物资的库存充足，可以随时调配到需要应急物资的受灾地区。本系统的主要角色分为普通采购人员和采购管理人员，普通采购人员可以查看仓库内物资的库存情况、过期情况等，也可以查看物资的供应商，按照物资的库存提出采购需求，将需求加入到自己的采购计划中，然后按需提交自己的采购计划，同时采购计划也可以导出为报表供上级签字查看，采购计划提交后会生成订单，订单在管理员审核通过后方可进行拨款采购。管理员负责管理所有的用户信息、供应商信息以及进行采购计划的审核，审核成功后该订单方可作为采购的原始依据使用，审核不通过需要说明理由，审核之后采购人员可以查询到自己订单的审核信息。1.2国内外研究现状随着社会的发展，企业的采购需求相比于过去增加了很多，同时，企业的采购模式也从传统的比价采购、询价采购、招标采购等演变成现代的战略采购和电子采购等。传统方式采购的缺点在于采购方和供应商的信息不平衡。在传统的采购过程中，采购方为了能从多个不同的供应商中选择一个最好的，往往会隐藏一些自己的信息，因为自己的信息暴露的越多，供应商的竞价筹码就越大，这对采购方是不利的，而且在不同的供应商竞争之下，供应商也会隐藏自己的信息，最终导致双方信息不平衡，无法进行有效的沟通。现代的战略采购模式和电子采购模式可以改变这一局面，战略采购是整合公司和供应商战略目标和经营活动的纽带，可以避免传统采购中采购方由于信息缺失导致在整个采购流程中处于劣势的局面。而电子采购则可以让众多供应商进行公平的竞争，电子采购允许用户查询买卖双方的商品以及服务信息。通过这种方式，买卖双方可以进行价格的制定或者物资的招标。在这个全新的采购模式下，买主和卖主通过互联网连接，其优势是显而易见的。美国在1761年就颁布实施了《联邦政府采购法案》，经过200多年的发展，美国已然是全球政府采购制度最完善的国家。在这段时间里，美国不断颁布新的法律法规来规范自己的采购行为。此外，为了在技术上保证采购中的竞争、公开、公平原则，美国在各个州、政府采用以网络技术为中心的管理方法，这间接的促进了供应商间的公平竞争，提高了政府的采购质量。1.3论文组织架构本论文包含软件开发的流程，主要分为以下七个章节：第一章：本文第一章节为绪论，对应急物资采购系统进行了背景研究、国内外现状研究，对本系统进行一个初步的了解，确定了系统的内容。第二章：此部分为相关技术以及开发环境介绍部分，主要对系统开发中的前后端框架、数据库、中间件等进行介绍。第三章：本章节为需求分析部分，分析用户需求，进行系统的性能分析。最后对系统进行可行性分析。第四章：本章节为系统设计部分，进行数据库表的设计，系统的总体设计与各个模块的设计。第五章：本章节为系统实现，根据用户需求进行详细的系统实现。第六章：本章节为系统测试，在系统实现以后对系统进行测试，主要采用黑盒测试的方法。第七章：本章节为总结与展望部分，对系统现有功能进行一个总结，分析其不足之处，再规划系统下一步优化方案。相关技术及开发环境2.1Java语言在当前的主流开发语言中，热度高的有python、C++、Java，三种语言的侧重方向也不尽相同：python得益于其强大的三方库，多被用于数据处理、深度学习、人工智能等方面的开发；C++作为一门偏向于计算机底层的语言，多被用于服务器的开发、硬件开发以及一些游戏引擎的开发；Java作为一门面向对象的语言，得益于Spring等框架，使其在web领域有着较为广泛的使用。Java语言特点：面向对象面向对象是编写大型程序时控制程序复杂性的重要手段，Java在面向对象方面要比C++做的更加完善，它的所有数据类型包括基本数据类型都有其相应的包装类，也就是说Java程序可以完全基于对象来编写。强类型Java语言是一种强类型的语言，其可以约束程序员在编写代码的时候遵守更多的编程约定，也可以让编译器检测出更多的错误。与平台无关Java与平台无关的特点保证了Java程序的可移植性，Java保证其可移植性的最主要的措施是定义了JVM虚拟机以及Java的字节码。无论是在哪种平台上，Java程序都会被编译为JVM可以识别的字节码文件，这样只要有JVM的平台就可以运行Java程序。内存回收与C++指针不同的是，Java程序员无法手动操作内存，这也是Java程序很少由于内存崩溃的原因。JVM会自己维护一个垃圾回收器，自动回收程序中不再使用的内存。这样可以避免在显示的撤销内存分配时带来的安全问题。多线程多线程是Java的灵魂所在，线程是一种比进程更小的可并发执行的单位，协同工作的线程可以共享内存和资源，线程直接相互切换消耗的资源要远远少于进程直接消耗的资源。Java的运行环境是多线程的，JVM可以在系统空闲时间进行垃圾的回收。此外，Java也支持语言级的多线程，使用Java可以直接编写多线程程序。2.2SpringBoot+MybatisPlus框架2.2.1SpringBootSpringBoot是Pivotal团队以Spring为基础开发的一套全新的开源框架，其目的是为了简化Spring应用的开发和搭建流程。SpringBoot拥有Spring的一切特性，Spring能做的事情，SpringBoot都可以实现。而且SpringBoot集成了大量的第三方库，这些第三方库几乎可以是零配置的开箱即用。SpringBoot的出现大大简化的Spring的繁琐配置，使开发者能够更专注于开发业务逻辑。SpringBoot特性：可以独立运行：通过Maven可以打包成Jar包，使用java-jar命令即可直接运行内嵌Servlet容器：SpringBoot使用嵌入式的Servlet容器（本项目使用内嵌Tomcat），应用无需打包为war包完全抛弃xml配置：不需要任何xml文件即可完成SpringBoot项目的配置开箱即用：提供了一系列stater启动器，简化了Maven配置2.2.2MyBatisPlus MyBatisPlus是一个MyBatis的增强工具，在MyBatis的基础上只做增强不做改变，为简化开发、提高效率而生。相比于MyBatis，其提升最大的点在于强大的CRUD操作：MyBatisPlus内置了通用的Mapper、Service，通过很少量的配置即可以实现表单的大部分CRUD操作，而且有更加强大的Wapper（条件构造器），可以满足各类的使用需求。其内置的性能分析插件可以输出SQL语句以及执行时间，可以让开发人员快速的找出慢查询。其内置的分页插件基于MyBatis的分页插件，在配置完成以后，开发者写分页查询如同普通的List查询。总而言之，MyBatisPlus的使用让开发人员省略了大部分书写SQL语句的时间，大大提升了开发的效率。2.3MySQL数据库MySQL是数据库管理系统中的一种，是市面上最流行的数据库管理软件之一。MySQL是oracle旗下最流行的关系型数据库之一。与非关系型数据库相比，关系型数据库将数据保存到不用的数据表中，每个表中的数据对应着Java中的实体类，大大提高了程序的灵活性。此外，MySQL对于数据的搜索做了大量的优化，最为主要的优化是引入了索引，MySQL支持多种索引，在数据量十分庞大的时候也可以快速查找到需要的数据，其查找效率接近于二分查找。另外，MySQL免费且可移植性高的特性也是本系统使用其的主要原因。2.4Redis缓存不同于MySQL，Redis是一种No-SQL的非关系型数据库，Redis不存在表的概念，数据是以键值对的形式存储的。此外，Redis是直接运行在内存上的数据库，因此，其IO速度要比运行在磁盘上的MySQL快的多。但是由于其运行在内存上，存储空间有限，所以Redis常常被用作缓存来保证MySQL的安全。本项目使用Redis主要是使用其键值对的过期策略来实现分布式Session，以此保证用户的登录状态。2.5Vue+PrimeVueVue是一套用于构建用户界面的JavaScript渐进式框架。Vue的核心只关注视图层，不仅容易上手，还便于与第三方库或者现有项目整合。其通过双向的数据绑定和虚拟的DOM技术，帮助前端开发人员处理了开发中最为繁琐的DOM操作部分，让程序员不再去考虑如何操作DOM以及如何最高效的操作DOM，大大加快了开发效率。由于路由的引用，使用Vue开发的应用为单页面应用，即只有一个Web页面，在用户与应用程序交互的时候动态更新该页面。单页面应用的优点在于用户体验好，整个交互过程都是使用axios异步交互，用户不用刷新页面即可看到不同的页面效果以及适合前后端分离项目的开发，后端提供接口，前端通过http请求获取数据，设计用JS对客户端进行动态渲染。PrimeVue类似于Element-ui，是基于Vue3的一个免费开源组件库。PrimeVue提供了众多的组件，大大方便了前端页面的开发效率，其后台管理模板做到了开箱即用，只需要进行很少量的修改便可以上手使用。PrimeVue与其他的UI库不同，它是一个与设计无关的库，并不强制使用某种样式，而是通过其内部的core和theme由用户自定义前端样式。2.6技术线路本系统使用前后端分离架构，前端使用Vue，开发工具使用VSCode，后端使用SpringBoot以及MyBatisPlus，使用IntelliJIDEA进行开发，同时使用Maven构建和管理项目。数据库采用MySQL，使用Navcait对数据库进行可视化操作。为实现用户状态的保持，使用Redis实现分布式Session。第3章系统分析3.1系统总体需求在实现本系统前，首先对本系统进行需求分析，确定要实现本系统所需要的功能模块都有什么。进行需求分析是设计一个项目的开端。在需求分析的过程中，首要考虑的是用户的需求，只有在确定了用户的需求之后才能对项目进行设计与实现。随着社会的发展以及近几年出现的疫情等因素，人们对应急救灾物资管理变得更加重视。为了能够在各种突发灾害到来之时做出及时的反应，以将损失降到最低，因此进行了本次应急救灾物资采购子系统的研究。经过查阅文献，结合各地应急救灾物资系统设计的经验，本次系统设计的首要任务是系统可以正常运行，满足各种基本的系统需求。其次是对系统功能方面进行更加细致的划分，根据对各行业采购系统的调查与分析，完成本系统的功能设计，并加以各种细节上的优化。3.2系统功能性需求本系统可以根据系统角色划分为俩部分，其一是采购人员部分，其二是采购管理员部分。根据不同角色角度出发，进行本系统的需求分析，大致得出本系统的需求分析有如下几个方面：图3-2应急救灾物资采购子系统功能概览图3.2.1用户登录模块用户登录模块是一个系统中最为基础且安全性要求最高的模块。此功能模块是系统中最基础的一部分，后续所有功能模块的使用的前提是保证了用户的登录状态。表3-2-1用户登录模块编号L0001需求描述物资采购系统的登录角色采购人员、管理员输入账号、密码输出登录结果正常流登录成功:跳转到首页登录失败:返回错误信息并提示用户v异常流账号为空密码为空账号不存在特殊需求登录后需要保持用户的登录状态，在下次访问页面的时候无需登录即可进入首页并获取到当前用户的信息图3-2-1用户登录模块3.2.2首页模块在管理员和普通用户进入首页后，可以看到的是最近的二十条订单信息以及所有订单的审核情况，包括审核率等。管理员可以查看所有的订单信息，采购人员只能查看自己已提交的订单信息。管理员查看的是自己对所有订单的审核情况，采购人员查看的是自己订单的审核情况。其中审核情况使用图表来实现。表3-2-2首页模块编号L0002需求描述管理人员和采购人员进入首页后看到最近订单以及审核情况；根据身份的不同所看到的数据也不同角色管理员、采购人员输入无输出最近的订单信息；订单审核图表；订单审核率正常流用户进入系统后看到正确反馈的数据异常流查看到的数据为空；图表显示不正确特殊需求无图3-2-2首页模块3.2.3基础信息查询模块登录系统后，首要查看的就是仓库的基础信息，然后根据基础信息进行采购。由于本系统只是物资管理系统中的采购子系统，因此无论是管理员还是普通用户都没有权限对仓库中物资的库存信息等进行修改、增添和删除。等到采购完毕以后，入库模块会相应的对仓库进行修改。表3-2-3基础信息查询模块编号L0003需求描述用户登录后对仓库信息、仓库库存信息、物资信息、供应商信息进行查询角色采购人员、管理员输入无输出返回对应的查询结果正常流对查询操作做出正确的反馈异常流查询失败用户未登录特殊需求无图3-2-3基础信息查询模块3.2.4采购用户管理模块本系统的角色权限控制比较简单，仅有采购管理员和采购人员俩个角色。考虑到本系统作为应急救灾物资管理系统中的一部分，管理员应当由大系统中后台管理子系统统一分配。而普通的采购人员应该由管理人员进行添加而非自己进行注册。同时管理员有权对采购人员进行基本的增删改查操作，但是无权对管理员进行操作。表3-2-4采购用户管理模块编号L0004需求描述管理员对后台采购人员进行增删改查操作，包括重置密码操作角色管理员输入新增用户：输入用户基本信息删除用户：输入人员编号修改用户/重置密码：输入修改后的用户信息/直接点击重置密码按钮查询用户信息：打开查询模块即可查询，查询列表支持模糊查询过滤导出用户信息：选中用户，点击导出，即可导出excel文件输出反馈新增结果并刷新页面反馈删除结果并刷新页面反馈修改结果并刷新页面返回员工信息excel文件正常流根据输入的条件进行正常的反馈异常流新增员工信息失败（手机号重复）删除信息失败（用户已经不存在）修改信息失败查询用户失败（登录状态失效）导出excel失败特殊需求用户列表支持单行删除和批量删除图3-2-4采购用户管理模块3.2.5供应商管理模块考虑到采购供应商可能面临的各种问题，比如负责人更换或是供应商破产等，因此添加对供应商的管理模块。供应商的管理由后台管理员进行实现，普通用户只能查看供应商的基础信息。供应商的管理主要包含供应商的增删改查。表3-2-5供应商管理模块编号L0005需求描述管理员对供应商进行增删改查操作角色管理员输入新增供应商：输入供应商信息删除供应商：点击删除按钮即可修改供应商：输入修改后的信息查询供应商：直接查询列表，列表实现过滤功能输出反馈新增结果反馈删除结果反馈修改结果返回查询列表正常流根据输入的条件反馈信息异常流新增供应商失败删除供应商失败修改供应商失败查询列表失败特殊需求无图3-2-5供应商管理模块3.2.6物资采购模块采购人员进入系统后，根据仓库物资库存提出采购需求，其中包括采购的商品、单价、数量等信息。采购又会分为新物资采购和仓库现有物资采购俩种类别。新物资采购规定只能采购系统中已有的供应商的物资，现有物资采购是采购库存不足的、需求量大的、以及即将过期的物资。表3-2-6-1仓库现有物资采购编号L0006需求描述仓库现有物资采购角色采购人员输入采购的商品信息，采购数量等输出将采购物资添加到采购计划中正常流添加成功，在采购计划可以看到该采购项目异常流添加失败，采购数量为0特殊需求在采购的时候确保输入的采购数量是数字并且控制在一定范围内表3-2-6-2新物资采购编号L0007需求描述根据仓库需求采购新物资角色采购人员输入新物资名称、价格、保质期、类型、用途等新物资供应商输出采购成功，将采购项目添加到采购计划中正常流添加成功，在采购计划中可以看到该采购项目异常流添加失败，采购列表有字段为空或者类型不匹配特殊需求无图3-2-6物资采购模块3.2.7采购计划管理采购人员进行物资采购的时候，会先生成采购计划。在一次采购结束以后，采购人员可以提交其采购计划生成订单，让管理员进行审核。采购计划在未提交前支持删除、查询、添加，但是无法修改，可以进行批量删除。同时，采购计划支持按需提交以及导出采购计划报表供管理员线下签字审核。表3-2-7采购计划管理模块编号L0008需求描述采购人员添加采购项目到采购计划中采购人员删除采购计划中的一条或者多条项目采购人员提交采购计划，可以全部提交，也可以选择提交采购人员导出采购计划报表，可以选择项目导出，也可以全部导出输入新增计划：输入采购计划信息或者批量导入采购计划删除计划：点击删除或者多选删除提交计划：选择提交导出报表：选择导出输出新增以后在采购计划中看到相应的采购项目删除以后刷新列表提交以后刷新列表获得word报表文件正常流按照对应的操作得到对应的结果异常流新增或导入采购计划失败删除采购计划失败提交采购计划失败word文件未渲染数据特殊需求无图3-2-7采购计划管理模块3.2.8采购订单审核模块在采购用户提交采购计划以后，会生成采购订单以供管理员进行审核。审核通过以后方可进行采购，审核不通过则需要说明不通过的理由。提供批量审核通过以节省效率。表3-2-8订单审核模块编号L0009需求描述订单审核通过，可以批量通过订单审核不通过，需要说明理由角色管理员输入不通过理由输出审核结果正常流审核以后出现对应结果异常流提交审核结果失败特殊需求无图3-2-8订单审核模块3.2.9订单查询模块在采购人员提交采购计划以后，采购人员可以查询自己的采购订单，管理员可以查看当前系统中存在的订单。其中订单的信息包括了审核情况。针对未审核的订单，管理员可以对其进行审核。此外，查询到的订单支持导出。表3-2-9订单查询模块编号L0010需求描述订单查询，管理员查询所有订单，采购人员只能查看自己的订单角色管理员、采购人员输入无输出订单列表正常流获得对应的订单列表异常流获取列表失败特殊需求无图3-2-9订单查询模块3.3系统可行性分析3.3.1技术可行性由于本系统是一个web系统，后台开发首选语言为Java语言，Java是大学中需要学习的语言，再加上Java的开源技术框架，后台模块开发起来还是比较轻松的。本系统是一个前后端分离的架构，前端采用当前的热门前端框架Vue，采用PrimeVue组件库，可以快速搭建好前端的界面。在软件方面，后端开发使用IDEA，前端使用VSCode，数据库采用MySQL，缓存使用Redis，均为免费的软件。综上，该系统在技术上是可行的。3.3.2经济可行性在开发一个软件的时候，首要考虑的就是软件的开发成本与软件可以带来的效益。通过分析得出该软件是否值得开发。本物资采购系统属于一个个人研发类的系统，用户需求较为简单，在开发软件的过程中不会产生任何的费用支出问题，开发所需的工具也都为免费软件。在硬件方面，任意一台配置合格的电脑都可以正常开发本系统。因此，本系统从最初的设计到最后的开发完成，基本没有任何的成本上的投入。在应急救灾物资管理系统中，仓库中的物资大多来自采购。因此，本系统是应急物资管理系统中不可缺少的一部分，其重要性不言而喻。综上对于成本与收益的分析，该系统的开发在经济方面是可行的。3.3.3时间可行性本系统开发时间充裕，前端界面的搭建在一周内可以完成；数据库的设计、后台逻辑的实现大约需要两周左右；进行前后端接口的耦合需要一周左右；在系统开发完成后，对系统进行细节方面的优化需要一周左右。综上，本系统从设计到开发完成共需要五周左右，因此该系统在开发的时间上是可行的。3.3.4操作可行性本系统的操作人员主要是某地应急救灾物资中心的人员。本系统外观简洁大方，操作简便，无需太多的输入，只要稍加学习，在使用起本系统来没有任何难度。因此在用户操作方面是可行的。第4章系统设计4.1系统总体设计4.1.1系统三层架构本系统遵循三层架构模型，将整个系统分为视图层、业务逻辑层、数据访问层。视图层负责接受和展示数据；业务逻辑层负责处理前端发来的请求并向数据访问层进行请求；数据访问层负责数据库的增删改查操作。三层架构可以降低系统的耦合度，方便后续系统的维护以及二次开发。图4-1-1系统三层架构系统开发模式本系统使用前后端分离模式，前端负责发送用户请求和展示数据，后端提供接口，前端通过访问对应的接口来实现对数据库数据的增删改查。前后端分离架构下，前端和后端职能分工明确，可以降低程序的耦合度。4.2系统功能设计4.2.1登录模块设计本系统的所有功能仅在登录后才可以使用，采购人员和管理员共用同一个登录页面，登录时由后端判断用户角色并跳转到不同的页面。如图为登录操作的时序图。图4-2-1登录模块时序图首页设计管理员和用户进入系统的时候，所看到的首页内容是不同的，依赖于二者角色不同。下面是进入首页时的时序图。图4-2-2首页模块时序图基础信息查询模块用户在登录系统以后，可以查看仓库中库存信息、物资库存信息、物资属性、供应商信息等基础信息。以下是基础信息查询模块的时序图。图4-2-3基础信息查询模块时序图采购用户管理模块本系统的权限分为俩种，采购人员和采购管理员。管理员负责采购人员的管理等操作。采购管理员可以通过本模块对采购人员进行增加、删除、修改、查询、导出等操作。以下是本模块运行时的时序图。图4-2-4基础信息查询模块时序图供应商管理模块管理员登入系统后，不仅可以对采购人员进行管理，也可以对供应商进行管理。对供应商进行的管理主要有增加、删除、修改、查询、导出等操作。以下是本模块的时序图。图4-2-5基础信息查询模块时序图物资采购模块在采购人员进入系统后，可以根据物资库存余量或者是物资的过期时间提出物资采购需求，采购分为新物资采购和现有物资采购俩种方式。以下是物资采购模块的时序图。图4-2-6物资采购模块时序图采购计划管理模块在采购人员添加采购计划以后，可以在采购计划列表中看到本次采购的项目和信息，采购人员可以对该表进行删除操作。同时，采购人员也可以提交采购计划，从而生成采购订单，在管理员审核通过后方可进行采购。提交采购计划可以选择提交。采购计划支持导出为采购报表以及批量导入。以下是本模块的时序图。图4-2-7物资采购模块时序图采购审核模块管理员登录系统后，可以看到用户的采购订单，进行审核，审核分为审核通过和审核不通过，审核不通过需要说明理由。审核通过支持批量审核。以下是本模块的时序图。图4-2-8物资审核模块时序图订单信息查询模块用户在登录系统后，可以查看订单信息，管理员查看的是本系统中所有的订单信息，包括已审核的订单和未审核的订单，管理员可以对未审核的订单进行审核操作。采购人员只能查看自己审核的订单以及订单的审核结果。订单列表支持模糊查询以及选择导出的功能。图4-2-9订单查询模块时序图4.3系统数据库设计4.3.1数据库ER图设计图4-3-1数据库E-R图数据库实体设计图4-3-2数据库实体设计图1.建立用户表，该表为使用本系统的所有人员的信息，包括姓名、电话、角色、id、密码、盐（用于加密）、注册日期。表4-3-1用户表字段字段意义数据类型约束id主键int主键name姓名varchar(255)非空phone手机bigint非空&唯一password密码varchar(255)非空salt盐varchar(10)非空register_date注册日期datetime非空 2.建立逻辑库表，该表存有逻辑库的一些基本信息，包括id、编号、名字、位置等信息。表4-3-2逻辑库表字段字段意义数据类型约束es_id主键int主键es_name名字varchar(255)非空es_no逻辑库编号varchar(20)非空&唯一es_introduce逻辑库介绍varchar(255)非空es_location逻辑库位置varchar(255)非空es_storeroom_number逻辑库下实体库数量int非空es_create_time建库时间datetime非空 3.建立实体库表，存储实体库的基本信息。包括编号、物资用途等。表4-3-3实体库表字段字段意义数据类型约束esr_id主键idint主键esr_no实体库编号varchar(20)非空&唯一es_no所在逻辑库编号varchar(20)非空esr_use实体库用途varchar(255)非空esr_space_number实体库下分库区数int非空ts每次更新的时间datetime非空 4.建立分库区表，存储分库区信息，主要包括上级库区的编号信息。表4-3-4分库区表字段字段意义数据类型约束eis_id主键idint主键eis_no分库区编号varchar(20)非空&唯一esr_no所处实体库编号varchar(20)非空es_no所处逻辑库编号varchar(20)非空ts更新时间timestamp非空 5.建立物资属性表，存储物资的基本信息。主要包括编号、名字、生产日期、保质期等。表4-3-5物资属性表字段字段含义数据类型约束emp_id主键idint主键emp_no物资编号varchar(255)非空&唯一emp_name物资名称varchar(255)非空emp_date_product生产日期datetime非空emp_shelf_life保质期int非空emp_price单价decimal(10,2)非空emp_is_reusable是否可以循环利用tinyint非空 6.建立供应商表，存储供应商的基本信息。包括编号、名字、地址、类型等。表4-3-6物资属性表字段字段含义数据类型约束ep_id主键idint主键ep_no供应商编号varchar(255)非空&唯一ep_name供应商名字varchar(255)非空ep_location供应商地址varchar(255)非空ep_type供应商物资类型varchar(255)非空ep_phone_person供应商联系人varchar(255)非空ep_phone联系方式bigint非空 7.建立物资—仓库中间表，便于查看物资在某个仓库中的余量。其主要字段有物资编号、仓库编号、物资库存等。表4-3-7逻辑库-物资中间表字段字段含义字段类型约束id主键idint主键es_no逻辑库编号varchar(20)非空emp_no物资编号varchar(255)非空count库存int非空表4-3-8实体库-物资中间表字段字段含义字段类型约束id主键idint主键esr_no实体库编号varchar(20)非空emp_no物资编号varchar(255)非空count库存int非空表4-3-9分库区-物资中间表字段字段含义字段类型约束id主键idint主键eis_no分库区编号varchar(20)非空emp_no物资编号varchar(255)非空count库存int非空 8.建立采购计划表，存储采购人员进行采购后的采购计划信息。其主要包括采购员、物资信息、采购信息等字段。表4-3-10采购计划表字段字段含义数据类型约束id主键idintiduser_id采购人员idint非空user_name采购人姓名varchar(255)非空emp_no采购物资编号varchar(255)非空emp_name采购物资varchar(255)非空ep_no物资供应商编号varchar(255)非空ep_name物资供应商varchar(255)非空emp_price采购物资单价decimal(10,2)非空count采购数量int非空total——amount总价decimal(10,2)非空is_submit是否提交tinyint非空ts生成时间timestamp非空 9.建立订单表，表示提交采购计划后生成的订单信息。主要包括采购信息、审核信息等字段。字段字段含义数据类型约束eo_id订单idint主键user_id采购人员idint非空root_id审核人员idinteo_no订单编号varchar(30)非空emp_no物资编号varchar(255)非空emp_name物资名称varchar(255)非空emp_price物资单价decimal(10,2)非空eo_count采购数量int非空eo_total_amount采购总价decimal(10,2)非空ep_name供应商varchar(255)非空name采购人员varchar(255)非空root_name审核人员varchar(255)eo_status订单审核状态varchar(20)非空ro_reason审核备注varchar(255)非空eo_verify_time审核时间timestampeo_create_time订单创建时间timestamp非空第5章系统实现通过对该应急救灾物资采购子系统的总体设计以后，开始进行各个功能模块的实现。本系统使用前后端分离模式，前端使用Vue框架，后端使用当前主流的SpringBoot框架，持久层框架使用MyBatisPlus。本系统在系统实现方面选择先编写后端代码，暴露好接口以后再进行前端代码的书写以及接口的对接。后端在完成时先使用ApiPost测试工具对接口进行测试。在进行后端开发的时候，先设计好数据库，然后编写对应的实体类，然后再根据具体的需求编写持久层的SQL语句，最后进行service层以及controller层的编码。在完成后端以后，前端使用PrimeVue进行页面的快速搭建，使用Vue的路由进行前端页面的跳转，通过axios对后端接口进行请求。调试完毕以后，一个前后端分离的项目基本实现，方便后续的维护与拓展。5.1系统前置功能实现为方便系统的开发与调试，在系统整体层面上进行一个系统的日志记录，主要记录用户在使用本系统的时候访问了哪个controller、请求参数是什么、返回代码和返回结果是什么。由于需要增强多个controller，在实现上选择了SpringAop，即面向切面编程，在不修改代码的情况下增强某个方法。下面是本功能的流程图以及实现效果示例。图5-1-1系统前置功能流程图5-1-2关键切面代码图5-1-3用户进入首页后控制台输出5.2用户登录模块实现本系统的管理员和采购人员存在于同一张表中，使用角色字段进行区分，因此本系统的前端登录页面只有一个且登录的时候不需要用户选择自己的身份。登录需要输入账号和密码，后端会对账号密码进行校验，校验通过会根据不同的用户角色渲染不同的前端页面，校验不通过则会直接返回给前端对应的信息。具体实现为前端输入后会先进行非空校验，然后将用户名和密码传给后端controller，后端先查询数据库有没有此用户，有的话根据用户加密盐将密码加密进行对比，对比后返回结果，没有的话直接返回前端用户不存在的信息。以下是该模块的流程图以及前端实现。图5-2-1登录模块流程图图5-2-2登录前端页面图5-2-3登录成功后系统首页5.3用户登录状态的保持本系统的设计是从实际出发考虑的，系统中除了登录以外的所有方法在调用的时候都需要前端的用户是登录状态，如果是未登录用户的话，就会返回给前端未登录的提示并让用户登录。传统的验证用户登录状态的方法是在用户登录的时候将用户存放到session中，而后每个方法都需要从session中取用户查看用户是否存在。图5-3-1传统验证用户登录状态考虑到项目在实际使用的时候可能部署到多个服务器上，由于session是存在于单个服务器的，也就是多个服务器之间的session不能共享，因此在用户进行操作的时候可能会出现session失效的情况。本项目通过redis实现了分布式session，将项目部署到多个服务器的时候不会出现session失效的情况，保持了用户的登录状态。图5-3-2多个服务器下session失效在用户进行登录的时候，系统会随机生成一个token来标识此用户。将此token作为key，用户对象作为value放入redis，有效期为两天。同时将这个token放入cookie中，存入浏览器根目录。此后用户的每次请求都会携带此cookie，后端即可以从cookie中取出token，再从redis中取相应的用户。这样前端用户的登录状态就可以保持。图5-3-3利用redis实现分布式session在本系统中每个方法都需要验证用户，那么在每个方法前面都会先有一段验证用户的代码，导致代码过于繁琐，因此选择使用参数解析器ArgumentResolver进行用户参数解析，这样只需要在方法参数里面写一个User就可以帮助我们进行用户的验证。具体步骤为先创建一个拦截器，重写其preHandle方法，在controller执行前拦截用户request，获取到用户，将用户对象存入该线程的ThreadLocal中。再创建参数解析器对象，方法参数中有用户对象的时候进行解析，从该线程的ThreadLocal中取出该用户。图5-3-4用户参数解析器5.4基础信息查询模块实现用户登入系统后，可以查看系统的基础信息，包括仓库信息、库存信息、物资信息、供应商信息等。在查询以后，可以进行导出操作和模糊查询。无论是管理员还是普通用户，都没有权限对仓库信息以及库存信息进行修改。具体实现为在用户点击相应的仓库、物资等信息按钮以后，会向后端发送请求，然后后端根据不同的请求查询数据库，将查询出来的数据以JSON的格式返回给前端进行渲染。下面是基础信息查询模块的流程图以及前端界面图。图5-4-1基础信息查询模块流程图图5-4-2基础信息查询模块前端界面5.5采购用户管理模块管理员负责对采购人员的增删改查操作，支持模糊查询以及导出操作，管理员可以帮助采购人员进行重置密码操作。此外，管理员没有权限操作管理员用户。具体实现为管理员登录系统后菜单栏有用户管理模块，管理员可以根据自己的需求对用户进行增删改查等操作，进行操作的时候会向后端发送请求，在后端的管理员模块中所有的方法都需要先验证用户权限是不是管理员。确定是管理员后再向数据库进行相应的操作，操作完成以后会返回给前端一个结果，然后前端再次向后端请求数据以进行页面的更新。以下是采购用户管理模块的流程图以及前端界面。图5-5-1用户管理模块流程图图5-5-2用户管理前端界面5.6供应商管理模块实现管理员可以对供应商进行增删改查以及导出操作，用户在登录系统后只可以查看供应商信息。供应商管理同用户管理，不做赘述。以下是供应商管理模块的流程图以及前端界面。图5-6-1供应商管理模块流程图图5-6-2供应商管理界面5.7采购模块采购用户在登录系统后可以根据物资库存信息提出采购需求，采购的项目会加入到采购计划中，采购分为仓库现有物资采购和新物资采购。具体实现为采购用户在查询到库存信息结果以后每一条数据后面都有一个采购按钮，点击按钮会输入采购信息，主要是输入采购数量，然后点击保存到采购计划按钮，会给后端发送请求，将这个采购项目加入到采购计划中。新物资采购需要输入更多的信息，比如商品名称、商品价格等，后续流程与旧的物资采购一样。以下是采购模块的流程图和前端界面。图5-7-1采购模块流程图图5-7-2采购模块前端界面5.8采购计划管理模块实现采购人员在进行采购的时候会生成采购计划，采购计划提交以后会生成采购订单。采购计划可以批量提交。采购用户可以对采购计划进行管理，也可以批量导入采购计划，以及将采购计划导出为报表供管理员查看。采购计划的导入以及导出为word报表主要是前端进行实现的。提交采购计划会向后端发送请求，将选中的采购计划生成采购订单，供管理员审核。下面是采购计划模块的流程图以及前端界面和报表图。图5-8-1采购计划管理模块流程图图5-8-2采购计划管理模块前端界面图5-8-3采购计划导出为报表图示5.9订单管理模块在采购用户提交采购订单以后，管理员登录系统后进行订单的审核。审核分为审核通过和审核不通过，审核不通过需要说明理由。本系统提供了批量审核通过的功能。在管理员审核过后，用户可以查看到审核详情。管理员进行在点击提交审核的时候会向后端发送请求，审核通过与审核不通过发送的请求不是同一个，在审核通过的时候后端会将管理员信息写入订单中，并将订单的审核状态改为审核通过，由于在表设计的时候订单审核备注默认是无，因此该订单的备注是无。审核不通过需要管理员输入不通过的理由，在提交以后会将理由写入审核不通过的订单中，后续管理员和用户都能查看到该信息。以下是订单管理模块的流程图和前端界面。图5-9-1订单管理前端界面图图5-9-1订单管理流程图第6章系统测试6.1系统测试目的与测试范围在系统开发的过程中，小到一个功能模块，大到整个系统的实现，每个开发流程都伴随着系统测试。系统测试是为了能够使程序的功能可以正常使用，防止在实际应用的时候出现一些不必要的错误影响用户体验，通过系统测试可以检验系统中存在的问题，让开发人员及时的修正系统中的错误。在进行系统测试的时候要针对某个系统模块设计不同的系统测试用例，尽最大可能的枚举用户可能进行输入以及操作，这样可以最大限度的发现系统中存在的问题。但是经过如此严格的测试之后，系统还是会必不可少的出现一些漏洞，因为我们进行系统测试的目的是修复系统中现有的漏洞而不是避免系统中出现漏洞，由于前端用户操作的不确定性，因此系统的漏洞是不可避免的。在此采购系统中，主要测试的部分为：登录模块、采购模块、后台管理模块、采购计划管理模块、订单审核模块，之后根据测试结果完善现有系统。6.2系统测试方法系统测试主要分为黑盒测试和白盒测试，黑盒测试是根据系统设计的功能进行测试，验证每个功能是否都已经实现、每个实现的功能是否符合需求，系统的性能是否可以作为实际使用。白盒测试是已知系统内部的实现过程，通过测试验证每种内部实现是否符合设计规格要求。本系统使用的测试方法为黑盒测试，即只针对接口进行测试，无需关注内部实现。通过黑盒测试来检查系统的功能是否符合要求，进而发现系统中存在的错误，为系统进一步的优化提供方向。6.3系统测试用例6.3.1登录模块测试进行登录测试，在账号密码框内输入不同的内容，查看登录的结果是否符合预期结果。测试用例表如下图所示：表6-3-1登录模块测试测试模块登录模块测试角色用户测试条件用户进入登陆页面测试目的查看是否可以正确登录并渲染不同首页操作不输入信息/某项信息为空输入错误的账号/密码输入正确的账号密码预期提示信息“输入完整信息”提示信息“密码错误”进入到首页实际结果提示信息“输入完整信息”提示信息“密码错误”进入到首页6.3.2采购模块测试采购人员进入系统，根据需求提出采购，采购可以采购仓库现有物资、新物资，采购后采购项目会加入到采购