【课程设计】基于Spring Boot的二手数码校园代理回收系统的设计与实现-计算机毕设 27671

1绪论

1.1研究背景及意义

1.1.1研究背景

校园二手数码产品流通长期以来依靠的是个人社交网络以及临时性的线下活动。学生出卖闲置物品需要自己去寻找买家，协商过程会耗时耗力。价格评估缺乏客观的标准，交易双方由于信息不对称而发生纠纷。产品质量没有专业的检测，买方的权益得不到有效的保障[1]。代理回收模式出现之后，中间商依靠经验和估价收购，但是整个过程仍旧是以纸质记录以及人工交流为基础的。订单状态不能实时跟踪，财务结算依靠线下转账，资金安全有风险。不同的代理之间报价差别大，市场秩序混乱。分散、非标准化的处理方式造成资源整合效率低下的现象，大量的可利用电子产品被闲置或者不当处置。信息技术飞速发展给商品流通领域带来了巨大的改变，电子商务平台充分发挥了高效匹配供需的作用[2]。高校信息化建设越来越完善，学生的线上服务接受度也基本没有变化。传统的回收方式依靠人工判断和手动操作，不能很好地适应物品信息描述的复杂性，也不能迅速地响应市场价格的变化[3]。管理数据存放在零散的表格或者笔记里，检索起来很不方便，不能支撑跨代理商的业务协作以及数据分析。这样就造成了循环服务在低水平重复阶段停滞不前，从而限制了校园循环经济的规模发展。由于行业内部缺乏统一的管理办法，服务质量参差不齐，给消费者带来了不良的影响。国家提倡绿色消费、资源循环利用，在校园这样一个电子产品消费密集区，其回收体系建设的规范程度也要得到提高。市场竞争迫使回收服务商努力提高效率并降低成本，客户希望得到透明、方便、有保障的回收体验。由于这些因素相互作用而产生出一个集成化、流程化、可监管的校园代理回收系统的需求。

1.1.2研究意义

系统把回收申请、订单处理、价格确认、款项交割都放入进去，这样就能实现网上流程的整合。用户提交信息之后，代理方的审核和报价操作在平台上进行，并且由于信息传递的延迟而使得该过程变得不可见。订单状态的变更立即通知相关人，所有的操作都有记录，并且有历史记录可以回溯。这样做的目的是大幅度减少事务处理的周期，大大降低人员重复沟通所耗费的时间。人工录入的数据容易出现疏漏，系统使用表单校验和流程控制的方法，缺少的关键信息不能进入到下一部分，从源头上降低差错率。资源调配借助于订单信息实现调节，代理人在完成任务之后能够有选择地使用工作量，闲置的物品和回收的需求也会更契合。校园二手数码回收一直处于自发的状态之下，系统给各方面的参与者定下了明确的行为准则以及服务规范。代理人的资质经过平台进行审核合格后可以向有权申报该权利，报价、履约行为也都有行政监管依据，这可以保证市场的运行平稳。交易数据存放在系统里，给分析物品流通规律、评价回收价值提供可靠的证据，有利于管理者作出更好的决策。整个回收链条形变得很平易可触，增大了学生对回收的信赖水平，有更多闲置物品愿意以正规的回收渠道进入流通环节中，从而促成了校园内资源循环利用实践的深入发展。根据具体的场景来设计的系统，给其他高校或者社区创建类似的回收平台提供了一种参考模板。可以适用于不同的规模的运营主体。经过系统的积累，能够服务于更多的电子废弃物回收政策研究，给城市资源循环体系的微观环节建设提供案例。平台促使的规范交易环境，也直接培养出学生对契约精神和环保意识的培养，社会效用大于仅仅经济效益。

1.2国内外有关的研究现状

1.2.1国内现状

国内对于校园二手交易以及回收系统研究与实践开始于二十一世纪初，前期主要是对电子商务理论在校园场景中适用性的探讨。当时我国高校信息化水平较低，学生的主要交易方式还是校园BBS论坛、QQ群组等非专门化的平台，特点就是信息零散、交易过程没有保证、商品质量参差不齐。伴随着移动互联网技术的发展以及电子商务模式的成熟，一批专门的校园二手交易平台也应运而生，比如“闲鱼校园”、“转转”这类综合平台下的校园圈功能，还有众多高校自己开发的小程序校园跳蚤市场。这些平台初步实现了信息的线上集中发布，在物品回收、价值评估、专业化代理服务等垂直领域开展的不多，流程标准化程度不高，本质依然是C2C模式的一种延伸。

近几年来，研究的焦点也由原先只关注商品信息的发布转为包含回收、评价、转售、服务等在内的闭环生态系统。学者也开始了对于校园里资源循环模式的研究。王思睿（2021）在关于高校绿色校园建设研究中提出，传统的二手交易模式下对于功能性的数码产品进行处置时效率低下的问题，提出了引入专业的评估方来对残值鉴定和规范回收做出必要的考虑，重视了流程的透明度对提高学生参与的积极性有着重要的意义[4]。李孟泽（2022）从校园二手市场入手对信任机制进行实证分析，发现缺少中间担保、不统一的质检属于交易纠纷的原因之一，由此来论证是由可信第三方（签约代理或者校园管理机构）介入交易过程，可以明显降低买卖双方的风险感知，促使交易达成[5]。张一驰等(2023)研发并且制作出来了一个用微信小程序做校园书籍回收的原型，证明了预约回收、上门取件、统一消毒翻新的方式可以应用于一定的品类里，并且给数码产品这种高价值物品的回收系统的设计提供了一种思路[6]。

目前我国行业存在的现状表现为平台专业化和服务细分化的发展趋向。一方面，综合型平台凭借流量优势，开拓起“回收”频道与第三方服务商合作的模式，试图进入回收领域，如“爱回收”和京东、小米等品牌开展以旧换新的合作已经渗透到校园推广中。同时，侧重于校园垂直领域的创业企业也在逐渐发展，他们试图创建出一个更加贴近学生使用的独立系统，并且聚集起了本地化代理的服务资源。比如“咔咔校园回收”这样的区域性项目，试图和校内的数码店铺或者学生创业团队合作，创建起实体代理店，在线上系统上完成订单的管理，探究线下线上的融合（O2O）回收途径。但是，目前还存在着规模化扩张难、代理服务质量难以把控、与校园管理深度融合不够等问题。总的来说，国内研究及实践已经认识到创建专业化校园回收系统的好处，并且正在朝着包含质检、定价、支付、售后全过程的服务体系前进，但是成熟的、可以广泛复制的商业模式和系统解决方案还在摸索和发展中。

1.2.2国外状况

国外对于循环经济和可持续消费的研究比较早，校园是践行可持续发展理念的重要社区，它的二手物品流通以及回收体系也得到了学术界以及产业界的广泛关注。研究脉络开始时只是理论的倡导，逐渐变成平台化建设、智能化、服务化的持续发展[7]。早在上世纪九十年代，欧美高校的校园集市（Campus Market）和年末甩卖（Yard Sale）就是实物二手交易的主要形式。互联网的兴起给学生提供了一种新的分类广告方式，但是它的信任和安全性问题也依然存在。进入二十一世纪，以eBay为代表的大批量C2C拍卖模式为校园密集社区、高频低值物品提供更加规范的交易环境，但是它对于校园密集社区和高频低值物品特点的通用性设计并没有得到深入改进。

2008年全球金融危机之后，共享经济的理念盛行起来，并且促使二手平台向着移动化、社交化、本地化方向前进。美国公司Decluttr主要做消费电子产品的在线即时估价和回收，借助自动化定价算法以及免邮费寄送的服务，大大降低了回收的门槛，是面向普通消费者的（学生）专业回收平台的典范[8]。在欧洲，Student Marketplace等专门服务于学生群体的平台出现，它把学生的身份验证作为重点内容，增强了社区成员的感觉，并且一些平台开始和教科书出版商合作，创建起对教材进行特定回收再流通的链路。学者Thompson（2021）对北美五所大学的电子废弃物回收项目做了比较研究，发现成功的项目大多依靠清楚的财务激励、便利的收集网络（设在图书馆、宿舍楼里有回收箱）、与专业的回收企业建立稳定的联系等来推动大规模参与，其研究表明，单纯环保宣传不能调动大家的积极性，必须把经济便利性作为系统设计的重要方面。意大利学者Rossi和Bianchi（2022）提出了一个用以评价二手电子产品的在线平台定价是否公正的多维模型，该模型把产品型号、磨损程度、市场供需波动、平台信誉等很多因素都考虑进去，给自动化、透明化估价系统的发展赋予了理论支撑，从而降低了回收交易中信息不对称的问题[9]。日本学者田中宏和（2023）对日本大学生进行二手数码产品消费态度的研究，发现除了价格之外，产品通过的“清洁度”、“功能检测认证”以及“售后保证期”等属于影响购买决定的重要服务属性，从而促使二手交易平台由简单的商品列表转变为提供增值质检、保修服务的平台。

目前，国外该行业存在的主要问题就是高度市场化、技术驱动和服务差异化。近几年来，先进的平台开始大规模投入到人工智能、物联网技术当中来提高运营的效率。比如一些平台开始用计算机视觉的方法，对用户上传的照片做自动识别、初步检测屏幕划痕等外观损伤的过程加快了在线评价的进度。在物流环节，和智能快递柜公司进行合作完成了回收物品的灵活投递。在服务模式上，呈现出了多元化的特征：既有如Back Market这类专注翻新的电子设备销售、统一质量标准并延长质保期的B2C平台，也有像Gazelle这样的完全属于C2C/B2C回收的平台，主打的是快货币支付，把回收深度融入到自己的产品生态系统里，用优惠券的形式来鼓励用户换购，形成闭环。学术界对于行为经济学干预（怎样设计激励来最大化回收率），区块链技术在提高回收链条溯源透明度方面的研究也比较多，对LCA方法在量化校园回收系统环境效益上所采取的实践也较多。总的来说，国外校园二手数码回收已经形成了一个以专业平台为主导、技术深度赋能、服务标准比较健全的成熟市场，它系统的设计更重视的是无缝的用户体验、自动化的后台处理和与宏观循环经济政策的对接，给我国相关的系统建设提供了一个技术路径和商业模式的丰富参照。

1.3论文组织结构

本文以“基于Spring Boot的二手数码校园代理回收系统的设计与实现”为主题，按照软件工程规范流程来组织内容。本文全文分为七章，每一章内容安排如下表所示：

第一章绪论。本章对课题研究背景和意义进行阐述，分析目前校园二手数码产品流通领域的效率低、缺乏保障等问题，提出开发规范化代理回收系统的重要性及价值。同时整理国外相关的研究现状，总结国内相关研究的现状，并对本文的研究结构做详细的说明。

本章主要是给读者介绍技术。本章对系统开发过程中使用的核心技术和工具做了详细的说明。主要介绍了Java语言、SpringBoot后端框架、Vue.js前端框架、MySQL数据库、Redis缓存以及B/S架构的基本原理、技术特点和在本系统中应用的情况，为之后系统的设计及实现打下技术基础。

第三章为系统的分析。本章是论文的主要部分之一。从技术、操作、经济三个方面来确定系统的可行性。之后根据用例图对系统做功能需求分析，确定用户、代理和管理员这三种角色的各个功能。最后，从可用性、可靠性和安全性这三个方面对系统非功能需求做详细的说明。

第四章为系统的建立。本章在需求分析的基础上，完成了系统的设计。对系统分层架构的设计及优势进行阐述。另外，用功能结构图来表达系统总的可操作功能模块的划分。接下来，用流程图来详细地描述出用户提交回收、代理审核订单、用户确认价格、代理放款支付以及管理员处理异常上报等主要的业务流程。最后，根据E-R图、数据表的设计来完成数据库的概念设计和逻辑设计。

本章为系统的实现，第五章给出系统的设计方案与功能模块的详细设计内容。本章根据第四章设计方案，对系统各个功能模块的实现做详细的说明。从用户端、代理端、管理员端三个方面，用文字描述和界面截图的方式，对各个核心功能的交互界面、操作逻辑以及实现效果进行展示。

本章主要对系统进行测试，保证系统功能达到预期的要求，并且给出一些改进的方向。本章主要目的是检验系统功能是否正确可靠。确定测试的目的和方法。其次，对前台物品回收、申请领取这些主要功能的模块进行详细的操作测试，并且执行相应的测试以获得结果。最后对测试结果做综合分析，确定系统是否达到预期目的。

第七章总结和展望部分，对本研究进行小结，并提出未来研究方向。本章对全文研究工作进行总结，对系统设计和实现取得的主要成果、系统目前存在的局限性等加以归纳，并从客观角度分析系统目前存在的不足。根据目前存在的不足，对未来系统的发展方向和未来的发展前景做展望。

2有关的技术介绍

2.1Java语言

Java语言起源于二十世纪九十年代初期，Sun Microsystems公司于二十世纪九十年代初期便开始了一个叫做“绿”的项目。最初设想在消费类电子产品上进行，并且后来又偏离了最初的初衷。互联网浪潮出现之后，该语言又转向了网络应用的开发。该设计思想是以“一次编写、到处运行”为原则的，源代码编译成字节码，字节码交给虚拟机来执行[10]。语言本身就有着标准的类库，类库给处理输入输出、网络通信提供大量的预构建组件，也能够支持网络通信的功能。内存管理用自动的垃圾回收机制来处理内存地址，程序员不需要自己分配或者释放内存地址。多线程编程模型放在语言的核心，并发控制依靠同步关键字来实现。

该语言有各种程序设计的范式。面向对象特性最明显地体现出来，所有的代码都放在了类中。继承机制可以让子类的属性和方法被复制到父类中，多态性使程序在统一方式下可以处理不同的类型对象。异常处理结构把错误处理的代码与正常的业务逻辑分开，从而使程序的执行流程更为清楚。反射机制可以对运行时进行检查类的信息，程序可以在需要的时候加载类并调用它的方法[11]。注解功能是代码中添加元数据，元数据可以在编译时或者运行时被指定的工具读取。泛型编程在编译时对类型进行检查，使类型安全得到加强，代码重复性降低。

2.2Spring Boot框架

Spring Boot框架是传统Spring框架的进一步发展，由原来的Spring框架发展而来。传统的Spring框架需要大量的XML配置，配置过程比较繁杂。Spring Boot的出现是为了解决基于Spring的应用初始搭建问题，其主要设计思想就是约定大于配置。框架中有Servlet容器，把应用放到一个不依靠其它的web服务器来部署的地方[12]。因此可以把该类放到一个单独的.jar文件中来使用。自动配置机制扫描项目类路径，根据类路径中存在jar包的自动推断并创建所需的Spring Bean。起步依赖将常用模块打包成预定义的依赖组，开发者创建文件时就声明出一组依赖就可以得到完整的功能支持。

框架用特殊的目录结构来组织项目文件。主应用程序类一般用@SpringBootApplication注解来标注，它把配置扫描、组件扫描、自动配置等各方面的功能一起集成起来[13]。外部化配置把属性值转移到application.properties或者application.yml文件中，不同的运行环境可以分别加载不同的配置文件。执行器模块给应用赋予了各种生产级的功能，健康检查端点能够向应用发出报警信号，度量指标端点会记录并传输应用的性能信息。框架通过条件注解的方式来控制Bean的创建过程，只有满足某个条件的时候，相关的配置类才生效。这样就可以给自动配置提供极大的灵活性，开发者容易地去覆盖掉默认的配置。

2.3Vue框架

Vue框架的创建于2014年以前，早期版本是由一个独立开发者发起的。它设计理念是借鉴了已有前端框架的设计思路，在实现方式上采取的是渐进式的方式。项目的发展过程中，社区的贡献越来越大，核心库的功能以及周边工具链不断延伸[14]。版本迭代遵照语义化的规范，每一个主要版本的发布都会伴随有详细的迁移指南。框架的文档用多语言编写的，给不同的地区开发者提供访问入口。

该框架用声明式模板和响应式数据绑定的方式创建起用户界面。Vue应用的核心是用Vue函数创建的一个根实例，该实例会接受一个选项对象。选项对象的内部可以有数据、方法、生命周期钩子。数据处理阶段，框架会遍历数据对象所有的属性，并利用Object.defineProperty或者Proxy来拦截对这些属性进行读写操作。当数据发生变化的时候，相关的视图会根据依赖跟踪来更新。视图层用HTML模板语法的方式，可以对DOM进行绑定，使得开发者能够方便地声明式地将DOM绑定到底层组件实例的数据上。模板会编译成渲染函数，渲染函数返回虚拟DOM节点树[15]。组件系统里，每一个组件就是一个使用Vue定制过的，带有选择器和作用域的自定义实例。组件间通过props传递数据，自定义事件则用在子组件将消息传给父组件上。

2.4MySQL数据库技术

MySQL数据库技术属于关系型数据库管理系统的一种。系统最初由瑞典的MySQL AB公司开发出来，后来又被许多商业公司所收购，并且一直保持下去。数据库用结构化查询语言对数据进行操作，它包含了数据定义、数据操纵、数据控制等很多子集[16]。存储引擎架构把数据处理与存储分离，不同的引擎根据具体的使用环境来改善。InnoDB引擎下可以进行事务操作，用ACID准则保证数据的一致性。该引擎采用行级锁定的方式来实现并发访问的控制，从而保证了资源的隔离保护，在并发操作出现的时候可以避免系统性能上的瓶颈。索引用B+树的数据结构来组织数据，该结构能保证数据的有序性并高效地进行范围查询。

数据库服务器用客户端/服务器模型工作。客户端通过网络连通性把SQL语句发给服务器端，服务器解析生成并返回执行计划。根据各种执行路径的性能来确定最省时的路径访问数据。最后选择成本最低的途径来访问数据。日志文件记载数据库一切变动的操作，二进制日志用来完成主从复制，重做日志来保证事务的持久性[17]。内存池缓存磁盘数据页，经常访问的数据会被存储在内存里减少磁盘I/O。表空间就是数据存储的物理容器，容器里分为多段、多段再分成多区。备份工具可以产生数据库在某个时刻的数据快照，快照可以用来数据恢复或者迁移。主从复制机制将主服务器的数据发送到各个从服务器上，这样可以提高数据的可用性，并且加快读取速度。

2.5B/S模式

B/S模式全称为浏览器/服务器模式，是随着万维网的出现而逐渐兴起的。早期计算大多用主机/终端方式，所有的处理都放在大主机上进行。个人计算机出现之后，客户端/服务器模式就流行起来了，但是客户端软件要安装并且保持。浏览器技术的快速发展使得软件交付变得容易起来，用户只需要打开一个浏览器就可以访问到各种应用[18]。该模式把主要逻辑放在服务器端，浏览器端完成用户的界面制作及用户输入的数据采集。它们之间用HTTP协议进行交互，没有状态的，每一次请求都是一次独立的。

在这样的架构下，服务器端一般会被分成许多逻辑层次。Web服务器接收到浏览器发送过来的HTTP请求，可以是请求静态资源或者是需要动态处理的业务逻辑。应用服务器执行业务的处理，用查询数据库的方式获取或者保存数据。数据库服务器持久化存储业务数据，数据按照一定的模型组织。浏览器端接收到服务器返回的HTML文档后，就会得到文档对象模型[19]。JavaScript引擎执行页面中的嵌入脚本，脚本可以对DOM进行改变页面内容。样式表来控制页面上元素的视觉呈现，布局、颜色按照规定渲染。异步JavaScript、XML技术可以使得浏览器在后台向服务器发送数据，从而使页面不完全刷新就更新部分内容。

3系统性地分析

3.1可行性分析

3.1.1技术可行性

本文所用的是成熟的B/S架构。这样的一种架构方式，把用户的交互、业务逻辑、数据存储分开来处理。后端开发使用Java语言并结合SpringBoot框架，该框架经过长时间的实践证明可以给系统提供稳定的可靠的基础运行环境。开发者对SpringBoot自动配置、依赖管理以及使用的熟练程度比较高，在此基础上就可以快速建立项目的结构并连接数据库操作逻辑等几个主要部分了。前端使用Vue框架来创建用户界面，它的响应式设计理念和组件化的开发方式，可以满足校园内各种终端设备访问的需求，已经掌握了它主要的语法以及状态管理的方法。数据持久化方案由MySQL数据库提供支持，它的表结构设计可以很好地满足用户、订单、商品等各种类型的实体之间的关联关系的映射，所以它具有很强的数据持久性。系统在实现上主要是依靠常规的Web应用开发技术，开发者对于相关的技术栈有一定的掌握程度，可以支撑功能模块的编码工作。系统运行时可能会出现数据查询响应慢的问题，可以将高频查询的字段加入数据库索引来改善。系统依靠网络完成数据的传送，存在信息泄漏的危险，计划使用基于角色的访问控制的方式来管理操作权限，对重要的用户输入实行严格的验证，来应对常见的安全威胁。因此，系统的在技术上可行。

3.1.2操作可行性

目的使用群体主要以在校学生、校园代理及系统管理员为主。该系统界面设计按照常见的Web应用操作逻辑来设计。用户初次接触时就可以根据文字提示完成物品回收的信息提交，不需要参加专门的培训。代理人员利用系统后台来处理订单，他的审核、报价等一系列主要工作流程也变成了一个个经过系统自动处理和人工审批的简单的点击操作。原来的依靠线下沟通、手工记录的方式已经被彻底地简化了。管理员对于各种基础信息的维护操作统一在一个工作面板上进行，信息更新之后立即生效。系统上线之后，大部分日常的事务都是各个角色用户的自主处理，一般性的运维维护工作都集中在服务器的状态监测以及数据库备份上。此类维护比较容易，技术难度适中，校园信息管理部门或项目的团队就可以胜任。因此，系统可以被实现。

3.1.3经济可行性

该项目主要的成本在开发阶段的人力投入上。软件开发可以由个人计算机来完成，硬件投入非常少。系统所依靠的SpringBoot、Vue、MySQL等核心技术组件都是开源软件，不需要付费许可。项目部署所需要的服务器资源初期可以使用性能适中、容量充足的云服务器或者校内服务器来满足需求，但是运行成本比较低。系统投入使用之后，可以大幅度提高校园二手数码回收整体效率，给代理方带来稳定的业务来源，也为用户创造便捷的变现途径。它所具有的实际应用价值和初期投入比较低，有一定的性价比。本项目的后期维护费用主要是对于服务器续费以及偶尔的功能更新等而言，收费区域是可以承受的。因此，系统在经济上是可以实现的。

3.2功能需求分析

UML用例图用来表示系统功能需求的图形化方法，用例图把系统和外部参与者之间的交互关系画出来来说明系统功能。用例图用例用来表示系统能够完成的功能，参与者就是与系统交互的各种用户或者外部系统的。用例图在分析设计的时候可以使用，开发期和测试期间也可以用，使系统的功能完整、准确，给开发者及用户提供一致的语言。用直观的图示，UML用例图给系统功能、角色的关系画出。本文将按照角色模块的方式来完成系统的设计。

3.2.1用户功能

用户可以在回收物品、申请领取物品的时候进行检索、查看转售信息的详细列表，还可以完成回收订单的申请，并将报废商品转交给回收商、把废品卖给厂家或者进行其他的处置方式。用户角色使用场景图如下图3.1。

图3-1 用户用例图

3.2.2代理功能

代理可以查看到企业的详细信息，对代理订单进行审核并查看代理订单，并且可以发起报价信息的提交，也可以实现放款支付。代理角色用例图如下图3-2所示。

图3-2 代理用例图

3.2.3管理员功能

管理员可以对代理信息进行查询、重置、删除、新增及修改；对企业信息进行查询、重置、删除、新增和审核；对于回收订单进行查询、重置、删除、新增及查看详情；查看价格确认详情；对回收故事进行查询、重置、删除、新增及查看详情；查看回收记录详情；对新闻资讯进行查询、重置、新增和删除；处理异常上报；查看代理订单详情。管理员角色的用例图见上图。

图3-3 管理员用例图

3.3非功能需求分析

1.可及性需求

用户界面按照现在的主流平台设计规范来打造，页面结构分层有序。导航菜单位置固定，关键操作按钮的视觉上很容易区分出来。系统支持响应式布局，页面内容可以在不同的显示屏上自适应地排列出来，主要的功能在主流的移动设备浏览器里依然可以使用。所有的交互操作在用户触发之后马上给出即时的反馈，即按钮被点击时的状态改变、数据提交时显示进度提示。界面文本表达清楚、没有歧义，图标意义接近一般的认知。错误信息用用户能够理解和接受的方式来表述，给用户提供清晰的纠正指引。本系统的功能实现主要采用优化的方式，传统的交易任务从开始到结束需要完成操作步骤量被限制。新用户的注册流程中要填写的信息项尽量少，可以用基本的社交账号快速授权登录。把文档嵌入到系统内，用户在当前页面的侧边栏或弹窗中可以查阅相关的操作说明。

2.可靠性的需求

系统在正常硬件、网络环境之下一直运行，并且计划内的维护工作安排在访问低峰时段来完成，提前向用户提供信息。核心的交易模块具有事务处理的功能，保证订单创建、库存扣减、支付状态改变等相关的操作要么全部成功，要么全部失败，数据一致性得到保证。用户提交数据或者是发起请求时，系统会对输入内容进行有效性校验，阻止明显异常或者格式错误的输入，防止无效操作造成后端流程。数据库定期做备份工作，把备份的数据存放在不同的存储设备上。利用服务器可以准确的保存下来的详细运行日志和错误的日志记录，这就为找到问题原因提供了支撑。系统对重要的业务服务进行状态监控，如果发现服务连续不能使用的话，就会发出预警信息。系统各个功能模块之间存在着一定的依赖关系，单个非核心模块出现的临时故障要尽量隔离，以免造成整个系统的服务中断。

3.安全需求

对所有的用户都实行身份认证制度，未登录的用户只能在公开的商品浏览页面上浏览。用户密码存入数据库时使用不可逆加密算法进行处理，把数据传递给服务器采用安全协议来保护。系统采用基于角色的访问控制方式，不同的角色用户只能看到并能被授权来完成他们所拥有的功能菜单以及数据。用户会话有有效期限制，如果长时间没有操作就会被注销，必须重新登录才能继续下一个活动。清除所有的用户输入，防止恶意脚本代码被注入或被执行。文件上传功能的限制可以接受的文件类型和大小以及上传之后产生的文件进行病毒扫描。涉及用户个人隐私、支付信息等敏感数据的页面不能被浏览器缓存。系统的后台管理操作都是由独立的日志来记录的，日志的内容是不能被一般用户修改的。系统内部的密码修改功能可以给用户随时对密码进行更改，没有固定的要求。当用户多次尝试登陆的时候就会出现异常，这时系统会对该账号暂时进行锁住。

4设计系统

4.1系统架构设计

本系统用传统的三层架构模式来设计和实现。该分层架构的主要优势就是重视点的分离，把用户交互、业务处理和数据存储分开来考虑。客户展示层主要完成人机交互界面的展现以及用户指令的接收，依靠业务层来承担起全部的核心业务规则和流程控制，数据持久层则是为了保证系统数据的结构化存储并且快速访问。各个层次之间的通过定义清楚的接口来实现通信，可以大大降低模块间耦合的程度，从而大幅度提高代码的可维护性和系统的可扩展性。该逻辑架构的关系如图所示。

图4.1 为系统架构图

采用 Vue.js 软件框架来创建单个页面的应用程序，使用 ElementUI 组件库在很短的时间内创建出一个风格一致、操作便捷的用户界面。前端应用使用Axios库创建HTTP客户端，后台发起异步请求，在后台返回后把数据传递给前端应用。每一次请求都会携带由登录认证流程发放的JWT令牌，该令牌在请求头里被传递。后端SpringBoot应用的控制层接到请求的时候首先要经过过滤器链对其进行解码与校验，然后判断用户是否具备该用户的授权，最后验证这个用户是否有权限执行某项操作。之后，请求根据它的URL路径被路由到相应的Controller方法。Controller层接受并初审请求参数，比如参数形式是否正确、非空等等，经过校验之后把参数转发到下一层的业务逻辑服务中。

业务逻辑层是系统的根本，它包括了用户管理和物品回收、代理审核和订单处理、质检定价和支付、转售与转申请管理、异常上报与售后服务、系统管理以及新闻资讯这几个主要的部分。服务层的方法将具体的业务规则封装起来，用户提交回收申请的时候需要验证用户的状态，生成唯一的订单号并初始化订单的状态，代理报价的时候要关联订单、计算价格并且触发状态的改变。复杂的业务操作一般需要涉及到多个数据库表的更新，System利用Spring的@Transactional注解的方式开启声明式的事务管理机制，保证数据修改的操作是可靠的、一致的。基础服务层给整个应用提供公共支撑的能力，Spring Security框架以角色认证的方式对所有的操作赋予了细致的限制，保证用户、代理、管理员不能访问到它们所拥有权限范围内的东西；全局异常处理器能统一捕捉并处理一切类型的运行时异常，并将它们转化为格式化错误的信息回馈给客户端；使用面向切面编程的方式实现的日志审计功能，关键业务动作会被自动记录下来，可以追溯并且可回溯。

数据持久化工作主要由MyBatis-Plus框架来完成，它是对象关系映射工具，把Java实体对象和数据库表结构进行映射，大大地简化了数据库的增删改查操作。开发人员不需要编写大量的JDBC代码以及大部分的基础SQL语句，MyBatis-Plus提供的条件构造器就可以方便地创建出动态的查询条件，而且它的自带的SQL注入防护功能也使得数据操作更加安全。采用MySQL 8.0为主要的关系型数据库，它的强大的ACID事务特性给上面的业务事务提供了一层底层的保证，在高并发的情况下保证数据的准确性、完整。为了减轻数据库的访问压力并提高系统的响应速度，系统使用了Redis来做分布式缓存。JWT令牌被授予之后就存储在Redis里，方便令牌的校验和黑名单的管理；另外一些访问频率高、变化不大的数据，比如系统配置信息、部分新闻资讯等，在下次请求的时候直接从缓存中读取，从而大大减轻了数据库的负担，提高了整体性能。

4.2系统结构功能设计

二手数码校园代理回收系统以用户、代理及管理员这三个主要角色为核心，创建起它的功能体系。系统给用户提供了一条从提交回收申请到完成交易的全过程服务，包含物品回收、订单管理、质检确认、支付反馈以及社区互动这些部分。代理角色只负责订单的审批、价格评定以及款项交割等工作，主要功能就是对订单进行审查并给出评分结果，并且管理企业的相关信息。管理员是平台的监管者和基础运营者，它的功能主要包括代理及企业资质审核、全站订单及内容管理、异常情况处理以及新闻资讯发布等主要后台操作。本系统功能层次清楚，各个角色职责分明，共同组成一个完善的、高效的一体化校园二手数码回收生态。系统功能结构图如图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数据库设计

在数据库设计时，用ER图将概念模型转化为具体的数据库结构。该阶段就是确定每一个数据表的字段类型、约束条件以及表之间的关系，为物理设计打下基础。之后通过优化数据存储方案来改善系统性能，并且可以满足系统的扩展性要求。

4.4.1设计E-R图

E-R图（实体关系图）用图形来表示数据的一种方法，把实体、属性和实体之间联系都画出来。采用图示的方式来辅助数据库结构分析与设计，可以方便地看出数据之间的联系，便于之后数据库开发及管理工作。下面给出系统全局E-R图以及各个实体的属性图。

系统全局E-R图见图4-8。

图4-8 系统E-R图

异常上报实体包括异常上报id、订单编号、代理姓名、创建时间等。实体属性图如图4-9所示，具体为。

图4-9 异常上报实体属性图

售后咨询实体有售后咨询id、订单编号、代理姓名、创建时间等。实体属性图图4-10如上所示。

图4-10 出售方交付的实体属性图

代理信息实体有代理信息id、代理介绍、代理姓名、代理电话等。实体属性图如图4-11所示。

图4-11 代理信息实体属性图

代理订单实体包括代理订单id、订单编号、企业名称、审核状态等。实体属性图如下图4.12所示。

图4-12 是代理订单实体的属性图

转增申请实体包含转增申请id，申请用户，申请日期，创建时间等信息。实体属性图如下图4-13所示。

图4-13 转增申请实体属性图

本文中的实体有文章id、标题、文章分类、创建时间等。实体属性图为图4-14。

图4-14 文献实体属性图

质检信息实体主要有质检信息id，订单编号，物品状态，创建时间这些。实体属性图如图4-15所示，主要是把“特征”（实体）和关联的“关系”的关系进行可视化表达。

图4-15 为检验信息实体属性图

报价信息实体有报价信息id、订单编号、物品报价、创建时间等。实体属性图如图4-16所示。

图4-16 报价信息实体属性图

收款确认实体包含收款确认id，订单号，物品价格，创建时间等信息。实体属性图（图4-17）把数据中所有的特征用图形的方式来表达出来，从而有利于对这些特性进行分析和理解。

图4-17 付款确认实体属性图

回收订单实体包含回收订单id、订单编号、代理姓名、审核状态等。实体属性图(图4—18)如图所示。

图4-18 产生订单实体属性图

4.4.2数据库设计

数据库表设计就是根据业务需要来决定数据库表的结构，字段类型和关系。规范化设计可以保证数据的完整、一致、有效，减少多余的资料，为后面的数据查询、存储、维护留出清晰的结构。下面是对系统中数据表创建的说明。

异常上报表是用来记录异常上报信息的。主要是异常上报ID，订单号，代理人名，创建时间这些字段。从表4-1可知，如图4.2所示。

表4-1 异常上报表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	异常上报id	int	11	是	是	异常上报id
2	订单编号	varchar	50	否	否	订单编号
4	代理姓名	varchar	50	否	否	代理姓名
13	创建时间	datetime	-	是	否	创建时间

售后咨询表是用于记录售后服务咨询的，主要目的是为了方便以后对客户反馈进行总结、分析和改进。主要是售后咨询id、订单编号、代理姓名、创建时间等字段。表4-2为如下。

表4-2 售后咨询表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	售后咨询id	int	11	是	是	售后咨询id
2	订单编号	varchar	50	否	否	订单编号
4	代理姓名	varchar	50	否	否	代理姓名
10	创建时间	datetime	-	是	否	创建时间

代理信息表是用来存储代理相关的信息的。包含代理信息id、代理介绍、代理姓名、代理电话等字段。按照表4-3可知，在此条件下，以下各项都是正确的。

表4-3 代理信息表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	代理信息id	int	11	是	是	代理信息id
2	代理介绍	text	255	否	否	代理介绍
3	代理姓名	varchar	50	否	否	代理姓名
4	代理电话	varchar	50	否	否	代理电话

代理订单表是用于记录代理相关订单的。包含代理订单id，订单编号，企业名称，审核状态等字段。在这个意义上来说，在我的研究成果之后加以对比，可以发现存在着一定的不足的地方，也就是研究缺少了对跨学科的研究能力以及研究的范围上的局限性。

表4-4 代理订单表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	代理订单id	int	11	是	是	代理订单id
2	订单编号	varchar	50	否	否	订单编号
4	企业名称	varchar	50	否	否	企业名称
12	审核状态	varchar	20	是	否	审核状态

转增申请表主要用来记载物品的转增申请情形。包含转增申请id、申请用户、申请日期、创建时间等字段。表4-5为如图所示。

表4-5 转增申请表

序号	字段名	类型	长度	是否非空	是否主键	备注
3	转增申请id	int	11	是	是	转增申请id
1	申请用户	int	11	否	否	申请用户
2	申请日期	date	-	否	否	申请日期
6	创建时间	datetime	-	是	否	创建时间

表主要用作保存系统文章的内容。包括文章ID，标题，文章分类，创建时间等字段。表4-6所示，同上。

表4-6 文章表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	文章id	mediumint	11	是	是	文章id
2	标题	varchar	125	是	否	标题
3	文章分类	varchar	50	是	否	文章分类
6	创建时间	timestamp	-	是	否	创建时间

质检信息表是用以记录商品质检情况的表格。主要是质检信息ID、订单编号、物品状态、创建时间等字段。表4-7为该算法的性能结果。

表4-7 产品质量检验记录

序号	字段名	类型	长度	是否非空	是否主键	备注
1	质检信息id	int	11	是	是	质检信息id
2	订单编号	varchar	50	否	否	订单编号
8	物品状态	varchar	50	否	否	物品状态
12	创建时间	datetime	-	是	否	创建时间

报价信息表是记录代理报价内容的表格，主要包含代理人报价的信息。主要是包含报价信息ID、订单号、物品报价、创建时间等信息的字段。表4-8如图所示。

表4-8 报价信息表

序号	字段名	类型	长度	是否非空	是否主键	备注
16	报价信息id	int	11	是	是	报价信息id
13	订单编号	varchar	50	否	否	订单编号
10	物品报价	double	-	否	否	物品报价
5	创建时间	datetime	-	是	否	创建时间

收款确认表是用来记载收款确认的。主要是收款确认id、订单号、物品价格、创建时间等字段。表4-9如下所示。

表4-9 收款确认表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	收款确认id	int	11	是	是	收款确认id
2	订单编号	varchar	50	否	否	订单编号
8	物品价格	double	-	否	否	物品价格
15	创建时间	datetime	-	是	否	创建时间

回收订单表是用来保存回收订单信息的。主要包含回收订单ID、订单号以及代理名信息，还有验证状态等项目内容。从上面得到的结果可以看出，经过了上述分析之后的结论如下表4-10所示。、

表4-10 收回订单表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	回收订单id	int	11	是	是	回收订单id
2	订单编号	varchar	50	否	否	订单编号
4	代理姓名	varchar	50	否	否	代理姓名
13	审核状态	varchar	20	是	否	审核状态

5实现系统

5.1用户功能的实现

前台-物品回收功能可以使用户把闲置数码产品的送到前台。用户进入物品回收页的时候，首先需要对个人信息做填表、产品信息录入然后上传图片等程序之后，在系统进行简单的价格匹配。用户点击提交后，系统的待处理的回收订单就会被创建下来。回收流程的主要功能就是该功能。物品回收界面（图5-1）如图5-1所示，它与“绿色回收”有关。

图5-1 物品回收界面

前台-申请领取功能可以给用户提供平台转售的商品。用户浏览转售信息列表的时候，对于感兴趣的商品可以点击“申请领取”。系统会对用户的账号进行验证，展示出商品详情以及领取规则，用户确认之后提交申请，该申请就会进入代理审核队列。申请领取界面如图5-2所示。

图5-2 申请领取界面

前台—转售信息列表主要展示出所有的可以领取到二手数码商品。用户在该页面输入商品缩略图、主要信息及价格后，系统会以卡片或者列表的形式显示出来。用户点击任何一个商品的卡片上，就可以跳转到这个商品的具体信息页。用户可以清楚地看到更多的关于该商品的信息以及其目前的状态。转售信息列表界面对于表6.2。

图5-3 转售信息列表界面

回收订单管理模块可以给用户追踪所有个人提交的回收请求。在网页上面可以看见用户所拥有的订单信息，里面包含的是所有的订单编号、状态及创建时间。用户可以对订单进行查询并选择筛选，可以用重置按钮清空条件。点击详情条下拉菜单查看订单全貌轨迹，如果没有进入了处理流程则可以立刻清除。回收订单管理界面如图5-4所示。

图5-4 复购订单管理界面

回收订单详情页面展示单个订单的所有信息。用户在列表里面进入该界面之后可以见到物品描述、提交时间、当前审批状态以及处理信息等各方面资料。核心操作就是查看最新的审核情况，了解订单处于等待审核的状态或者已经接受过报价或者是被拒绝对待的环节。订单详情界面为图5-5所示。

图5-5 回收订单详情界面

质检信息功能用来公示代理方对于回收物品的检测结果。用户在订单流转到各个阶段之后，可以在相应的页面找到质检信息入口。点击详情，显示代理填写各项检测指标、成色评定以及可能存在的问题描述。质检信息界面如下图5.6所示。

图5-6 质检信息界面

异常上报功能给用户提供了一个问题反馈的途径。订单处理时用户对于流程、报价或者服务的异议可以到异常上报入口去寻找。用户填写异常类型、详细描述并提交，该上报会形成工单送达管理员进行处理。异常上报界面如下图5-7所示。

图5-7 异常上报界面

价格确认环节要让用户决定是否接受代理的最后报价。当订单状态变成待确认价格的时候，用户就会收到通知。进入价格确认页，显示报价金额，用户需要点击确认按钮同意后，或者是关闭页面来取消订单，在用户选择的基础上作出不同的决策。价格确认界面对应图5-8。

图5-8 价格确认界面

收款确认功能用来完成用户已经收到回收款项的确认。在代理完成支付之后，用户可以在该页面看到支付凭证和金额。用户核对信息无误之后，点击提交确认按钮，该订单的状态就会由之前的未完成变成已完成，整个回收流程的结束也就意味着。收款确认界面为图5-9。

图5-9 收款确认界面

售后服务咨询功能可以给用户在交易之后与服务商进行沟通。用户在售后咨询页面点击相应的订单，填写咨询问题或者服务请求后提交。该咨询内容会发送到对应的代理或者平台客服处，用户可以在之后查看回复记录。售后咨询界面在图5-10中，如图所示。

图5-10 售后咨询界面

评价反馈模块用来给已经完成的服务打分。完成的订单上可以找到评价入口。在本页上，用户可以对多个方面做出评分并填写文字评价内容，提交之后评价会公开显示并且会对代理服务的评分产生影响。评价反馈界面为图5-11所示。

图5-11 评价反馈界面

回收记录功能将所有的已经完成的回收订单保存下来。用户点击回收记录之后，系统就会显示出最后的状态订单的一张列表。用户在任意记录下，可以回溯到此笔交易的具体时间线、成交价以及用户的评分。回收记录表单界面为图5-12所示。

图5-12 回收记录界面

转售信息详情页显示的是用户自己发布的转售商品。用户在个人中心进入我的转售信息，可以查看出已发布的商品列表。当用户对某一个商品做详细的访问时，用户可以在浏览该商品的时候了解到它现在的状态、浏览过的客户和潜在的买家申请领用的情况。转售信息详情界面如下图5.13所示。

图5-13 转售信息详情界面

转申请管理功能对用户的商品领取申请进行处理。用户在自己的转申请页面上可以看见所有的申请状态列表。点击一条申请详情，可以查看代理的审核进程、审核意见或者被拒绝的原因。转申请管理界面如下图5-14所示。

图5-14 转申请管理界面

回收故事模块是用户分享社区。用户可以在他人发布过的回收经历故事中浏览，也可以利用查询功能进行主题的搜索。用户也可将新的添加按钮拖放到已有的故事上进行编辑或者发表，也可以在已有信息中留下一些关于使用心得或者交易体验的内容。回收故事界面上图5—15所示的如图5—15。

图5-15 回收故事界面

5.2代理功能的实现

企业信息模块用来展示代理自身的资质。代理登录之后，在个人中心查看已经登记的企业详情，公司名称、联系人信息以及营业执照等信息。该信息主要是给用户建立起信任，一般由管理员审核通过之后向外发布。企业的界面图是图5-16所示的。

图5-16 企业信息界面

代理订单处理属于代理的主要工作面板。代理在该页面上集中查看自己所处理的所有回收订单。列表清楚地把待审核、待报价等不同的状态标出来。代理点击审核按钮对于处理订单进行核实，点击详情按钮深入查看用户提交的信息。代理订单处理界面如图5-17所示。

图5-17 代理订单处理界面

报价信息提交功能是代理将回收价格提供给用户。在审核通过订单详情页之后，代理就会打开报价入口。根据物品的状况及市场的行情填写报价金额，可以附带简单的说明，点击提交之后，报价就会被推送到用户那里进行确认。报价信息提交界面如下图5-18所示。

图5-18 报价信息提交界面

放款支付功能就是代理完成交易最后环节。用户确认价格之后，订单就会进入到待支付的状态。代理在放款信息页面选择待支付的订单，核对收款方的信息和金额，调用支付接口或者确认线下转账之后，点击支付按钮完成操作并且更新订单的状态。放款支付界面如图5-19所示。

图5-19 放款支付界面

5.3管理员功能的实现

代理信息管理模块提供管理员对平台代理资源进行维护的功能。管理员在该页面上查询所有的注册代理，用重置按钮刷新列表。可以增加代理操作来扩展服务方，对出现违规或者失效的代理记录进行删除处理，保证代理队伍的质量。代理信息管理界面如图5-20所示。

图5-20 代理信息管理界面

企业信息审核就是管理员对代理资质进行把关的过程。管理员查看所有的代理提交或者更新的企业的信息，列出待审核、已经通过等状态。管理员可以查询到具体的资料，对提交的材料进行核对，点击审核按钮通过或者驳回，驳回需要填写理由。企业在信息审核页面的图5-21中。

  

图5-21 企业信息审核页面

回收订单监管功能可以管理员对全平台的订单进行浏览。管理员在该页面可以对所有的回收订单进行查询，并且也可以根据不同的条件来筛选。管理员可以查看任意订单详情进行监督，并且对于异常或者测试订单也可以进行删除操作来清除数据。回收订单监管界面见图5-22。

图5-22 回收订单监管界面

价格确认监管允许管理员复核交易的价格。管理员把订单列表中的已确认或者已经确认的价格的订单，点击详情按钮。该页面可以显示用户和代理之间的报价以及确认信息，方便管理员在出现纠纷的时候做查询或者调解。价格确认监管界面对左侧对右侧，位于界面底部。

图5-23 价格确认监管界面

回收故事管理模块把社区的内容存档。管理员在此可以对所有的用户发布回收故事进行查询和重置。管理员读取故事内容，对于符合规定的故事情节保留下来，对违规或者不良信息点击删除按钮进行清除，保证社区的健康。回收故事管理界面如图5-24所示。

图5-24 生成故事处理界面对照

转申请审核功能用以管理员对商品领取进行最后审批。管理员对所有的用户提交的转售商品领取申请进行查看。对代理初审通过的申请，管理员进行最后审核，点击审核按钮选择通过或者拒绝，保证流转物品的合规性和公平性。转申请审核页面如下图5-25所示。

图5-25 转申请审核界面

回收记录归档可以给管理员创建历史数据视图赋予基本依据。管理员使用该功能可以查看到任何一个已经完成的回收订单最后的详细信息。点击详情后，页面上显示了该订单从提交到完结的所有关键节点以及快照，用以数据分析或者追溯查询。回收记录归档界面在图5-26中如上所示，包含有回收记录栏目、回收凭证栏和归档人栏。

    

图5-26 回收记录界面

新闻资讯管理是平台内容发布后台。管理员在这里发布系统的公告、行业的消息。用户可以看到历史资讯列表，并且去掉过期的消息之后，再添加新的按钮来修改并发布新资讯的文章，在这样的基础上就使得平台上的信息保持最新的状态。新闻资讯管理界面在图5-27中为如上所述。

图5-27 新闻资讯管理界面

异常上报处理属于管理员解决问题的一种途径。管理员在该页面接收到了用户提交的异常工单，并且可以显示待处理的状态。管理员点击处理按钮进入工单详情，联系有关方面调查问题，根据调查结果填写处理意见和解决办法。异常上报处理界面为图5-28所示的，如上。

图5-28 异常上报处理界面

代理订单监管功能使管理员可以对代理进行详细的查看。管理员可以通过此页面来穿透查看任意代理名下具体的订单处理情况。点击某个代理订单的详细信息，管理员可以对代理的审核速度、报价是否合理以及服务流程是否规范进行监督。代理订单监管界面如图5-29所示。

图5-29 代理订单监管界面

6系统测试

6.1测试目的

主要目的是系统测试以及验证，使软件或者系统达到设计的要求和功能要求，可以稳定、安全地运行。即测试的目的就是发现并消除潜在的缺陷和问题，提高系统的质量、性能，降低系统在实际使用中出现错误的概率。用单元测试、集成测试、功能测试、性能测试等各种测试方法来对软件在不同的环境下是否兼容、可靠地运行进行测试[20]。测试可以保证系统的安全性，防止出现数据泄露或者系统崩溃等状况的发生。从提高用户体验的流畅性、客户满意度以及以后维修的成本等各个方面展开全方位的测试。因此，测试过程是软件开发的一部分，也是对软件质量以及用户需求的一种体现。

6.2检测方式

测试方法是保证软件或者系统的质量的重要手段，根据测试的目的和要求的不同，选择不同的测试策略。常见的测试方法有黑盒测试、白盒测试、灰盒测试、回归测试、性能测试。

黑盒测试只关注软件功能的表现，不考察它的内部结构。测试人员会对数据进行输入，观察结果来检验软件的性能，可以用来做功能验证、接口测试。白盒测试就是对系统内部结构进行检查，按照代码理解来判定代码的逻辑性、控制流、数据流等，保证所有的路径、每个语句都被覆盖，找出逻辑错误或者性能瓶颈。灰盒测试把黑盒测试、白盒测试的优点结合在一起，测试人员一方面可以了解到系统内部的结构，另一方面也可以注意到系统的功能和安全性以及集成性。

回归测试就是在软件进行修改或者更新之后，对已经完成的功能重新测试一遍，使新的功能没有引入新的缺陷或者问题。性能测试就是对系统各个部分做负载和压力下的性能检测，看它是否能完成所要求的任务。

采用上述测试手段对软件的功能性、性能、稳定性进行评价并改进，进而达到满足用户需求的目的，最后交出能满足用户期待的系统。

6.3测试内容

该模块测试主要是检查用户提交闲置数码产品回收请求的功能是否正常、完整。测试重点是检查请求信息是否正确录入，系统对于输入的数据进行有效的校验，并且请求成功提交之后状态的变化是否准确。前台-物品回收测试（见图6.1）是这个设计的一个方面，也是整个试验的一部分。

表6-1 前台-物品回收测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
信息提交功能	验证用户能否成功创建回收请求	用户访问回收页面，按要求填写必要信息并提交	系统提示提交成功，并在用户订单列表中生成一条待处理记录	符合预期
信息完整性校验	验证系统对必填字段的校验机制	用户在提交回收请求时，有意识地遗漏部分必填信息	系统阻止提交，并清晰地提示用户补充缺失字段	符合预期
输入合法性校验	验证系统对非标准输入的处理能力	用户在价格等数字字段输入非数字字符或超出合理范围的值	系统阻止提交，并提示用户输入格式有误或数值不合理	符合预期

该模块测试主要是对用户申请领取二手物品的流程是否顺利以及逻辑是否一致进行检测。测试重点就是用户发出申请动作之后系统对它的响应，申请状态的可视化以及相关校验规则的执行情况。前台-申请领取测试为表6-2所示。

表6-2 前台-申请领取测试用例表

测试内容	测试步骤	预期结果	实际结果
申请提交流程	用户浏览转售商品列表，对特定商品执行领取申请操作	系统弹出确认窗口，用户确认后显示申请已提交，申请状态可追踪	符合预期
重复申请限制	用户对同一商品在未完成当前申请流程时，再次尝试申请	系统提示用户已存在待处理申请，阻止重复提交	符合预期
状态查询功能	用户提交申请后，在个人中心查看申请记录	申请列表中能准确显示该申请当前的处理状态，如待审核、已通过或已拒绝	一致

本模块测试主要是检验转售商品信息展示页面的可靠功能。测试目的主要是检查页面加载的数据是否正确，信息的呈现是否完整，用户查看详情时是否有正常的交互。前台—转售信息列表测试如上图所示，如下表6-3所示。

表6-3 使用入口转售信息展示列表测试用例表格

模块名称	测试内容	操作	预期结果	实际结果	结论
列表信息加载	验证页面能否正确加载所有可转售商品	用户访问转售信息列表页面	页面正常显示所有符合条件的商品卡片或列表，包含图片、标题、价格等关键信息	正常显示	测试成功
详情跳转功能	验证从列表页跳转至商品详情页的流程	用户点击列表页中任意商品的“查看详情”入口	页面正确跳转到对应商品的详细信息页面，展示全部内容	跳转正确	测试成功
列表数据排序	验证列表是否支持按预设规则排序展示	用户触发按价格或发布时间排序的筛选条件	列表项根据所选规则重新排列，排序逻辑正确	排序正确	测试成功

该模块测试的主要目的是保证用户对于自己回收订单的管理活动是准确无误的。测试主要检查订单信息的检索、查看具体的详情以及对某个订单进行删除功能的检验。回收订单管理测试用表6-4展示。

表6-4 收回订单的管理测试用例表

序号	测试功能	测试步骤	预期结果	实际结果
1	订单查询功能	用户进入回收订单管理页面，输入查询条件进行搜索	列表仅显示符合查询条件的订单记录，无关记录被过滤	一致
2	订单详情查看	用户在订单列表中选择一条记录，触发查看详情操作	系统展示该订单的全部信息，包括提交内容、处理状态和日志	符合预期
3	订单删除操作	用户对一条处于允许删除状态的订单执行删除操作	系统提示确认信息，用户确认后该订单从列表中移除	符合预期
4	查询条件重置	用户在输入查询条件后，使用重置功能	查询条件被清空，列表恢复显示所有符合条件的订单	一致

该模块测试主要考察的是回收订单详情页的主要功能。测试目的就是检验订单详情页能否准确地显示出所有的关键信息，即动态改变的审核状态信息是否及时、准确。回收订单详情页状态查看测试如下表6-5所示。

表6-5 回收订单详情页状态查看测试用例表

测试项	测试目的	测试步骤	预期结果
信息完整性呈现	验证详情页是否包含订单所有属性	用户访问处于不同处理阶段的订单详情页	页面显示该订单的完整信息集，如物品描述、时间节点、当前状态等
审核状态动态显示	验证订单审核状态的更新与显示	代理方对订单进行审核操作后，用户刷新订单详情页	详情页中的审核状态信息实时更新，与最新处理进度一致
状态流转可追溯	验证状态变更历史的可查性	用户查看一个已完成多个环节的订单详情	页面提供状态变更的时间线或日志，清晰展示流转过程

该模块测试是检验质检报告中有关用户可以访问性和展示性的有效性。测试重点就是用户能不能在指定的位置上看到对它的回收物品进行专业质检的结果，并且信息内容没有错误。质检信息查看测试如下表6-6所示。

表6-6 检验信息查看测试用例表

测试内容	测试步骤	预期结果	实际结果
质检结果访问路径	用户根据系统引导或在订单相关页面寻找质检信息入口	用户能够顺利找到并进入展示质检详情的页面	符合预期
信息内容准确性	用户查看已生成的质检报告详情	页面展示的检测项目、成色评定、问题描述等信息与代理后台录入内容完全一致	一致
信息状态关联性	用户在不同订单状态下尝试查看质检信息	仅当订单流程推进到已生成质检报告的阶段，质检信息才对用户可见并展示	符合预期

该模块对用户的异常情况上报进行测试，检验是否有效。测试目的是保证上报渠道通畅，上报的信息可以被系统正确的接收，并且产生待处理的工单记录。异常上报功能测试如表6-7所示。

表6-7 异常上报功能测试用例表

模块名称	测试内容	操作	预期结果	实际结果	结论
异常上报提交	验证用户提交异常上报的完整流程	用户在遇到问题时，填写异常类型和描述并提交	系统提示提交成功，并在后台生成一条状态为“待处理”的异常工单	成功生成	测试成功
上报信息完整性校验	验证系统对必填上报内容的校验	用户尝试提交一份描述为空或类型未选的异常上报	系统阻止提交，并提示用户补充必要信息	阻止成功	测试成功

6.4测试结果

本次测试对系统七大部分的核心用户功能模块进行全部检验。前台-物品回收模块的测试结果显示，信息提交、完整性校验和输入合法性校验功能都满足要求，用户可以创建回收请求，并且系统会对非法输入进行拦截。前台——申请领取模块测试中可以发现，申请提交流畅、重复申请限制机制发挥作用，申请人状态查询准确无误，并且功能表现一致。前台转售信息列表模块的测试表明，列表信息被加载得正确，详情跳转功能正常，数据排序逻辑没有错误，所有的测试用例都通过了。回收订单管理模块测试时，所有功能都能达到预期的目的，操作非常流畅。回收订单详情页状态查看测试验证，页面内容全部展现出来，并且审核状态的动态更新也能够被看到。质检信息查看模块会对访问途径的真实性、有效性、内容的准确性的检查，显示时跟订单流程完全一致的时候才给出展示结果。异常上报功能测试结果显示，上报提交流程完成，并且信息完整性检验有效，异常工单可以被正确创建。各个模块的功能测试结果都与预期的相符，主要业务流程运行正常。

7分析

高校二手数码产品的很多，但是长期存在着一个不健全的流通渠道，造成资源浪费、纠纷不断，学生群体实际的需求无法得到满足。根据上述状况，依据Spring Boot的二手数码校园代理回收系统设计及实现工作产生出来。该系统创建起一个连接学生用户、回收代理以及平台管理者三者之间的协作平台，其目的是将零散、自发的二手交易行为融入到标准化、信息化的管理体系中去。借助于代理审核以及线上化的流程，系统很好地克服了传统的缺点，即信息不对称、交易不透明等等问题，从而让校园里的闲置数码产品得以以一种更为安全、便捷的方式来进行价值流转和循环利用。全部的研究工作完成于从问题分析、方案设计到系统实现的闭环之中，达成预定的设计目的，给创建起绿色、可持续的校园循环经济生态赋予了一种可行的技术途径。

本文的研究工作按照标准的软件工程流程进行。首先根据需求分析来确定用户、代理和管理员这三种角色的主要要求以及功能范围。在这样的基础上，经过分层架构的思想完成系统总体的设计和详细设计，创建起包含客户展示层、应用业务层以及数据持久层的清晰的技术架构。在完成阶段选择Spring Boot作为后端开发框架，利用Vue.js和ElementUI来创建前端的界面，用MySQL做为主要的数据库并且使用Redis进行缓存优化，最后实现了系统的编码实现。用B/S架构和前后端分离的方式来实现系统的可靠性与可扩展性，保证系统能很好的进行维护和扩展。系统的大部分功能已经实现了，普通的用户可以轻松发起回收申请、确定价格、跟踪订单及做出售后服务评价；回收代理可以高效地对订单进行审核、提交报价并完成支付放款；超级管理员全部管理了代理、订单、内容和其他的一切事情。三大角色的功能模块互相配合地运行，从而保证一个从回收申请到交易完成的完整业务流程运转起来。

虽然已经实现了基本的设计目标，并且可以稳定的运行，但是由于研究周期和开发规模的原因，还存在着一些不足之处。首先，从支付端来说，系统目前只完成了支付流程的模拟以及状态记录的工作，没有和第三方支付平台对接，给交易的真实性、完整性造成了一定的影响。其次，在物流和回收环节，系统主要是依靠线上信息交互和线下人工协作来完成的，缺少了对回收路径进行智能规划、优化算法的支持，从而影响到代理人员线下作业效率。另外，系统的大量的交易数据还没有被深入分析和挖掘出来，不能发挥出它在用户行为分析、市场趋势预测等方面所具有的巨大潜力。最后，目前系统部署的方式和服务器配置大多集中在开发、测试阶段，对于很多用户的并发访问来说，它的性能状况和发展稳定性还不是很突出。

根据以上缺陷，本文将从以下方面来开展研究。首要的任务就是建立成熟的第三方支付接口，比如支付宝或者微信支付等，创建起真实、可靠的线上资金交易渠道。另外可以利用地图API和智能调度算法来为代理人员设计出最优的上门回收路线，提高线下作业的智能化程度以及效率。数据价值挖掘可以采用大数据分析技术，对回收品类、价格走势、用户喜好等各方面展开深入分析，并给平台的精细运作以及决议提供数据支持。从更宽广的角度来看，该系统架构模式和业务逻辑有较好的可复制性，将来可以尝试将它应用于更多的校园物资回收场景当中，并且也可以把它当作一个区域性循环经济服务平台的基座来使用，它的社会价值和社会意义也是十分明显的。

参考文献

1. 秦彦悦,安尘潇,李云,等. FP-Growth算法在校园二手商品推荐系统中的应用[J].计算机时代,2025,(05):35-39.
2. 王明松,于营. 基于微信小程序的二手物品交换系统[J].电子质量,2024,(11):70-73.
3. 崔臣,宋甲旭. 基于SpringBoot的校园二手交易系统研究[J].无线互联科技,2023,20(18):31-34.
4. 周姣. 基于微服务架构的高校二手物品交易系统设计与实现[J].电脑知识与技术,2023,19(22):67-70.
5. 王颖.社区二手物品处置系统研究与设计[D].哈尔滨理工大学,2022. 
6. 陈春龙.基于混合推荐的校园二手交易系统的研究与实现[D].辽宁大学,2022. 
7. Chi H ,Chenglian L ,I C S C . Research on the Used Car System Based on Blockchain and Cryptographic Technology[J].WSEAS TRANSACTIONS ON COMPUTER RESEARCH,2022,10105-111.
8. Zhang J ,Lv T . Design and implementation of second-hand housing data statistical analysis system[J].Financial Engineering and Risk Management,2021,4(4).
9. Hejing W ,Ran C . Research on Data Collection and Analysis of Second Hand House in China Based on Python[J].International Journal of Advanced Network, Monitoring and Controls,2021,6(2):37-47.
10. 熊威. 基于项目驱动的Java编程基础教学研究与实践[J]. 中国教育技术装备,2023(2):80-82. 
11. 韩小龙,司珍,吕晓峰,等. 基于面向对象编程的Java语言程序设计方法分析[J]. 集成电路应用,2024,41(1):228-229. 
12. 陈蓓蕾,洪年松. 基于SpringBoot的数据库接口设计[J]. 信息与电脑,2023,35(16):181-183. 
13. 王志亮,纪松波. 基于SpringBoot的Web前端与数据库的接口设计[J]. 工业控制计算机,2023,36(3):51-53. 
14. 八度云计算（安徽）有限公司.一种基于Vue框架的UI组件库创建方法：CN202311590956.7[P].2024-03-29.
15. 李晓薇. vue.js前端应用技术分析[J]. 网络安全技术与应用,2022(4):44-45. 
16. 庞敏. MySQL数据库的数据安全应用设计技术研究[J]. 数字通信世界,2024(9):25-27. 
17. 柳青,程晨. MYSQL数据库技术应用一体化课程开发研究[J]. 造纸装备及材料,2024,53(5):251-253. 
18. 谷春红. 基于B/S结构的高校教材管理系统设计与实现[J]. 海峡科学,2024(3):117-122. 
19. 赵惠. 基于B/S模式的实验室管理系统设计和实现[J]. 中国新通信,2023,25(21):72-74. 
20. 陈倩怡,何军.Vue+Springboot+MyBatis技术应用解析[J].电脑编程技巧与维护,2020,(01):14-15+28.
21. 何金龙. 电子信息工程计算机数据库应用[C]//2024智慧施工与规划设计学术交流会论文集. 2024:1-3.
22. 张晓蕾,王斌,郭锡泉. "互联网"背景下数据库应用技术课程思政教学设计与实践[J]. 现代商贸工业,2024(23):251-253. 
23. 罗超,彭玉涛. 计算机软件测试方法的研究分析[J]. 长江信息通信,2023,36(2):83-85. 

致谢

时光消逝，到此为止，表示大学生活将结束。回顾毕业设计之路，对这所给予我无限关怀和温暖的学校充满深深的感激之情。我首先要对我的校内指导教师表示衷心的感谢。从课题初步选择到最后方案确定，从开题报告反复打磨到论文撰写尽心批阅，老师的深厚学术功底与严谨治学态度给我的提供持续且宝贵的支持。在遇到困难的时候，老师指点会有豁然开朗的感觉，这也是严谨求实、科研精神的体现。另外，还要真诚地对这段时间里所得到的帮助表示谢意。非常感谢分享宝贵的经验，系统架构的设计和功能实现上的具体建议给我的工程实践赋予了丰富的实践基础，让理论知识得以转化为可以落地的应用解决方案。

本次毕业设计的顺利完成，对于我来说不但是学业任务的圆满解决，也是对能力的一种全面培养和提高。起初面对复杂的需要时的迷茫，经过文献研究、技术学习逐渐理清思路；遇到编码调试中各种技术瓶颈的时候，经过反复尝试和团队讨论最后攻克它，整个过程中充满着挑战，同时也获得无与伦比的成就感。它对我的大学四年所学的专业知识进行了系统的检验和巩固，并且使我把离散的理论知识联系起来成为一个可以解决实际问题的完整体系。这次经历给我带来理论与实践之间存在着怎样的联系有更深层的认识，也使我对以后的职场发展打下了一些基础。

谢谢我的所在学校，给我们的学习创造了良好的条件以及丰富多样的学术资源。非常感谢辅导员老师多年来对我的悉心关怀和帮助，也感谢所有的授课老师，是你们循循善诱的教导，给我的专业学习打下了良好的基础。此外要对一直陪伴在身边，支持我并且在我做实验的时候、当我学习的时候与我一起的人们表示衷心的感谢。在图书馆里一起并肩作战的记忆里，有和大家一起讨论问题、分享心得的时候。你伴随着，支持，真诚的协助给我留下了难以磨灭的记忆，我在求学时得到你的陪伴、鼓舞和真实帮忙。这份宝贵的人脉让我心存感激。

最后，真诚地对我的深爱的家庭说一声“谢谢”。非常感谢母亲从不因为劳动而放弃自己的工作，一直认为是你来给生活提供无私的奉献与支持、默默付出，在于帮助你去追求自己心中美好的未来。即将开始新的人生之旅，以最完全的感激、收获和希望，开始新的工作，并且也感谢一直支持鼓励过我的人。

请关注点赞+私信博主，免费领取项目源码