软件工程综合实践3实验报告——校园二手交易平台系统（黑龙江大学）

实验一项目开发计划说明书

1 引言

1.1 编写目的

为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。

1.2 背景

项目名称：二手校园交易平台

提出者：xxx

开发者：xxx、xxx、xxx、xxx

用户：在校师生

智能手机功能的完善满足了生活中的各种需求，二手交易平台的开发流行起来，实现了商品的线上交易渠道。互联网的兴起方便了人们的生活，改变了传统的生活方式。过去闲置物品只能出售给收荒匠或堆在角落，偶尔的跳蚤市场才有一定几率让部分闲置物品以合适的价格出售。二手交易平台的出现解决了这一问题，汇集线上信息化资源，打造便捷的商业交易环境，形成了完整的二手电商商业模式，满足用户对闲置物品处理和二手商品购买的需求，具有明朗的市场发展空间。

1.3 定义

SQL：一种用于访问查询数据库的语言。
UML：统一建模语言，是一套用来设计软件蓝图的标准建模语言，是一种从软件分析、设计到编写程序规范的标准化建模语言。

1.4 参考资料

软件需求说明书编写规范。
软件工程国家标准文档。
二手交易平台管理系统需求说明书。

2 项目概述

2.1 工作内容

需求设计分析：在用户的参与下完成对于系统需求的详细分析，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。

软件开发：软件源程序的编写。

软件测试：对于初步成型的软件的功能测试。

软件运营及维护：软件的运营即更新维护支持。

2.2 主要参加人员

表2-1 主要参与人员表

|----|-----|----------|
| 序号 | 人员 | 工作内容 |
| 1 | xxx | 需求分析、测试 |
| 2 | xxx | 开发、测试、维护 |
| 3 | xxx | 开发、测试、维护 |
| 4 | xxx | 开发、测试、维护 |
| 5 | xxx | 开发、测试、维护 |

2.3 产品

2.3.1 程序

项目名称：校园二手交易平台

编程语言：Spring Boot+Mybatis-Plus

开发工具 IntelliJ IDEA 2023.3.6

数据库MySQL

功能：

（一）普通用户

添加商品到购物车、预订商品
前台登录、通过邮箱接受验证码注册和找回密码
查看和修改个人信息
发布商品和管理自己发布的商品（修改、删除、查询、上架、下架、完成交易、取消商品被预订）
管理自己的联系方式（添加、修改、删除、查询）
查看预订记录以及取消预订
查看自己的消息
给管理员留言以及管理自己的留言（查询、修改、删除）

（二）管理员

管理普通用户（添加、修改、删除、查询、封禁与取消封禁）
商品类别管理（添加、修改、删除、查询）
商品管理（查询、删除、审核商品、推荐商品）
管理用户联系方式（修改、删除、查询）
管理用户留言（答复用户的留言、删除、查询）
管理首页的轮播图（添加、修改、删除、查询）
管理公告（添加、修改、删除、查询）
管理预订记录（查询、删除）
管理用户消息（查询、删除）
安全退出后台

2.3.2 文件

项目需求分析说明书：所开发软件的功能、性能、用户界面以及运行环境等做出详细说明
数据要求说明书：确定各项功能和非功能性需求实现时所需要的数据
概要设计文档：系统的功能分配、模块划分、程序的总体结构、输入输出及接口设计、运行设计、数据结构设计和出错处理设计等
详细设计文档：详细的列出开发的方式，如何编写代码等内容，着重描述功能模块是如何实现的，包括算法和逻辑流程等
测试计划：列出测试方案和预期的测试结果等
操作手册：让用户了解软件的运行情况与操作方法

2.3.3 服务

表2-2 用户服务表

|------------|--------------|--------------|--------------|--------------|
| 序号 | 服务名称 | 开始时间 | 支持级别 | 服务期限 |
| 1 | 日常维护 | 2024/05/06 | 高 | 三年 |
| 2 | 运行支持 | 2024/05/06 | 高 | 三年 |
| 3 | 操作引导 | 2024/05/06 | 高 | 三年 |

2.3.4 非移交的产品

项目开发计划书：表明该项目的计划时间、计划内容、参与人员、负责项目部分、应用资源等多项详细计划内容，方便在编写程序的时候严格执行该计划，有明确的目标和行动力。
需求规格说明书：通过用户对于本系统的需求描述，开发人员将其所提到的内容归纳并达成一致后撰写的文档，包括本系统的功能、内容、界面内容、性能等信息进行详细的描述，能更加完善系统的功能、符合用户的需求。
系统设计说明书：将通过所设计功能的系统细化分成多个部分，包括代码模块、接口设计、功能划分、出错处理等。便于以后的代码编写和逻辑组合。
项目开发总结：本系统开发结束以后，对于整个系统的功能、性能和操作的整合，与计划相对比得出总结。
源程序：实现系统的全部代码。

2.4 验收标准

文档验收：

文档验收是确保项目文档符合要求并完整的过程。在项目开发过程中，各种文档如需求文档、设计文档、测试文档等都需要经过验收。文档验收的主要目的是确保文档内容准确、清晰，并且满足项目需求。在文档验收过程中，通常会有相关人员对文档进行审查、确认和批准。

代码验收：

对开发完成的代码进行检查和确认，以确保代码质量符合标准和项目需求。在代码验收过程中，通常会进行代码审查、单元测试、集成测试等活动，确保代码的功能完整、正确性高以及可维护性强。代码验收的目的是提高代码质量，减少潜在缺陷，并确保项目按时交付。

服务验收：

进行功能测试、性能测试、安全测试等活动，以验证服务的可用性、稳定性和安全性。服务验收的主要目的是保证服务达到预期效果，并为用户提供良好的体验。

2.5 完成项目的最迟期限

从2024年5月6日开始到2024年6月24日，本校园二手交易系统会完成的项目计划书、需求规格说明书、系统设计说明书、源代码编写、总结报告等相关报告的撰写和全部代码的编写并通过验收标准，交付给用户。

2.6 本计划的批准者和批准日期

批准者：xxx

批准日期：2024年5月6日

3 实施计划

3.1 工作任务的分解与人员分工

需求分析阶段

需求分析阶段人员分工如表3-1所示。

表3-1 需求分析阶段人员分工表

|-----|------|-------------|-----------------|
| 姓名 | 角色 | 职位 | 项目任务 |
| xxx | 项目经理 | 需求分析总负责人 | 对产品的所有需求进行完整性分析 |
| xxx | 项目经理 | 产品功能性需求负责人 | 对产品的功能性需求进行分析 |
| xxx | 项目经理 | 产品非功能性需求负责人 | 对产品的非功能需求进行分析 |
| xxx | 项目经理 | 产品运行环境需求负责人 | 对产品运行环境需求进行分析 |

项目设计阶段

项目设计阶段人员分工如表3-2所示。

表3-2 项目设计阶段人员分工表

|-----|------|-----------|-------------------|
| 姓名 | 角色 | 职位 | 项目任务 |
| xxx | 项目经理 | 项目设计总负责人 | 对整个项目完成总体性设计 |
| xxx | 项目经理 | 程序内部设计负责人 | 对完整程序内部接口，软件结构的设计 |
| xxx | 项目经理 | 用户界面设计负责人 | 对软件用户界面设计 |
| xxx | 项目经理 | 数据库设计负责人 | 对软件所需数据库结构设计 |

项目实现和测试阶段

项目实现和测试阶段人员分工如表3-3所示。

表3-3 项目实现和测试阶段人员分工表

|-----|------|-------------|-------------------------|
| 姓名 | 角色 | 职位 | 项目任务 |
| xxx | 项目经理 | 项目实现和测试总负责人 | 评审软件，项目规划，编写项目文档 |
| xxx | 项目经理 | 项目实现负责人 | 评审软件，编写程序项目文档 |
| xxx | 项目经理 | 项目实现负责人 | 评审软件，编写数据库文档 |
| xxx | 项目经理 | 项目测试负责人 | 测试软件，编写项目测试文档 |
| xxx | 研发主管 | 项目研发负责人 | 审核程序，分配项目 |
| xxx | 开发人员 | 编码工程师 | 程序框架与数据库的建立，服务器的搭建，编写代码 |
| xxx | 开发人员 | 编码规范设计师 | 统一编码风格 |
| xxx | 测试人员 | 程序测试工程师 | 测试整体程序 |
| xxx | 测试人员 | 数据库测试工程师 | 测试数据库 |

项目运营和维护阶段

项目运营和维护阶段人员分工如表3-4所示。

表3-4 项目运营和维护阶段人员分工表

|-----|------|-------------|----------------|
| 姓名 | 角色 | 职位 | 项目任务 |
| xxx | 项目经理 | 项目运营维护总负责人 | 运营系统，修改记录、修改报告 |
| xxx | 项目经理 | 项目软件运营维护负责人 | 调试软件系统，修改记录 |
| xxx | 项目经理 | 项目硬件运营维护负责人 | 调试硬件系统，修改记录 |
| xxx | 项目经理 | 项目维护负责人 | 维护系统，修复bug |
| xxx | 维护人员 | 软件维护负责人 | 维护软件系统 |
| xxx | 维护人员 | 硬件维护负责人 | 维护硬件系统 |
| xxx | 运营主管 | 项目运营负责人 | 组织项目后期运营工作 |
| xxx | 运营人员 | 项目运营工程师 | 后期运营 |

3.2 接口人员

负责本项目同用户的接口人员:xxx

主要负责与用户保持密切沟通,及时了解用户的需求变化和反馈,并将信息传达给项目团队。协调用户与项目组之间的问题,确保用户需求得到满足。定期组织用户评审会议,收集用户意见并推动改进。

负责本项目同本单位各管理机构的接口人员:xxx

合同计划管理部门接口人员:负责项目合同管理、进度计划控制等工作。财务部门接口人员:负责项目费用预算、审核、付款等财务管理工作。质量管理部门接口人员:负责项目质量目标制定、质量检查、验收等工作。这些接口人员需要与项目团队保持密切协作,确保各项管理工作顺利进行。

负责本项目同外部合作单位的接口人员:xxx

主要负责与其他参与单位的沟通协调,确保各方工作任务明确,相互配合。协调解决跨单位间的问题和矛盾,确保项目整体进度和质量目标实现。定期组织各参与单位的联席会议,共同研究和解决项目推进中的问题。

3.3 进度

对于需求分析、设计、编码实现、测试等工作，设计出每项工作的预定开始日期、完成日期，规定了各项工作任务完成的先后顺序以及里程碑。关键里程碑表如表3-5所示。

表3-5 关键里程碑表

|------------|-----------------------|-----------------------------|-------------|
| 名称 | 时间 | 提交产品 | 评审人 |
| 项目启动 | 2024.05.06-2024.05.20 | 项目开发计划书 | xxx |
| 需求分析 | 2024.05.20-2024.05.27 | 静态原型、需求规划、软件需求规范 | xxx |
| 设计实现 | 2024.05.27-2024.06.03 | 架构设计规范、概要设计规范、测试用例、用力手册、源代码 | xxx |
| 系统集成测试 | 2024.06.03-2024.06.10 | 测试报告 | xxx |
| 系统实施 | 2024.06.10-2024.06.17 | 验收报告 | xxx |
| 系统试运营 | 2024.06.17-2024.07.01 | 调试系统修改记录、修改报告 | xxx |

3.4 预算

本项目的预算主要用于人员劳务、资料费及设备的租金费用等。详细预算如表3-6所示。

表3-6 成本估算表

|---------|-------|------|------|--------|
| 任务 | 时长/pd | 工资/元 | 人数/个 | 累计/元 |
| 项目开发计划 | 2 | 1200 | 2 | 5000 |
| 需求规约说明书 | 2 | 1200 | 2 | 5000 |
| 总体设计 | 3 | 1500 | 2 | 9000 |
| 概要设计 | 1 | 1000 | 3 | 3000 |
| 详细设计 | 2 | 1200 | 2 | 4800 |
| 编码 | 8 | 1000 | 3 | 24000 |
| 代码测试 | 2 | 2000 | 2 | 8000 |
| 修改错误 | 2 | 1500 | 2 | 6000 |
| 核对需求 | 4 | 1500 | 2 | 12000 |
| 交付代码 | 4 | 1500 | 1 | 6000 |
| 上线运行 | 2 | 1200 | 1 | 4800 |
| 用户测试 | 5 | 1400 | 3 | 210000 |
| 内部人员测试 | 3 | 1200 | 3 | 108000 |
| 形成完整程序 | 1 | 1000 | 1 | 1000 |
| 总计 | 121400 ||||

3.5 关键问题

本项目的成败还受许多因素影响，项目风险因素如表3-7所示。

表3-7 项目风险因素表

|------|----------|------------------------------|---------------------|
| 风险排序 | 风险项名称 | 风险描述 | 风险缓解方案 |
| 1 | 专业基础知识不牢 | 本次项目开发过程涉及知识较多，给项目开发人员带来一定困难 | 进行相应培训 |
| 2 | 经验缺乏 | 成员开发经验不足，使项目质量难以保证 | 不断实践 |
| 3 | 软件性能影响 | 本次开发过程中部分软件可能容易出现死机现象 | 选择合适的软件，搭建良好的配置开发环境 |

4 支持条件

4.1 计算机系统支持

服务器CPU+Intel+E3300，内存2G以上，⽹络适配器1000MB的⽹卡。

⽹络环境：4M+ADSL或光缆。

软件环境：客户机win11。使用开发工具为Visual Studio Code、Eclipse，数据库为Mysql。

4.2 需由用户承担的工作

信息收集:用户需要提供项目所需的相关信息和资料,包括但不限于项目背景、目标、现状等。提供时间:项目启动后1周内。
需求分析:用户需要参与需求分析工作,确认项目的具体需求。提供时间:项目启动后2周内。
方案设计:用户需要审核并提供反馈意见,对方案进行确认。提供时间:方案设计完成后1周内。
实施执行:用户需要配合项目组,提供必要的支持和协助,确保项目顺利推进。提供时间:整个项目实施阶段。
验收测试:用户需要参与验收测试,确认项目结果符合预期要求。提供时间:项目实施完成后1周内。
项目交接:用户需要接收项目结果,并做好相关的培训和知识转移。提供时间:项目验收完成后2周内。

5 专题计划要点

5.1 人员培训计划

编程人员需要对该项目的编译环境有一定的了解，对于专业水平不高的人员，在详细涉及钱需要自学培训，包括Web数据库、面向对象开发、网页制作等，预计两周时间完成。如下表5-1所示。

表5-1人员培训计划

|----------------|---------------|--------|
| 培训内容 | 时间 | 参与者 |
| 数据库、网页 | 第一周（第一周周一到周三） | 全体开发人员 |
| JSP、JavaEE架构配置 | 第一周（第一周周四和周五） | 全体开发人员 |
| Rose使用 | 第二周（第二周周一到周三） | 全体开发人员 |
| Java | 第二周（第二周周四和周五） | 全体开发人员 |

6 可行性分析

6 .1 项目意向：

本项目旨在构建一个校园内部的二手交易系统，以数字化的方式促进物品的再利用，减少资源浪费，并为用户提供一个安全可靠的交易环境。项目的核心目的在于搭建一个用户友好的平台，通过该平台，学生和教职工能够轻松发布、浏览和购买二手商品。

6 .2 政策支持：

当前教育部门鼓励高校推动绿色校园建设，其中包括推广资源的循环利用。此外，国家对于信息技术的创新应用持积极态度，特别是那些能够提升教育质量和效率的项目。因此，本项目符合国家推动教育信息化和绿色发展的政策导向。

6 .3 二手交易市场行业发展现状：

校园二手交易市场具有巨大的潜力。随着学生群体对于环保意识的提升和经济实惠的追求，二手交易需求稳步增长。然而，现有的交易方式多为非正式的个人行为，缺乏有效的管理和安全保障措施，这为本项目的实施提供了切入点。

6 .4 服务对象：

服务对象主要涵盖了校园内的学生、教职工以及其他校园社区成员。学生群体作为主要的二手物品买卖参与者，他们的需求多样且频繁，包括教科书、电子产品、生活用品等。教职工则可能涉及到教学设备、办公物资等更为专业的二手物品交易。其他校园社区成员，如校友、访客等，也可能成为潜在的交易参与者，增加交易的多样性和活跃度。

6 .5 关键性问题

安全性问题，由于缺乏官方的监管和认证机制，交易过程中可能出现欺诈行为，用户的个人信息和财产安全难以得到保障。

效率问题，当前的交易多依赖于口口相传或社交媒体群组，这种方式信息分散，难以快速匹配买卖双方。

便捷性问题，缺少一个统一的平台来集中展示和管理交易信息，导致用户体验不佳。

6 .6 解决方法

该系统应包含用户身份验证功能，以确保交易的安全性
系统需要具备高效的搜索引擎和智能推荐算法，以提高交易匹配的效率
系统界面应简洁易用，操作流程简化，以提升用户的整体交易体验。通过这些解决方案，我们能够构建一个安全、高效、便捷的校园二手交易环境，满足用户需求，同时促进校园内部资源的合理流通和利用。

6 .7 厂址

在厂址选择上，考虑到项目的服务对象主要是校园内的成员，数据中心的建设应优先考虑校园内的网络基础设施和物理空间。

6 .8 项目进度

表3-5 关键里程碑表

6 .9 主要成本

研发成本，办公场地，人员工资，宣传成本。

6 .10 团队规模

调研人员：5人；开发及技术人员：3人；管理人员：3人；维护人员：3人。

6 .11 项目建设必要性

项目建设的必要性在于其对环境、经济和社会文化的深远影响。环境层面，校园二手交易系统的建立将减少资源浪费，延长物品使用寿命，有助于构建低碳校园。经济层面，该系统能够为学生节省开支，同时创造新的就业机会和商业价值。社会文化层面，它促进了校园内的社区互动，增强了学生的环保意识和社会责任感。

6 .12 项目的生命周期

开发期：2个月；维护期：3年；项目预计寿命：5年以上。

6 .13 资金

12.1万元。

6 .14 资金来源

银行贷款12.1万元。

银行贷款还款方式为：等额本息6年后完全偿还，根据银行贷款利息5.31%，计算可得支付利息为2.876万元，还款总额为14.976万元。

实验二需求规格说明书

1 文档简介

本文档为校园二手交易平台系统需求规格说明书"。本需求规格说明书详细地描述了这款校园二手交易平台系统预期实现的各项功能，并提供UML用例图及详细的用例描述。

1.1 文档目的

此需求规格说明书描述了用户需求，明确了系统功能内容、功能边界、开发途径，是项目组全体人员的参考资料。

1.2 背景

随着科技的飞速发展，计算机科学已经深入到人类社会的各个角落，并在其中发挥着不可或缺的作用。计算机功能的不断增强已经得到了人们的广泛认可，它不仅引领了现代社会的技术潮流，而且在各领域均展现出了其不可替代的价值。在计算机应用的众多分支中，利用计算机对二手交易平台进行管理成为了一种极具前瞻性的选择。这种现代化的管理方式以其高速的检索能力、便捷的操作过程、显著的效率提升、低廉的成本以及庞大的存储容量等优势，为传统的交易模式带来了革命性的改变。这些优势无疑极大地提升了管理和执行业务流程的效率。

此系统的用户群体定位于那些热衷于二手商品买卖的人们，为他们提供一个方便、高效的交易环境。系统采用JavaScript编写，实现了与数据库的无缝交互，从而构建了一个既充分利用网络优势又结合线下销售优点的综合性平台。依托先进的数据库管理技术，我们致力于开发一个规范化、个性化的在线二手交易平台，让交易变得更加简单、便捷且安全。

1.3 参考资料

编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位如表1-1所示。

表1-1 参考文件

|--------------|---|---|---|----|----|---|---|
| 资料名称 | 简介 ||| 作者 | 日期 | 出版单位 ||
| 数据库系统概论（第5版） | 介绍有关数据库的SQL语言、数据库设计 || 王珊、萨师煊 || | 高等教育出版社 ||
| 网点 || 简介 |||||
| 数据库系统概论课后习题答案（第五版王珊、萨师煊）_数据库系统概论第五版课后答案-CSDN博客 || 数据库系统概论"是计算机科学与技术专业、软件工程专业、信息系统与信息管理等专业重要的专业基础课程。本课程将系统讲述数据库系统的基础理论、基本技术和基本方法。本课程的知识内容和技术方法，对从事现代数据管理技术的应用、开发和研究的人员都是重要而必备的基础。 |||||

1.4 术语与缩写解释

UML：统一建模语言或标准建模语言。

SQL：结构化查询语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。

2 系统产品介绍

2.1 项目来源与目标

本款二手商品系统旨在为客户提供其想购买的二手商品的销售信息，并提供评价平台。应用目标一是使用户能够及时快速的获取二手商品信息。二是构件一个二手商品交易市场，使物品利用率提高，节约资源。三是为人们购买物品省下一些钱。作用范围是社会各种人群。人们可以通过二手商品系统筛选物品信息获取自己需要的商品。

2.2 系统（或用户）的特点

本款二手商品系统功能在个人PC上使用，是用户群体遍布各个阶层。

本系统采用B/S结构编写，前端后台具有分工明确和维护方便的特点。

本款二手商品系统具有实时更新货品信息的特点。

市场上也有类似软件，如:咸鱼：与咸鱼相比较，本款二手具有针对卖家出售资格审核以确保客户购买商品有保障的特点。

2.3系统需要解决的主要问题

针对以上现有系统存在的问题分析，提取新系统需要解决的主要问题列举与问题定义如表2-1所示。

表2-1 问题分析

|------|------------------------------------|
| 问题类别 | 问题详情 |
| 性能 | 吞吐量：网站人多的时候会变得卡响应时间：订单提交后后滩处理时间过长 |
| 信息 | 输出：1.商品介绍不完整2.订单详情不完整输入：销售信息易被修改 |
| 效率 | 二手商品卖方不能及时回复消息，沟通效率慢，交易时间过长 |
| 服务 | 若客户购买的商品不满意可通过客服人员办理退货 |

3 产品的功能性需求

3.1 确定业务参与者

采用参与者词汇表进行描述，如表3-1所示。

表3-1 参与者词汇表

|------------|------------|-------------|---------------------|
| 序号 | 词汇 | 同义词 | 描述 |
| 1 | 用户 | | 注册了账号的个人 |
| 2 | 卖家 | 用户 | 完善个人信息的用户 |
| 3 | 买家 | 用户 | 未完善个人信息的用户 |
| 4 | 平台管理员 | 管理员 | 系统内含的固定用户。负责解决用户纠纷。 |

3. 2 用例模型描述

3. 2 .1建立系统上下文用例模型

系统上下文用例图如图3-1所示。

图3-1 系统上下文用例图

3. 2 .2 用例词汇表

表3-2 用例词汇表

|--------------|--------------------------------------|----------------|
| 用例名称 | 用例描述 | 参与者和角色 |
| 上架商品 | 用户将希望出售的商品的详细信息提供给系统，并由此使得其他用户能够自由查看 | 用户 |
| 下架商品 | 用户将已经上架且有库存余额的个人的上架商品下架 | 用户 |
| 搜索商品 | 查看所有用户上架的且有库存余额的商品 | 用户 |
| 发布公告 | 用户购买支付购物车中所有的商品 | 用户 |
| 提交投诉 | 用户对已经完成的订单产生纠纷且需要平台介入处理时，向系统提交具体情况描述 | 用户平台管理员 |
| 绑定银行卡 | 用户确认已经支付的订单，使交易完成 | 用户 |
| 评价交易 | 用户查看自己的简单订单列表 | 用户 |
| 编辑个人信息 | 用户查看自己的详细订单信息 | 用户 |
| 支付结算 | 用户查看购物车中的简单商品列表 | 用户 |
| 登录 | 用户删除购物车中的商品列表中的某一项 | 用户 |

3. 2 .3系统用例模型图

本系统的用例模型如图3-2所示。

图3-2 系统用例模型图

3. 2 .4 用例描述

上架商品用例描述如下：

表3-3 上架用例描述（xxx编写）

|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 上架商品 |
| 用例ID | MSM1101 |
| 用例类型 | 业务用例 |
| 参与者 | 个人信息完整的用户 |
| 描述 | 用户向系统提交商品的详细信息。 |
| 前置条件 | 用户登录且绑定信息完整。 |
| 后置条件 | 用户成功上架商品。 |
| 触发条件 | 用户成功上架商品。 |
| 基本流程 | 1.用户开始上架商品。 2.系统检查用户信息（学号、联系方式、姓名、身份证号、寝室门牌号）是否完整，若完整跳转至商品信息填写界面。 3.用户填写商品信息（商品名称、商品价格、商品数量）。 4.系统检查商品信息（商品价格、商品数量）完整正确，若完整且正确回显商品上架成功提示。 5.商品成功上架。 |
| 替代流程 | 2a.用户信息完整，跳转至商品信息填写界面。 2b.用户信息不完整，用户需完善个人信息。 4a.商品信息完整且正确，系统回显上架成功提示。 4b.商品信息不完整或不正确，用户需修改商品信息。 |
| 结束 | 用户商品上架成功。 |
| 待解决问题 | 无。 |

上架商品用例活动图如图3-3所示。

图3-3 上架商品用例活动图（xxx绘制）

下架商品用例描述如下：

表3-4 下架商品用例描述（xxx编写）

下架商品用例活动图如图3-4所示。

图3-4 下架商品用例活动图（xxx绘制）

编辑个人信息用例描述如下：

表3-5 编辑个人信息用例描述（xxx编写）

|----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 编辑个人信息 |
| 用例ID | MSM1103 |
| 用例类型 | 业务用例 |
| 参与者 | 每个用户，系统 |
| 描述 | 该用例允许已注册的用户更新或修改他们的个人资料信息。用户可以通过此功能更改其姓名、联系方式、密码等个人信息。 |
| 前置条件 | 用户必须已经登录到系统。 |
| 后置条件 | 用户的个人信息将被更新，并在系统中反映出来。 |
| 触发条件 | 用户希望更新或更改存储在系统中的个人数据。 |
| 基本流程 | 1. 用户登录到系统。 2. 用户点击"个人资料"或"设置"链接。 3. 系统显示用户的当前个人信息。 4. 用户选择要编辑的信息字段，如姓名、联系方式、密码等。 5. 用户输入新的信息并点击"保存"按钮。 6. 系统验证新信息的有效性。 7. 如果新信息有效，系统将更新用户的个人信息。 8. 系统显示更新成功的信息。 |
| 替代流程 | 7a. 如果用户输入的新信息无效或不符合要求，系统将显示错误消息，并要求用户重新输入。 |
| 结束 | 用户成功修改个人信息 |
| 待解决问题 | 无 |

修改个人信息用例活动图如图3-5所示。

图3-5 编辑个人信息用例活动图（xxx绘制）

管理员发布系统公告用例描述如下：

表3-6 管理员发布系统公告用例描述（xxx编写）

|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 管理员发布系统公告 |
| 用例ID | MSM1104 |
| 用例类型 | 业务用例 |
| 参与者 | 管理员 |
| 描述 | 管理员在平台发布系统公告 |
| 前置条件 | 管理员必须已经以管理员身份登录系统。管理员需要进入"管理通知公告"页面，其中列出了已有的通知公告清单。 |
| 后置条件 | 系统公告成功发布，用户可在网站首页或其他指定位置看到新发布的公告。系统数据库更新，反映了新的公告信息状态。 |
| 触发条件 | 管理员决定发布新公告或更新现有公告。系统要求发布重要信息或变更通知。 |
| 基本流程 | 1. 管理员在后台登录系统，进入公告管理界面。 2. 管理员点击"发布公告"按钮，进入公告编辑页面，填写公告标题、内容、发布时间等信息。 3. 管理员点击"预览"按钮，查看公告效果。如果满意，点击"提交"按钮，将公告信息提交至系统审核。 4. 系统自动对公告内容进行审核，如无违规内容，审核通过。 5. 管理员再次确认发布，公告信息将在指定时间自动发布至网站首页或其他指定位置。 |
| 替代流程 | 4.如果系统审核未通过，管理员需根据反馈修改公告内容后重新提交。 |
| 结束 | 管理员成功发布系统公告 |
| 实现约束和说明 | 管理员必须有相应的权限才能进行公告的发布。公告内容应符合相关法律法规，避免包含敏感词汇。公告发布时间应准确，确保用户能够及时接收到信息。 |
| 待解决问题 | 无 |

管理员发布系统公告用例活动图如图3-6所示。

图3-6 管理员发布系统公告用例活动图（xxx绘制）

修改商品用例描述如下：

表3-7 修改商品用例描述（xxx编写）

|----------|---------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 修改商品 |
| 用例ID | MSM1102 |
| 用例类型 | 业务用例 |
| 参与者 | 个人信息完整的用户 |
| 描述 | 用户修改商品的详细信息。 |
| 前置条件 | 用户登录且绑定信息完整且该商品已上架。 |
| 后置条件 | 用户成功修改商品信息。 |
| 触发条件 | 用户修改商品信息。 |
| 基本流程 | 1.用户开始修改商品信息。 2.系统检查用户信息（学号、联系方式、姓名、身份证号、寝室门牌号）是否完整，若完整跳转至商品信息界面。 3.用户可修改商品信息（商品名称、商品价格、商品数量）。 4.系统检查商品信息（商品价格、商品数量）是否正确，若正确显示修改成功提示。 5.商品信息成功修改。 |
| 替代流程 | 2a.用户信息完整，跳转至商品信息界面。 2b.用户信息不完整，用户需完善个人信息。 4a.商品信息完整且正确，系统显示修改成功提示。 4b.商品信息不正确，用户需重新修改商品信息。 |
| 结束 | 用户修改商品信息成功。 |
| 待解决问题 | 无。 |

修改商品用例活动图如图3-7所示。

图3-7 查询订单列表用例活动图（xxx绘制）

搜索商品用例描述如下：

表3-8 搜索商品信息用例描述（xxx编写）

搜索商品用例活动图如图3-8所示。

图3-8搜索商品用例活动图

绑定银行卡用例描述如下：

表3-9绑定银行卡用例描述（xxx编写）

|----------|-------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 绑定银行卡 |
| 用例ID | MSM1006 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 每个用户 |
| 其他参与者 | 无 |
| 描述 | 用户在平台上绑定自己的银行卡，以便进行支付操作 |
| 前置条件 | 用户已注册并登录到平台 |
| 后置条件 | 用户成功绑定银行卡 |
| 触发条件 | 用户点击绑定银行卡按钮 |
| 基本流程 | 1. 用户点击绑定银行卡按钮 2.系统回显绑定银行卡页面 3.用户输入银行卡信息 4.系统验证银行卡信息 5.用户确认银行卡信息 6.系统保存银行卡信息 7.系统回显绑定成功提示 |
| 替代流程 | 4a. 系统验证银行卡信息失败，系统回显错误提示 4b. 用户未确认银行卡信息，系统回显取消绑定提示 |
| 结束 | 用户成功绑定银行卡 |
| 待解决问题 | 无 |

绑定银行卡用例活动图如图3-10所示。

图3-10绑定银行卡用例活动图（xxx绘制）

交易评价用例描述如下：

表3-11 交易评价用例描述（xxx编写）

|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 交易评价 |
| 用例ID | MSM1206 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 买家 |
| 其他参与者 | 系统、卖家 |
| 描述 | 买家在确认收货后对商品和卖家服务进行评价，以反映交易满意度 |
| 前置条件 | 买家已成功确认收货 |
| 后置条件 | 买家完成评价，评价信息被记录 |
| 触发条件 | 买家点击进行评价 |
| 基本流程 | 1. 当买家决定分享他们的购物体验时，他们只需轻轻点击"进行评价"按钮。 2. 这一动作会立即引领他们进入一个专门设计的评价页面，这里既是他们表达满意与否的舞台，也是他们分享个人使用感受的空间。 3. 在这个页面上，买家被鼓励填写详细的评价内容，这不仅包括了对商品的评分，还有对商品及卖家服务的文字评述。完成后，买家轻松点击提交，将他们的反馈传递给系统。 4. 系统在收到评价后，会进行一系列的验证工作，确保每一条评价都符合标准，无论是在内容的真实性还是在语言的礼貌性上。 5. 经验证的评价将被系统保存起来，成为后来买家的宝贵参考信息。 6. 同时，系统会自动更新卖家的评价统计，这是一个持续追踪卖家整体表现的重要机制。 7. 根据评价的内容和质量，系统可能会奖励买家一定的积分或提供优惠，这是对他们花费时间提供反馈的一种感谢，同时也鼓励更多买家参与到评价体系中来。 8. 最后，当一切流程顺利完成后，买家会收到一条"评价成功"的提示，这不仅是对他们行动的认可，也标志着整个评价过程的圆满结束。这个过程不仅体现了平台的互动性，也增强了买卖双方之间的信任与理解，共同营造了一个更加健康、透明的交易环境。 |
| 替代流程 | 4a. 系统验证评价内容失败（如包含不当词汇），系统提示错误并要求买家修改 |
| 结束 | 订单评价完成，买家得到的积分或优惠（如果有） |
| 实现约束和说明 | 评价必须在确认收货后进行，且在一定时间内完成 |
| 待解决问题 | 如需买家上传图片作为评价证据时的用例扩展 |

交易评价用例活动图如图3-12所示。

图3-12 交易评价用例活动图（xxx绘制）

支付结算用例描述如下：

表3-13支付结算用例描述（xxx编写）

|-----------|-----------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 名称 | 支付结算 |
| ID | MSM1110 |
| 主要业务参与者 | 用户 |
| 其他参与者 | 无 |
| 触发条件 | 用户点击支付选项 |
| 前置条件 | 用户进入购物车界面 |
| 后置条件 | 用户购物车清空，用户成功支付订单 |
| 基本流程 | 1用户点击支付选项 2系统根据用户购物车信息与商品库存判断商品库存是否满足 3系统根据用户购物车信息与用户个人信息生成支付订单 4用户支付，系统回显支付成功提示 5系统清空用户购物车 |
| 扩展流程 | 2a. 若商品库存不足，订单生成失败，并回显错误提示 2b. 若商品库存充足，订单生成成功，并回显订单信息 4a. 用户支付，回显支付成功提示 4b. 用户长时间未支付，回显操作超时提示 |
| 实现约束或特殊需求 | 若用户长时间无操作，提示操作超时并返回主页 |

支付结算用例活动图如图3-14所示。

图3-14 支付结算用例活动图

提交投诉详情用例描述如下：

表3-15提交投诉详情用例描述（xxx编写）

|----------|------------------------------------------------------------|
| 用例条目 | 内容 |
| 名称 | 提交投诉 |
| ID | MSM1108 |
| 主要业务参与者 | 用户 |
| 触发条件 | 用户点击投诉 |
| 前置条件 | 用户已经确认收货 |
| 后置条件 | 用户撤销申诉 |
| 基本流程 | 1用户点击申诉 2系统回显申诉信息表单 3用户填写表单 4系统回显操作提示 5系统回显操作成功提示用户等待平台介入 |
| 扩展流程 | 4a. 用户确认操作，系统回显操作成功提示 4b. 用户未确认操作 |

提交投诉用例活动图如图3-16所示。

图3-16 提交投诉详情用例活动图

3. 3 概念模型分析

二手交易系统概念模型如图3-5所示。

图3-5 二手交易系统概念模型

4 产品的非功能需求

4.1 质量需求

性能(Performance)：系统后台会合理分配服务器，来面对高峰期巨大数据井喷式增长的情况，并且将会发挥出我们的算法优势。

安全性(Security)：系统力争将会保护所有用户的隐私信息,并且我们系统后台数据库将会加大安全系数。

易用性(Usability):界面设计会符合大多用户的使用期望和使用习惯，操作逻辑与用户使用的大多系统的思维方式相似。并且页面美化相对简洁，可以让用户方便快速找到内容。

4.1.1 精度

本系统中输入的各种数据均要求精确到小数点后2位。

4.1.2 时间特性要求

响应时间：一般来说，响应时间应该在几秒内完成，以确保用户的体验。

更新处理时间：更新处理时间应该尽可能地短，以确保数据的及时性和准确性。

数据的转换和传送时间：在数据传输和转换过程中，需要确保数据的完整性和准确性，同时也需要尽可能地减少传输时间，以确保系统的效率和用户的体验。

4.1.3 灵活性

操作方式上的变化：

该软件应具备良好的用户界面设计，使得用户可以方便地进行各种操作。当需求发生变化时，该软件应该可以通过简单的界面调整或功能添加来满足新的操作方式需求。

运行环境的变化：

该软件应具备跨平台性，能够适应不同的操作系统和硬件环境。同时，在运行环境发生变化时，该软件应该具备自适应能力，可以在新的环境中正常运行，不影响用户的使用体验。

同其他软件的接口的变化：

该软件可能需要和其他软件进行数据交换或接口调用。当其他软件接口发生变化时，该软件应该可以灵活地适应新的接口，并保证数据传输的准确性和完整性。

精度和有效时限的变化：

对于精度和有效时限的变化，该软件应该能够根据需求变化做出相应的调整，并且在保证准确性的同时，能够满足时限的要求。

计划的变化或改进：

在软件开发过程中，难免会出现计划的变化或需要进行改进。该软件应该具备良好的可维护性和可扩展性，能够容易地进行修改和扩展，以适应计划的变化或改进。

4. 2 故障处理要求

软件故障：软件崩溃、死循环、数据损坏等，可能导致系统崩溃、无法正常使用，甚至可能导致数据丢失和安全问题。
硬件故障：硬盘故障、内存故障、CPU故障等，可能导致系统崩溃、无法正常使用，甚至可能导致数据丢失和安全问题。

4. 3 其他专门要求

安全保密要求：该系统需要满足用户单位的保密要求，比如数据加密、用户身份验证、访问控制等机制。同时，该系统还需要保证系统的可靠性和稳定性，以确保用户的信息安全。
使用方便要求：该系统需要提供易于使用的界面和操作方式，使用户可以方便地管理、查询、统计等操作。此外，该系统还需要具备良好的易用性和可操作性，以降低用户使用的难度。
可维护性、可补充性和易读性要求：该系统需要提供清晰、易读的代码和文档，并具备可维护性、可补充性和易读性，以方便后续的系统维护和更新。

5 运行环境规定

5.1 开发环境

客户端应用平台：windows操作系统；

服务器端应用平台：windows操作系统,Tomcat环境,idea,网络环境；

5.2 运行环境

操作系统：例如Windows、Linux等，根据具体需求选择合适的操作系统。
数据库管理系统：如MySQL、Oracle等，用于存储和管理系统的数据。
版本控制工具：如Git、SVN等，用于管理源代码的版本和变更记录。
单元测试工具：如JUnit、TestNG等，用于测试系统的各个单元模块是否正常运行。
集成测试工具：如Jenkins、Travis CI等，用于集成测试系统的各个模块，确保系统整体性能和稳定性。

实验三系统设计说明书

1 系统概况

1.1 项目背景

校园二手交易平台项目旨在满足高校师生对二手物品交易的需求，推动校园内的资源循环利用，减少浪费。随着学生人数的增长和消费观念的转变，校园内产生了大量闲置物品，而这些物品往往对于其他学生具有使用价值。因此，建立一个校园二手交易平台，能够方便学生之间的物品交易，同时也有助于培养学生的环保意识和节约精神。

在规模方面，校园二手交易平台主要覆盖高校校园内的学生、教职工等人群。目标客户定位为有闲置物品需要处理的学生、需要购买二手物品以节省开支的学生，以及希望方便进行物品交换的师生。

组织结构上，校园二手交易平台可以设立一个管理团队，负责平台的日常运营和维护。团队成员可以包括技术开发人员、市场推广人员、客服人员等，共同推动平台的发展。

1.2 当前应用现状

目前，虽然有些高校内部存在一些非正式的二手交易方式，如校园论坛、微信群等，但这些方式存在诸多问题。例如，信息发布零散、难以搜索；交易双方难以建立信任；缺乏规范的交易流程和售后保障等。这些问题限制了校园二手交易的规模和效率，也增加了交易风险。

因此，建立一个规范化、专业化、便捷化的校园二手交易平台具有迫切性和重要性。平台可以通过统一的信息发布渠道，方便用户搜索和浏览二手物品；通过实名认证、信用评价等方式，建立用户之间的信任机制；通过制定规范的交易流程和售后政策，保障用户的权益和交易安全。

1.3 系统建设的意义

校园二手交易平台的建设对于高校师生和校园环境都具有重要意义。

首先，对于学生而言，平台提供了一个便捷的交易渠道，使他们能够轻松处理闲置物品并获取所需物品，从而节省开支并促进资源的循环利用。此外，通过参与二手交易，学生还能够培养节约意识、环保意识和经济管理能力。

其次，对于校园环境而言，校园二手交易平台有助于减少浪费和污染。通过促进二手物品的再利用，平台能够降低废弃物的产生量，减轻对环境的压力。同时，这也符合高校作为教育机构的使命和责任，推动可持续发展和环保理念的普及。

最后，从经济效益的角度来看，校园二手交易平台能够为学校创造一定的经济收益。通过收取一定的服务费用或参与广告合作等方式，平台可以实现自我造血并持续发展。这些收益可以用于平台的维护和升级，进一步提升用户体验和服务质量。

综上所述，校园二手交易平台的建设不仅具有实际意义，还能够带来多方面的效益。

1.4 系统建设的初步构想

系统建设的目的

校园二手交易平台的建设旨在为学生和教职工提供一个安全、便捷、高效的二手物品交易环境。具体目标包括：促进校园内资源的循环利用，减少浪费，实现可持续发展；搭建一个诚信的交易平台，建立用户之间的信任机制，降低交易风险；提供便捷的信息发布和搜索功能，方便用户查找和发布二手物品信息；优化交易流程，确保交易的安全性和公平性，保障用户的权益。

系统的主要功能

a.上架商品：

用户通过平台提供的界面或接口，将希望出售的商品的详细信息，包括商品名称、描述、价格、图片、规格、成色等，上传至系统。系统将对上传的信息进行审核，确认信息的真实性和合法性后，将商品信息展示在平台的商品列表中，供其他用户浏览和搜索。同时，系统将对上架商品进行库存管理，确保商品信息的准确性和实时性。

b.下架商品：

用户可以通过系统提供的功能，将已经上架但不再出售或已售出的商品进行下架操作。下架的商品将不再展示在平台的商品列表中，其他用户将无法查看和搜索到该商品的信息。下架操作不会影响已生成的订单和交易记录，用户可以随时查看和管理自己的交易历史。

c.搜索商品：

用户可以在平台的搜索框中输入关键词或选择分类，查看所有用户上架的且有库存余额的商品。系统将根据用户输入的关键词或选择的分类，快速检索出符合条件的商品信息，并按照一定的排序方式展示给用户。用户可以通过筛选条件进一步缩小搜索范围，快速找到自己需要的商品。

d.发布公告：

管理员具备发布系统公告的权限。通过该功能，管理员可以向所有用户发布重要通知、系统更新信息、活动公告等。公告内容将展示在平台的首页或指定页面，以便用户随时查看。管理员可以编辑和修改公告内容，确保信息的准确性和及时性。

e.修改商品：

用户可以在商品管理页面中找到已上架的商品，并进行修改操作。用户可以修改商品的详细信息，如价格、描述、图片等。修改后的信息将经过系统审核后更新到平台，确保其他用户看到的信息是最新的。。

f.绑定银行卡：

为了保障用户的支付安全和便捷性，平台提供绑定银行卡的功能。用户在平台的个人中心或支付设置页面，可以输入自己的银行卡信息，包括卡号、开户行、姓名等，进行绑定操作。系统将对用户输入的银行卡信息进行验证和加密处理，确保信息的安全性和隐私性。绑定成功后，用户可以使用银行卡进行支付结算操作。

g.编辑个人信息：

已注册的用户可以通过平台的个人中心或账户设置页面，编辑和更新自己的个人资料信息。用户可以更改姓名、联系方式、密码等个人信息，以确保信息的准确性和及时性。编辑个人信息的过程需要进行身份验证和确认，以确保只有用户本人才能进行修改操作。

h.交易评价：

买家在确认收货后，可以通过平台提供的评价系统对商品和卖家服务进行评价。评价内容包括商品质量、卖家服务态度、物流速度等方面，可以选择不同的评价等级或撰写文字评价。评价信息将展示在商品详情页面和卖家信用页面中，供其他用户参考。交易评价系统有助于建立用户之间的信任机制，提高交易的透明度和可靠性。

i.支付结算：

平台提供多种支付方式，如在线支付、银行卡支付等，方便用户进行支付结算操作。用户在确认购买商品后，可以选择合适的支付方式完成支付。系统将对支付过程进行安全验证和记录，确保支付的准确性和安全性。支付成功后，平台将及时通知卖家进行发货操作，并跟踪物流信息直至买家确认收货。

j.投诉：

用户在交易过程中如遇到任何问题或纠纷，可以通过平台的投诉系统进行投诉。用户需要填写投诉内容、提供相关证据和联系方式，以便平台能够及时处理和解决。平台将对投诉内容进行核实和调查，积极协调双方解决问题。投诉处理结果将及时通知用户，并作为改进平台服务和提升用户体验的参考依据。

系统的拓扑结构

校园二手交易平台的拓扑结构可以采用三层架构，包括前端展示层、业务逻辑层和数据存储层。前端展示层负责与用户进行交互，展示平台界面和信息；业务逻辑层负责处理用户请求和业务逻辑的实现；数据存储层负责存储和管理用户信息、物品信息等数据。

系统的时间计划

此系统计划开始时间为2024年4月，完成时间为2024年7月。详细为：

业务分析：2024年4月29日-2024年5月6日

需求分析：2024年5月6日-2024年5月13日

系统分析：2024年5月13日-2024年6月6日

系统实现：2024年6月6日-2024年6月17日

系统测试：2024年6月24日-2024年6月25日

系统移交：2024年6月25日-2024年6月27日

2. 系统设计

2.1 系统环境与平台

2.1.1 物理设备

中央处理器：Intel Core i7-11800H处理器。

内存：配备了16GB的DDR4内存，内存频率为3200MHz，并且采用SO-DIMM插槽设计。

硬盘：硬盘容量为512GB，采用固态硬盘（SSD）作为存储介质。

联网设备：配备了无线网卡，支持无线连接功能。

2.1.2 软件平台

操作系统：Windows 10/11

数据库管理系统：MySql

中间件：SpringBoot框架集成的Tomcat作为Web服务器

编译器：IntelliJ IDEA 2023.3.6

2.2 系统结构

2.2.1 软件开发结构

为了描述二手交易平台的软件结构，我们可以使用类图和包图来展示各个组件和它们之间的关系。，其中用户与商品之间存在关联关系，因为用户可以上架、修改和下架商品。用户与订单之间存在关联关系，因为用户可以购买商品并处理订单。用户与评价之间存在关联关系，因为用户可以评价交易。用户与投诉之间存在关联关系，因为用户可以提交投诉。商品与订单之间存在关联关系，因为订单包含商品信息。订单与支付系统之间存在依赖关系，因为订单处理涉及支付结算。用户管理包与其他包均有交互，因为用户是所有功能的主体。商品管理包与订单管理包有交互，因为订单涉及商品信息。订单管理包依赖于外部的支付系统实现。

软件结构图（包图+类图）如图2-1所示。

图2-1软件结构图（包图+类图）

2.2.2 拓扑结构

该系统由三层架构组成，用户端和管理员端通过服务器连接数据库，进行二手商品交易和各种信息的管理。

整体部署图如图2-2所示：

图2-2部署图

2.3 接口设计

2.3.1 用户接口

（1）上架商品接口：

提供商品信息录入表单，包括标题、描述、价格、图片等字段。

支持用户选择商品分类和属性。

提供预览和确认上架功能。

（2）修改商品接口：

提供编辑已上架商品的界面，允许用户修改商品信息。

修改后应显示更新成功的提示，并允许用户预览修改后的商品。

（3）下架商品接口：

提供商品列表，允许用户选择想要下架的商品。

提供确认下架按钮，下架成功后显示相应提示。

（4）搜索商品接口：

设计搜索框，支持关键词搜索和筛选条件搜索。

显示搜索结果列表，包括商品图片、标题、价格等信息。

（5）购买商品接口：

提供商品详情页面，展示商品详细信息及购买选项。·

支持用户选择购买数量，进入结算页面。

（6）评价交易接口：

交易完成后，提示用户进行评价。

提供评价表单，包括文字评价和星级评分。

（7）提交投诉接口：

提供投诉入口，用户可填写投诉内容和相关证据。

支持用户选择投诉类型，如商品质量问题、卖家服务态度等。

（8）用户编辑资料接口：

提供个人资料编辑页面，允许用户修改个人信息，如姓名、联系方式、收货地址等。

提供头像上传和修改功能。

（9）订单通知接口：

通过系统消息或邮件方式，向用户发送订单状态变更通知，如订单创建、支付成功、发货通知等。

（10）支付结算接口：

整合第三方支付接口，支持多种支付方式。

显示支付金额和支付状态，提供支付成功后的订单详情查看功能。

（11）充值余额接口：

提供充值入口，支持用户通过第三方支付平台进行余额充值。

显示充值金额和充值状态，更新用户余额。

2.3.2 软件接口

（1）商品管理接口：

提供商品信息的增删改查功能，确保数据的准确性和一致性。

处理商品上架、修改和下架的后台逻辑。

（2）搜索引擎接口：

根据用户输入的关键词和筛选条件，提供商品搜索结果的接口。

优化搜索算法，提高搜索速度和准确性。

（3）订单处理接口：

接收用户提交的购买请求，创建订单并处理支付逻辑。

更新订单状态，通知用户和卖家。

（4）评价管理接口：

存储和管理用户评价信息，确保评价的真实性和可靠性。

提供评价数据的统计和分析功能。

（5）投诉处理接口：

接收用户提交的投诉信息，并进行审核和处理。

通知相关方进行协调或解决投诉问题。

（6）用户数据管理接口：

存储和管理用户个人资料信息，确保数据的安全性和隐私性。

提供用户数据的修改和查询功能。

（7）通知服务接口：

发送订单通知、支付通知等系统消息或邮件通知。

支持自定义通知模板和推送方式。

（8）支付接口：

与第三方支付平台对接，处理支付请求和支付结果回调。

确保支付过程的安全性和稳定性。

（9）余额管理接口：

处理用户余额的充值、扣款和查询操作。

确保余额数据的准确性和安全性。

2.3.3 其它接口

与其他软件交互接口：

由于本项目涉及支付和收款信息，本项目在应用过程中一定会有和其他支付软件之间的交互。因此在编写代码时也一定要为这类交互设立特定的方法，一定要在双方都同意允许的情况下才可写入对应的支付选项。卖家可以通过出售订单商品来获得一定报酬，而报酬的获取方式可以由卖家自行决定（例如银行卡、支付宝、微信等方式）。同理买家也可以在购买商品支付时选择自己想要的支付方式。

2.4 详细设计

2.4.1 上架商品用例的详细设计

上架商品用例的分析类

在二手交易平台的上架商品用例中，我们同样可以识别出接口类（边界类boundary）、控制类（control）和实体类（entity）。

A.接口类/边界类（Boundary Classes）:

这些是系统与用户或其他外部系统交互的接口。在上架商品这个用例中，可能的接口类有：

UserInputInterface: 负责接收用户输入的商品信息，如商品名称、描述、价格、图片等。

DisplayInterface:负责展示商品上架的结果或错误信息给用户。

B.控制类（Controller Classes）:

ProductListingController: 负责处理上架商品的逻辑。它接收来自 UserInputInterface的商品信息，调用 Model 层的相应方法来保存商品信息，并通过 DisplayInterface显示结果。

C.实体类（Entity Classes）:

实体类代表系统中的数据对象。在上架商品的用例中，我们可能需要的实体类有：

Product: 表示商品的信息，包括商品ID、名称、描述、价格、图片URL等属性，以及相关的getter和setter方法。

User: 表示用户的信息，如用户名、密码、邮箱等。在商品上架的过程中，可能需要验证用户的身份。

D.模型类（Model Classes）:

ProductRepository:负责商品信息的存储和检索。它提供了方法，如 addProduct(Product product) 用于添加新商品到数据库中，getProduct(ProductId id)用于检索特定商品的信息等。

UserRepository:负责用户信息的存储和验证。它可能提供了 authenticateUser(User user)用于验证用户登录等方法

上架商品用例的接口类、控制类、实体类如表3-1所示。

表3-1 上架商品用例的接口类、控制类、实体类（xxx编写）

|--------------------|--------------------------|---------|
| 接口类 | 控制类 | 实体类 |
| UserInputInterface | ProductListingController | Product |
| DisplayInterface | ProductRepository | User |
| | UserRepository | |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现上架商品的功能。

上架商品用例的类图如图3-1所示：

图3-1上架商品用例的类图（xxx绘制）

ProductListingController接收UserInputInterface 和 DisplayInterface的请求，并调用ProductService接口中的业务逻辑方法，同时 ProductRepository 和 UserRepository实现ProductService接口，ProductRepository 和 UserRepository又分别依赖于Product 与 User ，Product 与 User 之间可能存在关联关系，因为一个商品通常与一个用户相关联（例如，记录商品的创建者或所有者）。

确定用例的行为模型

上架商品用例的顺序图如图3-2所示。

图3-2上架商品用例的顺序图（xxx绘制）

在上架商品的流程中，用户首先通过 UserInputInterface输入商品信息。然后，ProductListingController接收这些信息，并验证用户身份（通过UserRepository）。如果验证通过，ProductListingController会创建一个Product对象，并通过ProductRepository将其保存到数据库中。最后，ProductListingController通过DisplayInterface 显示上架结果给用户。

2.4.2 下架商品用例的详细设计

下架商品用例的分析类

在下架商品的用例中，我们需要识别相应的接口类（boundary），控制类（control），和实体类（entity）。这些类将协同工作以完成下架商品的功能。

A.接口类/边界类（Boundary Classes）:

UserInputInterface: 提供用户输入下架商品信息的接口，如商品ID、下架原因等。

DisplayInterface: 显示商品下架操作的结果或错误信息给用户。

B.控制类（Controller Classes）:

ProductDelistingController: 负责处理下架商品的逻辑。它接收来自 UserInputInterface的下架请求，调用模型层的相应方法来执行下架操作，并通过 DisplayInterface显示结果。

C.实体类（Entity Classes）:

Product:代表商品信息，包括商品ID、名称、描述、价格等属性。

User:代表用户信息，包含用户名、密码等属性。

D.模型类（Model Classes）:

ProductRepository:负责商品信息的存储和检索。它提供方法，如 removeProduct(ProductId id)用于下架指定ID的商品。

UserRepository:负责用户信息的验证和管理。它用于验证当前操作的用户是否有权限下架商品。

下架商品用例的接口类、控制类、实体类如表3-2所示。

表3-2 下架商品用例的接口类、控制类、实体类（xxx编写）

|--------------------|----------------------------|---------|
| 接口类 | 控制类 | 实体类 |
| UserInputInterface | ProductDelistingController | Product |
| DisplayInterface | ProductRepository | User |
| | UserRepository | |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现下架商品的功能。

下架商品类图如图3-3所示：

图3-3下架商品类图（xxx绘制）

ProductDelistingController接收UserInputInterface 和 DisplayInterface的请求，并调用ProductService接口中的业务逻辑方法，同时 ProductRepository 和 UserRepository实现ProductService接口，ProductRepository 和 UserRepository又分别依赖于Product 与 User ，Product 与 User 之间可能存在关联关系，因为一个商品通常与一个用户相关联（例如，记录商品的创建者或所有者）。

确定用例的行为模型

下架商品用例的顺序图如图3-4所示。

图3-4下架商品用例的顺序图（xxx绘制）

在下架商品流程中，用户通过UserInputInterface输入下架商品的ID以及可能的下架原因。ProductDelistingController接收下架请求，并通过UserRepository验证用户身份和权限。如果用户验证通过，ProductDelistingController调用ProductRepository的removeProduct方法来下架商品。ProductRepository执行下架操作中的可能涉及更新数据库商品状态或移除相关记录。ProductDelistingController通过DisplayInterface显示下架操作的结果给用户，例如成功下架或下架失败的原因。

2.4.3 编辑个人信息用例的详细设计

编辑个人信息用例的分析类

A.接口类：

user profile page：用户的个人资料页面，显示用户当前的个人信息，并提供编辑个人信息的入口。

edit profile form：编辑个人资料表单，允许用户填写或修改他们的个人信息，如姓名、联系方式、密码等。

B.控制类：

profile controller：个人资料控制器，负责接收用户的编辑请求，验证输入数据的合法性，并调用相应的模型方法来更新用户信息。

C.实体类：

user model：用户模型，包含用户id、姓名、联系方式、密码等属性，以及更新用户信息的方法。

validation service：验证服务，用于验证用户提交的信息是否符合要求，如检查密码强度、联系方式格式等。

上架商品用例的接口类、控制类、实体类如表3-1所示。

表3-3 编辑个人信息用例的接口类、控制类、实体类（xxx编写）

|-------------------|--------------------|--------------------|
| 接口类 | 控制类 | 实体类 |
| user profile page | profile controller | user model |
| edit profile form | | validation service |

编辑个人信息用例的类图如图3-5所示：

图3-5上架商品用例的类图（xxx绘制）

user profile page和edit profile form依赖于profile controller这个控制器类处理来自视图的请求，负责接收用户的编辑请求，验证数据的合法性，并调用相应的模型方法来更新信息。

validation service依赖于user model用于验证用户资料是否符合要求

确定用例的行为模型

编辑个人信息用例的顺序图如图3-6所示。

图3-6编辑个人信息用例的顺序图（xxx绘制）

用户登录后导航到个人资料页面（user profile page），该页面展示了用户的当前个人信息。用户点击"编辑"按钮，系统呈现编辑个人资料表单（edit profile form）。用户在表单中输入新的信息，如更改姓名、联系方式或密码。用户提交表单数据，请求发送到个人资料控制器（profile controller）。控制器接收用户输入的数据，并调用验证服务（validation service）来检查数据的有效性，如确认密码强度足够，联系方式格式正确无误。数据验证成功后，控制器指示用户模型（user model）更新数据库中的用户信息。控制器制器向用户反馈操作成功的信息。

2.4.4 管理员发布系统公告用例的详细设计

管理员发布系统公告用例的分析类

A.接口类：

New Announcement Page：新公告页面，用于展示创建或编辑公告的表单。

Announcement List Page：公告列表页面，展示所有系统公告的列表，支持搜索和过滤功能。

Announcement Details Page：公告详情页面，显示单个公告的详细信息，以及编辑和删除选项。

B.控制类：

AnnouncementController：公告控制器，提供系统公告管理的主界面，允许管理员进行各种公告操作

C.实体类：

Announcement：公告，包含公告的属性，如标题、内容、发布日期、有效期等。

Admin：管理员，包含管理员的相关属性，如ID、姓名、权限等级等。

AnnouncementRepository：公告业务逻辑层，定义了公告的存储和检索方法，如获取所有公告、获取单个公告详情、创建新公告等。

管理员发布系统公告的接口类、控制类、实体类如表3-4所示。

表3-4管理员发布系统公告的接口类、控制类、实体类（xxx编写）

|---------------------------|------------------------|-----------------------|
| 接口类 | 控制类 | 实体类 |
| Announcement Details Page | AnnouncementController | Announcement |
| New Announcement Page | | Admin |
| Announcement List Page | | AnnouncementRepositor |

管理员发布系统公告类图如图3-7所示：

图3-7管理员发布系统公告类图（xxx绘制）

AnnouncementController：控制器类作为模型和视图之间的中介，处理所有公告相关的操作请求。Announcement：此实体类包含了公告的所有属性，如标题、内容等。Admin：代表系统管理员，包含其基本信息如ID和姓名。AnnouncementRepository：处理公告数据的存储和检索。AnnouncementDetails Page，New Announcement Page，Announcement List Page依赖于AnnouncementController，用于负责处理管理员的请求，如创建新公告、更新或删除现有公告。此控制器接收来自视图的数据，调用模型进行处理，并返回响应到视图。Admin，Announcement依赖于AnnouncementReposito定义公告的存储和检索方法，如获取所有公告、获取单个公告详情、创建新公告等。

确定用例的行为模型

管理员发布系统公告的顺序图如图3-8所示。

图3-8管理员发布系统公告类图（xxx绘制）

管理员点击发布公告页面进入新公告页面（New Announcement Page），编辑公告信息后，由公告业务逻辑层（AnnouncementRepository）检验公告是否合规，随后对公告（Announcement）更新相关公告信息，管理员在新公告页面（New Announcement Page）点击发布按钮后，由公告业务逻辑层（AnnouncementRepository）验证管理员（Admin）权限信息，成功发布后跳转公告列表页面（Announcement List Page），最后提示管理员发布成功公告。

2.4.5 提交投诉用例的详细设计

提交投诉用例的分析类

A.接口类/边界类（Boundary Classes）:

SubmitComplaintForm提交投诉界面: 它提供用户填写投诉信息的界面。

B.控制类（Controller Classes）:

ComplaintHandler投诉处理: 它负责接收来自SubmitComplaintForm的投诉信息，验证数据的合法性，并将其传递给相应的实体类进行存储。

C.实体类（Entity Classes）:

Complaint: 表示投诉的信息，包括包含投诉ID、投诉状态、投诉内容、优先级等属性。

User: 表示用户的信息，包含用户ID、姓名、联系方式等属性。

D.模型类（Model Classes）:

ComplaintType: 投诉系统需要支持多种类型的投诉，ComplaintType模型类来表示不同类型的投诉，每个类型包含了特定的属性和方法。

提交投诉用例的接口类、控制类、实体类如表3-1所示。

表3-5 提交投诉用例的接口类、控制类、实体类（xxx编写）

|---------------------|------------------|-----------|
| 接口类 | 控制类 | 实体类 |
| SubmitComplaintForm | ComplaintHandler | Complaint |
| | ComplaintType | User |

提交投诉用例的类图如图3-9所示：

图3-9提交投诉用例的类图（xxx绘制）

ComplaintHandler接收SubmitComplaintForm的请求，并调用ComplaintType中的业务逻辑方法，Complaint与 User 之间可能存在关联关系，因为一个投诉通常与一个用户相关联。

确定用例的行为模型

提交投诉用例的顺序图如图3-10所示。

图3-10提交投诉用例的顺序图

在提交投诉的流程中，用户首先通过 SubmitComplaintForm 输入投诉信息。然后，ComplaintHandler接收这些信息，ComplaintHandler会创建一个Complaint对象将其保存到数据库中。最后，ComplaintHandler通过 SubmitComplaintForm显示投诉结果给用户。

2.4.6 支付结算用例的详细设计

支付结算用例的分析类

在支付结算的用例中，我们需要识别相应的接口类（boundary），控制类（control），和实体类（entity）。这些类将协同工作以完成支付结算的功能。

A.接口类/边界类（Boundary Classes）:

PaymentInterface:它提供用户填写支付信息的界面。

B.控制类（Controller Classes）:

PaymentProcessor: 它负责接收来自PaymentInterface的数据，验证数据的合法性，并将其传递给相应的实体类进行存储。

C.实体类（Entity Classes）:

Payment:代表支付信息，包括支付金额、支付方式、支付状态等属性。

User:表示用户的信息，包含用户ID、姓名、联系方式等属性。

D.模型类（Model Classes）:

PaymentMethod:支付系统需要支持多种类型的支付方式，模型类来表示不同的支付方式，每种方式包含了特定的属性和方法。

支付结算用例的接口类、控制类、实体类如表3-2所示。

表3-6 支付结算用例的接口类、控制类、实体类（xxx编写）

|------------------|------------------|---------|
| 接口类 | 控制类 | 实体类 |
| PaymentInterface | PaymentProcessor | Payment |
| | PaymentMethod | User |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现支付结算的功能。

支付结算类图如图3-11所示：

图3-11支付结算类图（xxx绘制）

PaymentProcessor接收PaymentInterface的请求，并调用PaymentService接口中的业务逻辑方法，同时 User和 Payment实现PaymentService接口，Payment 与 User 之间可能存在关联关系。

确定用例的行为模型

支付结算用例的顺序图如图3-12所示。

图3-12支付结算用例的顺序图（xxx绘制）

在支付结算的流程中，用户首先通过 PaymentInterface输入支付信息。然后，PaymentProcessor接收这些信息，PaymentProcessor 会创建一个payment对象，将其保存到数据库中。最后，PaymentProcessor 通过 PaymentInterface显示上架结果给用户。

2.4.7 修改商品用例的详细设计

修改商品用例的分析类

在二手交易平台的修改商品用例中，我们可以识别出接口类（边界类boundary）、控制类（control）和实体类（entity）。这些类协同工作以完成修改商品的功能。

A. 接口类/边界类（Boundary Classes）：

W01-ProductList: 商品列表页，展示卖家已上架的商品列表，提供修改商品的入口。

W02-EditProductForm: 商品编辑表单，允许卖家输入或修改商品的信息，如标题、描述、价格等。

W03-ProductPreview: 商品预览页，显示卖家在编辑表单中修改后的商品信息，供卖家确认。

W04-ProductUpdatedConfirmation: 商品修改成功确认页，显示商品已成功修改的消息。

B. 控制类（Controller Classes）：

Edit Product Handler: 商品编辑处理类，负责接收来自商品列表页的修改请求，调用相应的实体类进行商品信息的更新，并处理相关的业务逻辑。

C. 实体类（Entity Classes）：

Product: 商品类，包含商品的唯一标识符（ID）、名称、描述、价格、图片URL等属性，以及修改商品信息的方法。

Seller: 卖家类，包含卖家的唯一标识符（ID）、姓名、联系方式等属性，虽然在此修改商品用例中不直接参与，但可能在某些业务逻辑中需要验证卖家的身份和权限。

ProductImage: 商品图片类（可选），如果平台支持存储图片的详细信息，这个类可以包含图片的URL、大小、格式等属性。

ProductDescription: 商品描述类（可选），如果平台将商品描述作为独立的实体来处理，这个类可以包含描述的文本内容、格式等属性。但在简单的实现中，商品描述通常作为Product类的一个属性存在。

修改商品用例的接口类、控制类、实体类如表3-1所示。

表3-7 修改商品用例的接口类、控制类、实体类（xxx编写）

|-------------------------------|-------------------|---------------------|
| 接口类 | 控制类 | 实体类 |
| W01-Seller Home Page | List Item Handler | Product |
| W02-Sell Product Form | | Seller |
| W03-Product Preview | | Product Image |
| W04-ProductListedConfirmation | | Product Description |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过关联、依赖等关系相互连接，共同实现修改商品的功能。

W01-Seller Home Page：卖家主页与ListItemHandler类有依赖关系，调用其方法触发修改流程。W02-Sell Product Form：商品编辑表单，与ListItemHandler类有依赖关系，传递卖家输入的商品信息。W03-Product Preview：商品预览页，与ListItemHandler类有依赖关系，接收并展示商品预览信息。W04-Product Listed Confirmation：商品修改成功确认页，与ListItemHandler类有依赖关系，接收修改成功的通知并展示给卖家。Product：商品类，与ListItemHandler类有依赖关系，通过ListItemHandler进行创建和更新。与ProductImage类有聚合关系，包含商品图片的信息。与ProductDescription类有聚合关系，包含商品的详细描述信息。Seller：卖家类，包含卖家的各种信息，如ID、姓名、联系方式等。与ListItemHandler类有依赖关系，记录商品上架的卖家信息。ProductImage：商品图片类，与Product类有聚合关系，作为商品的一个属性存在。 ProductDescription：商品描述类，与Product类有聚合关系，作为商品的一个属性存在。

修改商品用例的类图如图3-13所示：

图3-13修改商品用例的类图（xxx绘制）

确定用例的行为模型

卖家在 W01-Seller Home Page 上查看已上架的商品列表。卖家点击某个商品旁边的"修改"按钮。W01-Seller Home Page调用ProductManager的retrieveProductForEdit方法，传入商品ID作为参数。ProductManager根据商品ID从数据库或持久化存储中检索相应的Product实例，并将其传递给W02-Edit Product Form。W02-Edit Product Form 显示当前商品的详细信息，包括名称、描述、价格、图片等，以供卖家修改。卖家在 W02-Edit Product Form 中修改商品信息，可以修改名称、描述、价格，或重新上传商品图片。卖家点击"保存修改"按钮。W02-Edit Product Form 验证卖家输入的信息是否合法（例如，价格是否为正数，描述是否为空等），如果验证通过，则将修改后的商品信息传递给ProductManager。ProductManager调用updateProduct方法，将修改后的商品信息保存到数据库或持久化存储中。ProductManager调用notifyProductPreview方法，通知W03-Product Preview显示修改后的商品预览。卖家在W03-Product Preview中确认修改后的商品信息无误。如果卖家确认无误，ProductManager调用completeEdit方法，完成修改商品的过程。ProductManager通过 W04-Product Edited Confirmation 显示修改成功的信息给卖家。

修改商品用例的顺序图如图3-14所示。

图3-14修改商品用例的顺序图（xxx绘制）

2.4.8 搜索商品用例的详细设计

搜索商品用例的分析类

A.接口类：

W01-SearchEntryPage：搜索入口页，提供搜索框供用户输入搜索关键词，并触发搜索请求。

W02-SearchResultPage：搜索结果页，展示根据用户搜索关键词匹配到的商品列表，并提供排序、筛选等交互功能。

W03-ProductDetailPage：商品详情页，当用户从搜索结果页点击某个商品时，展示该商品的详细信息。

B.控制类：

SearchHandler：搜索处理类，负责接收来自W01-SearchEntryPage的搜索请求，调用搜索服务进行商品搜索，并将搜索结果传递给W02-SearchResultPage进行展示。

SearchService：搜索服务类，封装了具体的搜索逻辑，如关键词匹配、排序、筛选等，并返回符合条件的商品列表。

C.实体类：

Product：商品类，包含商品ID、名称、描述、价格、图片URL、卖家ID等属性，以及商品的状态（如上架、下架、已售等）。

SearchResult：搜索结果类，包含搜索到的商品列表（List<Product>）以及可能的分页信息。

SearchCriteria：搜索条件类，封装了用户输入的搜索关键词、排序方式、筛选条件等信息，供SearchService使用。

搜索商品用例的接口类、控制类、实体类如表3-2所示。

表3-8 搜索商品用例的接口类、控制类、实体类（xxx编写）

|-----------------------------|-------------------|----------------|
| 接口类 | 控制类 | 实体类 |
| W01-Seller Home Page | RemoveItemHandler | Product |
| W02-Product List Display | | Seller |
| W03-Confirm Product Removal | | Product Status |
| W04-RemoveProductForm | | |

搜索商品类图如图3-15所示：

图3-15搜索商品用例的类图（xxx绘制）

SearchPage搜索页面依赖于SearchController类，处理用户提交的搜索请求。SearchController搜索控制器依赖于SearchService类，获取搜索结果。SearchService搜索服务依赖于数据存储层（未在类图中直接表示，但隐含依赖），根据搜索条件检索商品数据。ProductList聚合Product，ProductList 是一个商品对象的集合，包含多个Product实例。

确定用例的行为模型

修改商品用例的顺序图如图3-16所示。

图3-16搜索商品用例的顺序图

用户进入搜索页面。用户输入搜索关键词或选择搜索条件（如商品类别、价格范围等）。用户点击搜索按钮提交搜索请求。系统接收用户搜索请求。系统调用SearchService的searchProducts方法，根据用户输入的关键词或条件在数据库中检索相关商品信息。系统对检索到的商品列表进行排序和筛选。系统在搜索结果页面显示商品列表，包括商品名称、图片、价格、描述等。用户可以浏览搜索结果，对感兴趣的商品进行进一步操作（如查看详情、购买等）。

2.4.9 交易评价用例的详细设计

交易评价用例的分析类

A. 接口类/边界类（Boundary Classes）：

FeedbackInterface: 负责接收用户输入的评价信息，如评价内容、评分等。

DisplayInterface: 负责展示评价提交的结果或错误信息给用户。

B. 控制类（Controller Classes）：

EvaluateTransactionController: 负责处理交易评价的逻辑。它接收来自 FeedbackInterface 的评价信息，调用模型层的相应方法来保存评价信息，并通过 DisplayInterface 显示结果。

C. 实体类（Entity Classes）：

Transaction: 表示交易的信息，包括交易ID、买卖双方的用户信息等属性，以及相关的 getter 和 setter 方法。

User: 表示用户的信息，如用户名、密码、邮箱等。在交易评价的过程中，需要验证用户的身份。

D. 模型类（Model Classes）：

FeedbackRepository: 负责评价信息的存储和检索。它提供了方法，如 addFeedback(Feedback feedback) 用于添加新评价到数据库中，getFeedback(TransactionId id) 用于检索特定交易的评价信息等。

TransactionRepository: 负责交易信息的存储和验证。它可能提供了 authenticateTransaction(Transaction transaction) 用于验证交易的有效性等方法。

评价交易商品用例的接口类、控制类、实体类如表3-1所示。

表3-9 评价交易用例的接口类、控制类、实体类（xxx编写）

|-------------------|-------------------------------|-------------|
| 接口类 | 控制类 | 实体类 |
| FeedbackInterface | EvaluateTransactionController | Transaction |
| DisplayInterface | FeedbackRepository | User |
| | TransactionRepository | |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现交易评价的功能。

EvaluateTransactionController接收FeedbackInterface 和 DisplayInterface的请求，并调用EvaluateTransactionService接口中的业务逻辑方法，同时 FeedbackRepository 和TransactionRepository实现EvaluateTransactionService接口，FeedbackRepository 和 TransactionRepository又分别依赖于Transaction 与 User，Transaction与User之间可能存在关联关系，因为多个评价通常与一个用户相关联。

交易评价用例的类图如图3-18所示：

图3-17交易评价类图（xxx绘制）

确定用例的行为模型

评价交易用例的顺序图如图3-19所示。

图3-18评价交易用例的顺序图（xxx绘制）

2.4.10 绑定银行卡用例的详细设计

绑定银行卡用例的分析类

A. 接口类/边界类（Boundary Classes）：

BankInterface：负责接收用户的银行卡信息，如卡号、持卡人姓名、有效期等。

DisplayInterface：负责向用户展示银行卡绑定的结果或错误信息。

B. 控制类（Controller Classes）：

BindBankCardController：负责处理银行卡绑定的逻辑。它接收来自 BankInterface 的银行卡信息，调用模型层的相应方法来验证和保存银行卡信息，并通过 DisplayInterface 显示结果。

C. 实体类（Entity Classes）：

BankCard：表示银行卡的信息，包括卡号、持卡人姓名、银行名称、有效期等属性，以及相关的 getter 和 setter 方法。

User：表示用户的信息，如用户名、密码、邮箱等。在绑定银行卡的过程中，需要验证用户的身份。

D. 模型类（Model Classes）：

BankCardRepository：负责银行卡信息的存储和检索。它提供了方法，如 addBankCard(BankCard bankCard) 用于添加新银行卡到数据库中，getBankCard(UserId id) 用于检索特定用户绑定的银行卡信息等。

UserRepository：负责用户信息的存储和验证。它可能提供了 authenticateUser(User user) 用于验证用户的有效性等方法。

表3-10绑定银行卡用例的接口类、控制类、实体类（xxx编写）

|------------------|------------------------|----------|
| 接口类 | 控制类 | 实体类 |
| BankInterface | BindBankCardController | BankCard |
| DisplayInterface | BankCardRepository | User |
| | UserRepository | |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现绑定银行卡的功能。

BindBankCardController接收BankInterface 和 DisplayInterface的请求，并调用BindBankCardService接口中的业务逻辑方法，同时BankCardRepository 和UserRepository实现BindBankCardService接口，BankCardRepository 和 UserRepository又分别依赖于 BankCard与 User ， BankCard与 User 之间可能存在关联关系，因为多个银行卡通常与一个用户相关联。

绑定银行卡用例的类图如图3-19所示：

图3-19绑定银行卡类图（xxx绘制）

确定用例的行为模型

绑定银行卡用例的顺序图如图3-20所示。

图3-20绑定银行卡用例的顺序图（xxx绘制）

2.5 用户界面设计

2.5.1 用户界面结构图

用户界面设计是确保用户能够直观地与平台进行交互，提供友好的操作体验。以下是根据提供的功能进行用户界面设计的分析。

主界面显示平台logo、导航栏（包括首页、商品列表、购物车、我的等）、推荐商品等。商品列表界面显示商品分类、筛选条件、商品列表（包括商品图片、标题、价格等）。商品详情界面显示商品详细信息（图片、描述、价格、卖家信息等）。提供购买按钮、加入购物车按钮、查看卖家其他商品等功能。购物车界面显示购物车中商品列表，包括商品信息、数量、总价等。提供修改商品数量、删除商品、结算等功能。我的界面包括我的订单、我的资料、我的评价、客服中心等子界面入口。我的订单界面显示订单列表，包括订单状态、商品信息、支付情况等。提供查看订单详情、确认收货、申请退款等功能。我的资料界面显示用户个人信息，包括姓名、联系方式、收货地址等。提供编辑资料、修改密码等功能。我的评价界面显示用户已评价的商品列表和评价内容。客服中心界面提供联系客服、提交投诉、查看帮助中心等功能。

用户界面结构图如图5-1所示。

图5-1用户界面结构图

2.5.2 主要用户界面详细设计

（1）商品列表界面

顶部设置搜索栏，便于用户输入关键词搜索商品。

左侧或顶部提供商品分类导航，便于用户按分类浏览商品。

商品列表采用网格或列表形式展示，每个商品展示缩略图、标题、价格等关键信息。

（2）商品详情界面

商品详情页面布局清晰，图片展示区域突出，确保用户能够清楚看到商品细节。

商品描述部分详细且易于阅读，包含商品属性、尺寸、材质等关键信息。

购买按钮明显，提供多种购买选项（如立即购买、加入购物车等）。

（3）购物车界面

购物车界面简洁明了，展示购物车中商品清单，包括商品图片、名称、价格及数量。

提供修改数量、删除商品等便捷操作，方便用户调整订单内容。

结算按钮明显，点击后跳转至结算页面，展示订单总金额及支付选项。

（4）我的订单界面

订单列表按照时间顺序或状态进行排序，方便用户查看和管理订单。

每个订单展示关键信息，如订单号、商品名称、支付状态、物流信息等。

提供查看订单详情、操作订单（如确认收货、申请退款等）的按钮或链接。

（5）我的资料界面

个人资料页面展示用户基本信息，如姓名、头像、联系方式等。

提供编辑功能，允许用户修改个人信息，如修改密码、更新收货地址等。

编辑功能布局合理，表单验证完善，确保用户输入信息的准确性和有效性。

2.6 数据库设计

2.6.1 逻辑结构设计

根据二手交易平台的基本功能，我设计了以下9个表，分别是公告表 (t_announcement)，轮播图表 (t_carousel)，留言表 (t_contact)，联系方式表 (t_contact_information)，商品表 (t_goods)，商品类型表 (t_goods_type)，预订消息表 (t_message)，预订记录表 (t_reserve_record)，用户表（t_user）

t_announcement

t_announcement 如图6-1所示。

图6-1 t_announcement

t_carousel

t_carousel如图6-2所示。

图6-2 t_carouse

t_contact_information

t_contact_information如图6-3所示。

图6-3 t_contact_information

t_contact

t_contact如图6-4所示。

图6-4 t_contact

t_goods_type

t_goods_type如图6-5所示。

图6-5 t_goods_type

t_goods

t_goods如图6-6所示。

图6-6 t_goods

t_message

t_message如图6-7所示。

图6-7 t_message

t_reserve_record

t_reserve_record如图6-8所示。

图6-8 t_reserve_record

t_user

t_user如图6-9所示。

图6-9 t_user

2.6.2 物理结构设计

以下是部分表的 `CREATE TABLE` 和 `INSERT` 语句示例：

CREATE DATABASE `db_secondhandtrade`;

USE `db_secondhandtrade`;

DROP TABLE IF EXISTS `t_announcement`;

CREATE TABLE `t_announcement` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`title` varchar(100) DEFAULT NULL COMMENT '标题',

`content` text COMMENT '内容',

`time` datetime DEFAULT NULL COMMENT '发布时间',

`click` int(11) DEFAULT NULL COMMENT '点击数',

`sortNum` int(11) DEFAULT NULL COMMENT '排序',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

insert into `t_announcement`(`id`,`title`,`content`,`time`,`click`,`sortNum`) values (3,'公告1','公告1\r\n\r\n<img alt=\"\" src=\"/static/images/articleImage/202201151617541642234674993.jpg\" style=\"height:500px; width:888px\" />\r\n','2022-01-15 14:35:09',80,1),(4,'公告2','公告2\r\n\r\n<img alt=\"\" src=\"/static/images/articleImage/202201151617021642234622557.jpg\" style=\"height:500px; width:888px\" />\r\n','2022-01-15 14:35:22',23,2),(5,'公告3','公告3\r\n\r\n<img alt=\"\" src=\"/static/images/articleImage/202201151618291642234709015.jpg\" style=\"height:500px; width:888px\" />\r\n','2022-01-15 16:18:33',34,3);

DROP TABLE IF EXISTS `t_carousel`;

CREATE TABLE `t_carousel` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`imageName` varchar(100) DEFAULT NULL COMMENT '图片名称',

`title` varchar(100) DEFAULT NULL COMMENT '标题',

`content` varchar(200) DEFAULT NULL COMMENT '描述',

`sortNum` int(11) DEFAULT NULL COMMENT '排列顺序',

`url` varchar(100) DEFAULT NULL COMMENT '链接',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8;

insert into `t_carousel`(`id`,`imageName`,`title`,`content`,`sortNum`,`url`) values (21,'202201150019141642177154078.jpg','公告1','公告1公告1公告1',1,'/announcement/3'),(22,'202201160201071642269667826.jpg','百草味果干大礼包','百草味果干大礼包零食年货芒果干送女生礼盒蜜饯果脯小吃食品休闲',2,'/goods/22'),(23,'202201150019441642177184535.jpg','求购一个机械键盘','求购一个机械键盘.200元以内',3,'/goods/31');

DROP TABLE IF EXISTS `t_contact`;

CREATE TABLE `t_contact` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`content` varchar(1000) DEFAULT NULL COMMENT '留言内容',

`reply` varchar(1000) DEFAULT NULL COMMENT '答复',

`time` datetime DEFAULT NULL COMMENT '留言时间',

`userId` int(11) DEFAULT NULL COMMENT '留言用户id（普通用户）',

`userIdReply` int(11) DEFAULT NULL COMMENT '回复用户id（管理员）',

PRIMARY KEY (`id`),

KEY `t_contact_ibfk_1` (`userId`),

CONSTRAINT `t_contact_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8;

insert into `t_contact`(`id`,`content`,`reply`,`time`,`userId`,`userIdReply`) values (8,'内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容内容','1111111111111','2022-01-12 14:39:53',56,1),(18,'1','1231231321','2022-01-12 16:12:30',56,1),(19,'2','00000','2022-01-12 16:12:34',56,1),(21,'3','3131321323121','2022-01-12 18:00:57',2,1),(22,'444',NULL,'2022-03-24 13:34:36',2,NULL);

DROP TABLE IF EXISTS `t_contact_information`;

CREATE TABLE `t_contact_information` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`name` varchar(100) DEFAULT NULL COMMENT '名称',

`content` varchar(100) DEFAULT NULL COMMENT '内容',

`userId` int(11) DEFAULT NULL COMMENT '用户id',

PRIMARY KEY (`id`),

KEY `t_contact_information_ibfk_1` (`userId`),

CONSTRAINT `t_contact_information_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8;

insert into `t_contact_information`(`id`,`name`,`content`,`userId`) values (1,'QQ','1203007466',56),(2,'微信','ledao303',56),(5,'手机','13667832012',56),(21,'微信','123434243',3),(22,'微信','2a231',2);

DROP TABLE IF EXISTS `t_goods`;

CREATE TABLE `t_goods` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`name` varchar(100) DEFAULT NULL COMMENT '商品名称',

`content` text COMMENT '商品详情',

`priceNow` decimal(10,0) DEFAULT NULL COMMENT '现在价格',

`priceLast` decimal(10,0) DEFAULT NULL COMMENT '上次价格',

`state` int(11) DEFAULT NULL COMMENT '商品状态,0为未审核,1为上架中,2为审核不通过,3为已下架,4为被预定,5为交易成功',

`reason` varchar(500) DEFAULT NULL COMMENT '审核不通过的理由',

`goodsTypeId` int(11) DEFAULT NULL COMMENT '商品类别id',

`userId` int(11) DEFAULT NULL COMMENT '发布者id',

`addTime` datetime DEFAULT NULL COMMENT '添加时间',

`isRecommend` int(11) DEFAULT NULL COMMENT '是否推荐,0为不推荐(默认),1为推荐',

`recommendTime` datetime DEFAULT NULL COMMENT '推荐时间',

`recommendDays` int(11) DEFAULT NULL COMMENT '推荐天数',

`click` int(11) DEFAULT NULL COMMENT '点击数',

PRIMARY KEY (`id`),

KEY `t_goods_ibfk_1` (`userId`),

KEY `t_goods_ibfk_2` (`goodsTypeId`),

CONSTRAINT `t_goods_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE,

CONSTRAINT `t_goods_ibfk_2` FOREIGN KEY (`goodsTypeId`) REFERENCES `t_goods_type` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=41 DEFAULT CHARSET=utf8;

insert into `t_goods`(`id`,`name`,`content`,`priceNow`,`priceLast`,`state`,`reason`,`goodsTypeId`,`userId`,`addTime`,`isRecommend`,`recommendTime`,`recommendDays`,`click`) values (21,'北美电器（ACA）电风扇一体式折叠风扇台式两用伸缩式落地扇','<img alt=\"\" src=\"/static/images/articleImage/202201160115131642266913331.jpg\" style=\"height:375px; width:666px\" />\r\n','333','0',1,NULL,5,56,'2022-01-16 01:15:23',0,NULL,NULL,3),(22,'百草味果干大礼包零食年货芒果干送女生礼盒蜜饯果脯小吃食品休闲','<img alt=\"\" src=\"/static/images/articleImage/202201160117501642267070232.jpg\" style=\"height:375px; width:666px\" />\r\n','99','0',0,NULL,4,56,'2022-01-16 01:17:57',0,NULL,NULL,28),(23,'旺旺旺仔小馒头30袋原味牛奶味儿童饼干怀旧零食品小吃整箱批发','<img alt=\"\" src=\"/static/images/articleImage/202201160119351642267175196.jpg\" style=\"height:375px; width:666px\" />\r\n','15','0',0,NULL,4,56,'2022-01-16 01:19:40',1,NULL,NULL,55),(24,'加绒加厚保暖上衣v领黑色打底衫女秋冬内搭长袖t恤时尚鸡心领百搭','<img alt=\"\" src=\"/static/images/articleImage/202201160121371642267297550.jpg\" style=\"height:375px; width:666px\" />\r\n','30','33',1,NULL,2,56,'2022-01-16 01:21:42',1,NULL,NULL,60),(25,'唐狮2022年新款白色长袖打底衫女蕾丝高领内搭设计感时尚洋气上衣','<img alt=\"\" src=\"/static/images/articleImage/202201160122491642267369440.jpg\" style=\"height:375px; width:666px\" />\r\n','60','0',1,NULL,2,56,'2022-01-16 01:22:54',0,NULL,NULL,18),(26,'优衣库秋冬男装摇粒绒半拉链套头衫(长袖保暖抓绒) 441257','<img alt=\"\" src=\"/static/images/articleImage/202201160124071642267447440.jpg\" style=\"height:375px; width:666px\" />\r\n','70','0',1,NULL,2,56,'2022-01-16 01:24:12',1,NULL,NULL,82),(27,'畅享20Plus 8+128G 6.63英寸4800W华为5g手机','<img alt=\"\" src=\"/static/images/articleImage/202201160125321642267532402.jpg\" style=\"height:375px; width:666px\" />\r\n','999','0',4,NULL,1,56,'2022-01-16 01:25:46',1,NULL,NULL,227),(28,'三星A52千元学生5G智能数码手机Samsung Galaxy','<img alt=\"\" src=\"/static/images/articleImage/202201160126481642267608246.jpg\" style=\"height:375px; width:666px\" />\r\n','1888','0',5,NULL,1,56,'2022-01-16 01:26:59',0,'2022-01-19 15:20:55',1,102),(29,'超薄办公一体机电脑高端四核i3i5i7家用网吧吃鸡游戏型独显台式主机19-27英寸非触摸屏高配整机','<img alt=\"\" src=\"/static/images/articleImage/202201160128131642267693062.jpg\" style=\"height:375px; width:666px\" />\r\n','1222','0',1,NULL,1,56,'2022-01-16 01:28:17',0,NULL,NULL,22),(30,'22寸壁挂嵌入式工业工控平板电脑一体机电容电阻触摸屏显示器安卓触控查询plc全封闭','<img alt=\"\" src=\"/static/images/articleImage/202201160130111642267811613.jpg\" style=\"height:375px; width:666px\" />\r\n','999','0',1,NULL,1,56,'2022-01-16 01:30:16',0,'2022-01-19 23:43:53',2,25),(31,'求购一个机械键盘','200元以内\r\n','88','0',3,NULL,8,56,'2022-01-16 02:05:02',0,'2022-01-18 16:25:40',10,55),(32,'22222','222222222\r\n','200','0',3,'哈哈',8,56,'2022-01-16 02:21:17',0,NULL,NULL,21),(33,'2','2\r\n','20','0',2,'99999',2,56,'2022-01-16 21:39:20',0,'2022-01-18 16:24:02',10,28),(40,'1','1\r\n','1','0',0,'1111111',3,56,'2022-04-17 22:09:12',0,NULL,NULL,3);

DROP TABLE IF EXISTS `t_goods_type`;

CREATE TABLE `t_goods_type` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`name` varchar(100) DEFAULT NULL COMMENT '名称',

`sortNum` int(11) DEFAULT NULL COMMENT '排序',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;

insert into `t_goods_type`(`id`,`name`,`sortNum`) values (1,'电子产品',1),(2,'服饰',2),(3,'书籍',3),(4,'食品',4),(5,'生活用品',5),(6,'运动器械',6),(7,'代步工具',7),(8,'求购',8);

DROP TABLE IF EXISTS `t_message`;

CREATE TABLE `t_message` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`userId` int(11) DEFAULT NULL COMMENT '接收人id',

`content` varchar(500) DEFAULT NULL COMMENT '内容',

`time` datetime DEFAULT NULL COMMENT '添加时间',

`isRead` int(11) DEFAULT NULL COMMENT '是否已读,0表未读,1表示已读',

PRIMARY KEY (`id`),

KEY `t_message_ibfk_1` (`userId`),

CONSTRAINT `t_message_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=utf8;

insert into `t_message`(`id`,`userId`,`content`,`time`,`isRead`) values (6,56,'你的商品（优衣库秋冬男装摇粒绒半拉链套头衫(长袖保暖抓绒) 441257）已被预定，请联系买家当面交易哦！！','2022-01-18 14:57:32',0),(7,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预定，请联系买家当面交易哦！！','2022-01-18 17:11:39',0),(8,56,'你的商品（加绒加厚保暖上衣v领黑色打底衫女秋冬内搭长袖t恤时尚鸡心领百搭）已被预定，请联系买家当面交易哦！！','2022-01-18 17:13:55',0),(9,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预定，请联系买家当面交易哦！！','2022-01-18 17:16:25',0),(10,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预定，请联系买家当面交易哦！！','2022-01-18 17:18:26',0),(11,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预定，请联系买家当面交易哦！！','2022-01-18 17:18:59',0),(12,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预定，请联系买家当面交易哦！！','2022-01-18 22:16:58',0),(13,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预定，请联系买家当面交易哦！！','2022-01-18 22:21:13',0),(14,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-01-18 23:53:04',0),(15,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-01-18 23:53:43',0),(16,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被卖家取消预订！！','2022-01-18 23:56:32',0),(17,56,'你的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被预订，请联系买家当面交易哦！！','2022-01-18 23:57:49',0),(18,2,'你预订的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被卖家取消预订！！','2022-01-19 00:03:45',0),(19,56,'你的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被预订，请联系买家当面交易哦！！','2022-04-17 21:58:27',0),(20,2,'你预订的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被卖家取消预订！！','2022-04-17 22:16:58',0),(21,56,'你的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被预订，请联系买家当面交易哦！！','2022-04-17 22:17:34',0),(22,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-04-17 22:20:15',0),(23,56,'你的商品（1）已被预订，请联系买家当面交易哦！！','2022-04-17 22:22:52',0),(24,2,'你预订的商品（1）已被卖家取消预订！！','2022-04-17 22:23:22',0),(25,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被卖家取消预订！！','2022-04-17 22:23:57',0),(26,56,'你的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被卖家取消预订！！','2022-04-17 22:24:04',0),(27,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-04-17 22:25:43',0),(28,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被卖家取消预订！！','2022-04-18 23:23:46',0),(29,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-04-19 00:15:26',0),(30,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-04-19 00:31:28',0),(31,56,'你的商品（三星A52千元学生5G智能数码手机Samsung Galaxy）已被预订，请联系买家当面交易哦！！','2022-04-19 00:32:47',0),(32,56,'你的商品（超薄办公一体机电脑高端四核i3i5i7家用网吧吃鸡游戏型独显台式主机19-27英寸非触摸屏高配整机）已被预订，请联系买家当面交易哦！！','2022-04-19 00:33:37',0),(33,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被卖家取消预订！！','2022-04-19 00:35:57',0),(34,2,'你预订的商品（超薄办公一体机电脑高端四核i3i5i7家用网吧吃鸡游戏型独显台式主机19-27英寸非触摸屏高配整机）已被卖家取消预订！！','2022-04-19 00:38:27',0),(35,56,'你的商品（畅享20Plus 8+128G 6.63英寸4800W华为5g手机）已被预订，请联系买家当面交易哦！！','2022-04-19 00:41:56',0),(36,56,'你的商品（1）已被预订，请联系买家当面交易哦！！','2022-04-19 11:31:33',0),(37,56,'你的商品（1）已被卖家取消预订！！','2022-04-19 11:32:30',0);

DROP TABLE IF EXISTS `t_reserve_record`;

CREATE TABLE `t_reserve_record` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`goodsId` int(11) DEFAULT NULL COMMENT '商品id',

`userId` int(11) DEFAULT NULL COMMENT '支付人id',

`reserveTime` datetime DEFAULT NULL COMMENT '支付时间',

`state` int(11) DEFAULT NULL COMMENT '是否取消,0代表未取消,1代表已取消',

PRIMARY KEY (`id`),

KEY `userId` (`userId`),

KEY `goodsId` (`goodsId`),

CONSTRAINT `t_reserve_record_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE,

CONSTRAINT `t_reserve_record_ibfk_2` FOREIGN KEY (`goodsId`) REFERENCES `t_goods` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8;

insert into `t_reserve_record`(`id`,`goodsId`,`userId`,`reserveTime`,`state`) values (33,27,2,'2022-04-19 00:31:28',1),(34,28,2,'2022-04-19 00:32:47',2),(35,29,2,'2022-04-19 00:33:37',1),(36,27,2,'2022-04-19 00:41:56',0);

DROP TABLE IF EXISTS `t_user`;

CREATE TABLE `t_user` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`userName` varchar(50) DEFAULT NULL COMMENT '用户名',

`password` varchar(50) DEFAULT NULL COMMENT '密码',

`nickName` varchar(50) DEFAULT NULL COMMENT '昵称',

`type` int(11) DEFAULT NULL COMMENT '1代表管理员,2代表普通用户',

`email` varchar(50) DEFAULT NULL COMMENT '邮箱',

`status` int(11) DEFAULT NULL COMMENT '1代表正常,2代表封禁',

`imageName` varchar(50) DEFAULT NULL COMMENT '用户头像图片名',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=58 DEFAULT CHARSET=utf8;

insert into `t_user`(`id`,`userName`,`password`,`nickName`,`type`,`email`,`status`,`imageName`) values (1,'admin','admin','乐道',1,'12030074691@qq.com',1,NULL),(2,'2','2','tom',2,'123@qq.com',1,'202201121805431641981943150.jpg'),(3,'3','3','jack',2,'1231@qq.com',0,'202201130053431642006423417.jpg'),(56,'1','1','哈哈',2,'122319@qq.com',1,'202204082218211649427501467.jpg'),(57,'4','4','4',2,'1203007469@qq.com',1,'202204182049341650286174535.jpg');

实验四系统测试报告

1 引言

1.1 编写目的

本测试报告为校园二手交易平台的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求。预期参考人员包括用户、测试人员、开发人员。

1.2 背景

项目名称：校园二手交易平台

提出者：xxx

开发者：xxx、xxx、xxx、xxx。

用户：在校师生

测试环境与实际运行环境之间可能存在的差异以及对测试结果的影响：

硬件配置差异：

差异：测试环境可能使用较低配置的硬件设备，而实际运行环境则需要更高配置的硬件设备以支持更高的并发量和更大的数据处理能力。

影响：在测试环境中，由于硬件配置较低，可能无法完全模拟实际运行环境中软件在高负载下的表现。这可能导致一些在高并发或大数据量下才会出现的问题在测试环境中被遗漏。

数据库差异：

差异：测试环境通常使用较小的数据库，而实际运行环境则需要使用更大的数据库以支持更多的数据存储和更高的并发查询。

影响：使用较小的数据库进行测试可能导致无法完全模拟实际运行环境中数据库的性能瓶颈和并发问题。此外，测试数据可能与实际数据存在结构或数据分布上的差异，进一步影响测试结果。

安全性差异：

差异：实际运行环境需要更高的安全性保障，包括更严格的访问控制、更复杂的身份验证和更完善的数据加密等。

影响：测试环境中可能无法完全模拟实际运行环境的安全性设置。这可能导致一些与安全性相关的潜在问题在测试环境中被忽略，而在实际运行环境中暴露出来。

综上所述，测试环境与实际运行环境之间的差异可能导致一些潜在问题在测试环境中被遗漏，而在实际运行环境中暴露出来。因此，在软件测试过程中需要充分考虑这些差异，并尽可能在测试环境中模拟实际运行环境的条件，以提高测试的有效性和准确性。

1.3 参考资料

《软件工程导论（第五版）》张海藩编著清华大学出版社出版
《实用软件工程》郑人杰编著清华大学出版社出版
项目开发计划（GB8567------88）项目概述

2 测试概要

下表2-1测试概要表列出了对"易物"二手交易平台的每一项测试的标识符及其测试内容，指明了实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，并说明了做出这种改变的原因。

表2-1测试概要表

|-------------------|-------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| 标识符 | 测试内容 | 与测试计划的差别及改变原因 |
| Management-01 | 对购买商品功能进行测试，包括审核用户是否登录、审核是否有添加信息权限、人机交互、对填写数据的核验等功能的测试 | 在实际进行测试过程中发现对填写数据的核验功能上还有很多地方需要增添测试用例。因为数据的多样性及不同类型数据的要求不同，测试计划中并没有具体描述 |
| Management-02 | 对下架功能进行测试，包括删除商品、取消删除动作、确定删除动作、删除成功提示等功能的测试 | 在实际进行测试过程中在取消删除功能上增添了测试用例，即当通知信息不同时测试是否均可成功删除相关信息。因为测试计划是从管理的角度对测试活动进行规划，但在实际测试中是从技术的角度出发的 |
| Management-03 | 对修改账户信息功能进行测试，包括点击修改按钮信息变成可编辑状态、验证修改数据的有效性、重置、确认修改动作、提示修改成功等功能的测试 | 实际进行的测试工作内容与测试计划中预先设计的内容之间并无差别 |
| UserManagement-01 | 对查看商品信息功能进行测试， | 实际进行的测试工作内容与测试计划中预先设计的内容之间并无差别 |

2.1 测试环境

下表2-2测试环境配置表说明了"易物"二手交易平台系统测试需要搭建的测试环境，测试环境中硬件、软件，包括测试工具的配置等内容。

表2-2 测试环境配置图

|--------|-----------------------------------|--------------------------|----------|
| 环境 | 硬件配置 | 软件配置 | 网络配置 |
| 应用服务器 | CPU：CPU奔腾Ⅲ以上内存：512M以上硬盘：500G或以上 | Windows Tomcat 8.0 | 10M LAN |
| 数据库服务器 | CPU：CPU奔腾Ⅲ以上内存：512M以上硬盘：500G或以上 | MySQL | 10M LAN |
| 客户端 | CPU：CPU奔腾Ⅲ以上内存：512M以上硬盘：100G或以上 | Windows | 10M LAN |
| 测试工具 | | FastRequest/Jmeter/JUnit | |

2.2 测试计划

测试计划使测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等。下表2-3测试计划表确定了测试所需要的时间和资源，以确保其可获得性、有效性。

表2-3 测试计划

|-----------|------------|------------|------------|------------|--------|----------|
| 版本/时间 | 计划开始时间 | 实际开始时间 | 计划结束时间 | 实际结束时间 | 加班 | 增加资源 |
| 用户模块 | 6-10 | 6-8 | 6-11 | 6-9 | 否 | 否 |
| 订单模块 | 6-12 | 6-10 | 6-13 | 6-11 | 否 | 否 |
| 商品模块 | 6-14 | 6-12 | 6-15 | 6-12 | 否 | 否 |
| 留言模块 | 6-17 | 6-15 | 6-17 | 6-15 | 否 | 否 |

3 测试用例

3.1 功能测试

3.1.1 用户信息管理测试

用户信息管理测试用例相关详细信息如下表表3-1所示：

表3-1 用户信息管理测试用例（xxx编写）

|--------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
| 条目 | 内容 |
| 测试用例编号 | A001 |
| 功能名称 | 用户模块 |
| 测试日期 | 2024/6/8 |
| 测试人员 | xxx |
| 测试目的 | 确保用户信息的安全、准确和易用性 |
| 前置条件 | 无 |
| 测试步骤 | 1、以管理员身份登录系统。 2、进入用户管理界面，查看用户列表。 3、选择一个用户，进行修改操作，验证是否成功执行。 4、尝试修改不存在的用户，验证系统是否提示错误信息。 5、添加一个用户，输入用户名、昵称、密码、邮箱。 6、点击删除按钮来删除一个用户 7、输入用户名点击搜索按钮来查询一个用户 |
| 预期结果 | 3.1、用户信息修改成功。 3.2、新密码不符合规范，修改失败。 4.1、用户信息错误，修改失败。 5.1、用户添加成功。 5.2、信息不规范，添加失败。 6.1、删除用户成功。 7.1、查询到该用户并显示该用户信息。 7.2、未查询到该用户。 |
| 实际结果 | 3.1、新密码符合规范，用户信息修改成功。 3.2、新密码不符合规范，修改失败。 4.1、用户信息错误，修改失败。 5.1、用户添加成功 5.2、信息不规范，添加失败 6.1、删除用户成功 7.1、显示该用户信息 7.2、未查询到该用户 |
| 结论 | 测试结果与预期结果相符。 |

3.1.2 商品模块相关功能测试

商品模块相关功能测试用例相关详细信息如下表表3-2所示：

表3-2 商品模块相关功能测试用例（xxx编写）

|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 条目 | 内容 |
| 测试用例编号 | A002 |
| 功能名称 | 商品模块 |
| 测试日期 | 2024/6/12 |
| 测试人员 | xxx |
| 测试目的 | 确保商品模块相关功能的安全、准确和易用性 |
| 前置条件 | 无 |
| 测试步骤 | 1. 以用户身份登录系统 2. 登录后自动跳转系统首页，验证首页是否能正常显示商品列表 3. 在首页搜索框输入关键字搜索，验证是否能够正常显示包含该关键字的商品 4. 进入分类页，点击各分类，验证是否能够分别显示各分类下对应的商品数据 5. 用户进入商品发布页，输入商品名称、价格，商品详情，选择商品类别，上传图片，点击提交按钮，验证商品是否发布成功，并顺利跳转我的商品页面 6. 用户进入我的商品页面，在我的商品列表，点击查看详情，验证是否能够显示商品详细信息（名称、价格、类别、详情/图片） 7. 用户在我的商品列表，点击修改，任意修改商品数据，点击提交，跳转我的商品列表，并且再次点击商品详情，验证是否与修改后的数据一致 8. 用户在我的商品列表，点击删除，验证是否删除成功 9. 以管理员身份登录系统 10. 管理员进入商品类别管理页，点击添加，输入名称和排序，点击保存，验证是否添加类别成功 11. 管理员选中某个类别，点击修改，任意修改输入项，点击保存，验证是否修改成功 12. 管理员选中某个类别，点击删除，验证是否删除成功 13. 管理员进入商品管理页，选中某个商品，点击查看，验证是否能够显示该商品详细信息 14. 管理员选中某个状态为未审核的商品，点击审核通过，验证是否审核通过成功 |
| 测试步骤 | 15. 管理员选中某个状态为上架中的商品，点击推荐与否，点击确定，输入推荐天数，点击保存，验证是否推荐成功 16. 管理员选中某个状态为被推荐的商品，点击推荐与否，点击确定，验证是否不推荐成功 17. 管理员选中某个状态为非审核不通过的商品，点击审核不通过，点击确定，输入审核不通过理由，点击保存，验证是否审核不通过成功 18. 管理员选中任意商品，点击删除，验证是否删除成功 |
| 预期结果 | 2.1商品列表能够正常显示 3.1能够正常显示包含该关键字的商品 3.2 没有包含该关键字的商品，显示搜索该关键字的结果有0个，不显示任何商品数据 4.1能够分别显示各分类下对应的商品数据 4.2 该分类下没有数据，显示无数据，不显示任何商品 5.1商品发布成功，并顺利跳转我的商品页面 5.2 商品名称为空，提示必须填写该字段 5.3 商品类别为空，提示必须填写该字段 5.4 商品价格为空，提示必须填写该字段 5.5 商品详情为空，提示必须填写该字段 6.1能够显示商品详细信息（名称、价格、类别、详情/图片） 7.1 用户修改商品成功，与修改后的数据一致 8.1 用户删除商品成功，我的商品列表不再显示该商品 10.1 添加商品类别成功，成功显示到商品列表 10.2 商品类别名称为空，提示该输入项为必需项 10.3 商品类别排序为空，提示该输入项为必需项 11.1 商品类别修改成功，提示保存成功，在类别列表显示正确的修改后数据 12.1 删除成功，类别列表不再显示该条类别数据 13.1 成功显示该商品详细信息 14.1 审核通过成功，状态变为已上架 15.1 推荐成功，状态变为被推荐 |
| | 15.2 推荐天数未填写，提示该输入项为必填项 16.1 提示不推荐成功，状态变为不推荐 17.1审核不通过成功，状态变为审核不通过 17.2 未填写审核不通过理由，提示该输入项为必需项 18.1 商品删除成功，商品列表不再显示该商品 |
| 实际结果 | 2.1商品列表能够正常显示 3.1能够正常显示包含该关键字的商品 3.2 没有包含该关键字的商品，显示搜索该关键字的结果有0个，不显示任何商品数据 4.1能够分别显示各分类下对应的商品数据 4.2 该分类下没有数据，显示无数据，不显示任何商品 5.1商品发布成功，并顺利跳转我的商品页面 5.2 商品名称为空，提示必须填写该字段 5.3 商品类别为空，提示必须填写该字段 5.4 商品价格为空，提示必须填写该字段 5.5 商品详情为空，提示必须填写该字段 6.1能够显示商品详细信息（名称、价格、类别、详情/图片） 7.1 用户修改商品成功，与修改后的数据一致 8.1 用户删除商品成功，我的商品列表不再显示该商品 10.1 添加商品类别成功，成功显示到商品列表 10.2 商品类别名称为空，提示该输入项为必需项 10.3 商品类别排序为空，提示该输入项为必需项 11.1 商品类别修改成功，提示保存成功，在类别列表显示正确的修改后数据 12.1 删除成功，类别列表不再显示该条类别数据 13.1 成功显示该商品详细信息 14.1 审核通过成功，状态变为已上架 15.1 推荐成功，状态变为被推荐 15.2 推荐天数未填写，提示该输入项为必填项 16.1 提示不推荐成功，状态变为不推荐 17.1审核不通过成功，状态变为审核不通过 |
| | 17.2 未填写审核不通过理由，提示该输入项为必需项 18.1 商品删除成功，商品列表不再显示该商品 |
| 结论 | 测试结果与预期结果相符。 |

3.1.3 预定管理测试

用户信息管理测试用例相关详细信息如下表表3-3所示：

表3-3 预定管理测试用例（xxx编写）

3.1.4 购物车管理测试

购物车管理测试用例相关详细信息如下表表3-4所示：

表3-4 购物车管理测试用例（xxx编写）

|--------|---------------------------------------------------------------------------------------------------|
| 条目 | 内容 |
| 测试用例编号 | A001 |
| 功能名称 | 订单模块 |
| 测试日期 | 2024/6/10 |
| 测试人员 | xxx |
| 测试目的 | 确保购物车模块的安全、准确和易用性 |
| 前置条件 | 无 |
| 测试步骤 | 1. 以用户身份登录系统。 2. 进入商品界面，查看商品列表。 3. 选择一个商品，进行加入购物车操作，确认是否添加到购物车列表里。 4. 尝试从购物车列表里删除某个商品，验证系统是否成功删除。 |
| 预期结果 | 3.1 商品已成功添加购物车 3.2 商品已下架，添加失败 4.1 清掉购物车某个商品成功 |
| 实际结果 | 3.1 商品已成功添加购物车 3.2 商品已下架，添加失败 4.1 清掉购物车某个商品成功 |
| 结论 | 测试结果与预期结果相符。 |

3.1.5 留言模块相关功能测试

留言模块相关功能测试用例相关详细信息如下表表3-5所示：

表3-5 留言模块相关功能测试用例（xxx编写）

|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 条目 | 内容 |
| 测试用例编号 | A003 |
| 功能名称 | 留言模块 |
| 测试日期 | 2024/6/15 |
| 测试人员 | xxx |
| 测试目的 | 确保留言模块相关功能的安全、准确和易用性 |
| 前置条件 | 无 |
| 测试步骤 | 1. 以用户身份登录系统。 2. 登录后自动跳转系统首页，验证首页是否能正常显示个人中心或联系我们的功能按钮。 3. 在首页点击个人中心，并验证是否能跳转到个人中心页面。 4. 进入个人中心页，点击联系我们，输入留言内容（分别输入正常格式和异常格式），点击提交按钮，验证输入正常格式和非正常格式的情况下，是否能够提交成功，能够显示提交成功或提交失败。 5. 用户点击我的留言，验证是否显示留言时间，内容，回复和相关操作的列表数据。 6. 用户在留言操作列表下，点击查看详情的按钮，验证是否显示用户留言内容详情信息。 7. 用户在留言操作列表下，点击查看详情的按钮，点击修改的按钮，对原有的留言进行修改，点击提交按钮，跳转到原页面，并查询内容列表下，验证内容是否成功修改。 8. 在留言操作列表下，点击删除的按钮，验证留言是否删除成功。 9. 以管理员身份登录系统 10. 管理员进入用户联系方式管理页，点击用户留言管理，验证是否显示用户留言列表数据，在用户名搜索框输入用户名关键字，点击搜索，验证是否能够显示包含关键字的用户名的用户留言数据。 11. 管理员勾选用户留言列表序号的复选框，点击答复，输入对用户留言的答复，跳转原页面，验证是否答复成功。 12. 管理员勾选用户留言列表序号的复选框，点击删除，跳转原页面，验证是否删除成功。 |
| 测试步骤 | 13. 管理员点击重置，验证是否恢复默认设置。 |
| 预期结果 | 2.1商品列表能够正常显示 3.1跳转成功 4.1用户留言提交成功，跳转原页面 4.2用户留言为空，提示必须填写该字段 5.1能够显示用户留言信息（留言时间、内容、回复、操作） 6.1能够显示用户留言内容的详细信息 7.1 用户修改留言内容成功，与修改后的数据一致 8.1 用户删除留言内容成功，用户留言列表不再显示该留言 10.1 查询用户留言列表数据成功，成功显示到留言列表 10.2 搜索成功，显示包含该关键字的用户名的相关用户留言数据 11.1 单选，回复成功，跳转原页面，在回复列表显示已回复 11.2 多选，回复成功，跳转原页面，在回复列表显示已回复 12.1 单选，删除成功，留言列表不再显示该留言数据 12,2 多选，删除成功，留言列表不再显示该留言数据 13.1 重置成功，留言列表恢复默认数据。 |
| 实际结果 | 2.1商品列表能够正常显示 3.1跳转成功 4.1用户留言提交成功，跳转原页面 4.2用户留言为空，提示必须填写该字段 5.1能够显示用户留言信息（留言时间、内容、回复、操作） 6.1能够显示用户留言内容的详细信息 7.1 用户修改留言内容成功，与修改后的数据一致 8.1 用户删除留言内容成功，用户留言列表不再显示该留言 10.1 查询用户留言列表数据成功，成功显示到留言列表 10.2 搜索成功，显示包含该关键字的用户名的相关用户留言数据 11.1 单选，回复成功，跳转原页面，在回复列表显示已回复 11.2 多选，回复成功，跳转原页面，在回复列表显示已回复 12.1 单选，删除成功，留言列表不再显示该留言数据 12.2 多选，删除成功，留言列表不再显示该留言数据 13.1 重置成功，留言列表恢复默认数据。 |
| 结论 | 测试结果与预期结果相符。 |

3.2 质量测试

3.2.1 易用性

现有系统在易用性方面已经取得了一定的成果，查询、添加、删除和修改操作的相关提示信息已经做到了一致性和可理解性，使得用户在使用过程中能够清晰地了解操作的结果和影响。输入限制的正确性得到了保证，确保了系统的稳定性和数据的准确性。输入限制的提示信息也做到了正确性、可理解性和一致性，帮助用户更好地遵守输入规则，减少错误操作。

然而，现有系统在易用性方面仍存在一些不足之处，界面排版不够美观，可能会影响到用户的使用体验，甚至导致用户对系统的信任度下降。输入和输出字段的可理解性较差，可能会使用户在操作过程中感到困惑，增加误操作的风险。输入缺少解释性说明，可能会导致用户在输入时产生疑惑，不知道如何正确地填写信息。

因此，为了提高系统的易用性，我们需要对上述缺陷进行改进，包括优化界面排版，提高输入和输出字段的可理解性，以及增加输入的解释性说明。

3.2.2 可靠性

现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据，引发错误。

现有系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态。

3.2.3 兼容性

现有系统支持Windows下的Edge浏览器和火狐浏览器。现有系统未进行其他兼容性测试。

3.2.4 安全性

现有系统控制了以下安全性问题：

用户名和密码应对大小写敏感。

现有系统未控制以下安全性问题：

（1）登陆错误次数限制。

（2）把某一个登录后的页面保存下来，能单独对其进行操作不进行登录。

（3）直接输入某一页面的Url能打开页面并进行操作。

4 测试结果与结论

4.1 测试执行情况

系统测试人员：xxx、xxx、xxx、xxx、xxx

测试时间：2024年6月18日------2024年6月19日

此次测试严格按照项目计划和测试计划执行，按时完成测试计划规定的测试对象的测试。针对测试计划中规定的测试策略，在测试执行中都有体验，在测试执行过程中，依据测试计划和测试用例，对系统进行完整的测试。

遵循的原则：

（1）测试应尽早进行，最好是能够在需求阶段就开始介入。

（2）负责软件开发的人员应避免检查自己的程序。

（3）设计测试用例既要考虑到合法情况，也要考虑不合法情况。

（4）在测试程序时，不仅要检验程序是否做了该做的事情，还要检验程序是否做了不该做的事情，多余的工作中会带来副作用，影响程序的效率，甚至带来潜在的危害和错误。

（5）应长期保留所有测试用例，有助于以后修改程序后进行回归测试。

测试结果：用户模块、商品模块、订单模块和申诉模块与计划相符，测试无错误。

4.2 覆盖分析

本次测试对系统需求的覆盖情况为：需求覆盖率=Y（P）项/需求项总数×100%=100%

表4-1 覆盖分析

|------------|----------|----------|----------------------|
| 需求 /功能 | 测试类型 | 是否通过 | 备注 |
| 登录/注册 | 功能测试 | Y | |
| 用户信息管理 | 功能测试 | Y | 用户个人信息的维护（改、查） |
| 用户商品管理 | 功能测试 | Y | 用户商品的维护（增、删、改、查） |
| 用户订单管理 | 功能测试 | Y | 用户交易流程（查询、添加、购买、收货） |
| 用户购物车管理 | 功能测试 | Y | 用户对个人购物车的维护（增、删、改、查） |
| 管理员申诉管理 | 功能测试 | Y | 管理员处理申诉流程（查询、处理） |

表格中"是否通过"的四种状态：

$Y$ ：全部通过

$P$ ：部分通过

$N$ ：不通过

$N/A$ ：不可测试或者用例不适用

4.2 功能测试情况

黑盒测试又称功能性测试。在软件测试的领域内，黑盒测试就是把要测试的程序当作一个黑色的盒子，测试者看不到里面的程序的内部结构和数据处理的过程。通俗来讲，黑盒测试就是在进行从事的接口测试。它的目的是在于系统实现的功能是否可以按照程序规格说明书上的规定正常使用，系统能否合适的接收用户所输入的数据，并根据数据产生相应正确的输出数据，同时保证数据库文件或系统相关信息的完整性。

本文针对主要的和常用的功能进行了功能性测试，分别为用户信息管理功能测试、用户商品管理功能测试、用户订单管理功能测试、用户购物车管理功能测试、管理员申诉管理功能测试。通过等价类划分方法，在输入条件规定了取值范围或值的个数的情况下，确定一个有效的等价类和两个无效的等价类，对每个功能的等价类进行测试并记录预期、实际结果。

4.3 质量测试情况

一、性能测试

数据量准备

使用驱动对测试环境进行测试

硬件环境

处理器：英特尔 11th Gen Core i5-11400H @ 2.70GHz 六核

主板：华硕 FX506HCB

内存：16GB(3200 MHz/3200 MHz)

硬盘：512 GB(NVMe HFM512GD3JX013N)

显卡：英伟达 NVIDIA GeForce RTX 3050 Laptop GPU(4096MB)

软件环境

测试指导8.0

测试结果

软件和硬件环境可以完成此测试

二、压力测试

场景1：

内容：在这个场景中，有40个并发用户。同时，使用40个用户来操作客户端访问接口，一个周期一次。

结论：可运行，速度快。

场景2：

内容：在这个场景中，有20个并发用户，持续2小时。

结论：可运行，速度一般。

三、负载测试

场景1：

内容：在这个场景中，有100个并发用户。同时，使用100个用户来操作客户端访问接口，一个周期一次。

结论：软件过载，崩溃。

场景2：

内容：在这个场景中，有20个并发用户，持续2小时。

结论：软件过载，崩溃。

4.4 bug性质及模块分布图

校园二手交易平台系统bug类型及数量具体相关信息如下表4-2所示：

表4-2 bug类型及数量

|------------|------------|------------|------------|------------|------------|
| 模块 | Bug性质 |||||
| 模块 | A类 | B类 | C类 | D类 | 总数 |
| 登陆 | 0 | 1 | 0 | 0 | 1 |
| 注册 | 1 | 1 | 0 | 0 | 2 |
| 用户信息管理 | 1 | 2 | 1 | 0 | 4 |
| 用户商品管理 | 0 | 3 | 1 | 0 | 4 |
| 用户订单管理 | 0 | 0 | 1 | 0 | 1 |
| 管理员申诉管理 | 1 | 1 | 0 | 0 | 2 |

软件测试合格须符合以下标准：

表4-3 测试合格标准

|--------------|--------------|
| 错误类型 | 合格标准 |
| A类错误 | 无 |
| B类错误 | 无 |
| C类错误 | <1% |
| D类错误 | <5% |

4.5 改进建议

在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测试人员都严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时也可以降低沟通成本。
发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。
开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪。
开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。

实验五综合实践总结报告

第一章绪论

1.1 课题研究的目的和意义

依照项目开发计划书所确定的工作范围为指南，本文为明确软件需求，明细系统内部模型，为设计阶段打下坚实的基础；明确系统运行支持环境要求、系统功能、设计时应该遵循的原则、约束条件以及性能等要求。

本文目的是深入描述校园二手交易平台的功能和性能以及界面等细节，面向系统分析员、编码人员、测试人员和最终用户，是后续整个系统软件开发的依据，也是项目完成后系统验收的依据。

读者对象为本小组成员、项目组长、系统设计人员、测试人员，客户

1.2 课题研究的背景

1.2.1 国内研究现状

随着时代的发展与国民经济水平的提高，当代大学生越来越喜欢市场上新奇的各类商品，但随着新鲜感的消失，导致越来越多的闲置物品堆积，但随着国内高校学生消费观念的改变，越来越多的大学生可以接受收二手产品的交易，只需要花费较低的价格，便可淘到自己需要的各类物品。校园二手交易平台应运而生，该平台可便于高校学生快捷方便的售卖以及购买二手产品，解决了闲置物品堆积问题，更适合中国宝宝的二手交易平台。

1.2.2国外研究现状

据几个头部二手交易站总结下来，海外的这类平台大概分为三种：

1、多数平台只卖某一类商品，综合类二手交易平台不多。ThredUP是出售儿童以及女性服装的平台，在海外还有一个Grailed，是一个男性服装的交易平台。此外还有做奢侈品交易的the Real Real等。

2、没有商品种类限定的平台，多数仅限于本地交易。比如月访问量达到550万的offerup就是一个类似于58同城的网站。不过似乎很多美国用户对二手商品的可靠性非常警惕，所以还出现了bookoo、Letgo这种当面交易的平台，没有线上支付，也不做电商，根据地理位置就近交易。

3、很多交易平台不仅限于二手交易。一些二手交易平台甚至偏离了二手交易平台处理闲置商品的本意，将平台变成了一个面向特定爱好者之间的好物交易市场。StockX是一个球鞋交易站，大部分出售的球鞋是全新状态。这个平台的买卖采用的是拍卖的玩法，而且可以拍卖到的球鞋的生产时间可以选到2001年之前，可以说是收藏价值大于实用价值。

由于国外交易市场的开放性较大，二手市场的发展更加的多元化，较之国内也更能吸人眼球，因此二手交易平台可见还有很大的市场空间。

1.3 系统开发环境简介

本系统采用B/S结构，运行平台为Windows 10，系统开发平台为IDEA，系统开发语言为JAVA，系统后台数据库为MySQL，分辨率最佳效果为1980×1200。

1.3.1 B/S结构的数据库访问模式

在B/S体系结构系统中，用户通过浏览器向分布在网络上的许多服务器发出请求，服务器对浏览器的请求进行处理，将用户所需信息返回到浏览器。B/S结构简化了客户机的工作，客户机上只需配置少量的客户端软件。服务器将担负更多的工作，对数据库的访问和应用程序的执行将在服务器上完成。浏览器发出请求，而其余如数据请求、加工、结果返回以及动态网页生成等工作全部由Web Server完成。实际上B/S体系结构是把二层C/S结构的事务处理逻辑模块从客户机的任务中分离出来，由Web服务器单独组成一层来负担其任务，这样客户机的压力减轻了，把负荷分配给了Web服务器 $2$ 。B/S三层体系结构如图1-1所示。

图1-1 B/S三层架构示意图

这种结构不仅把客户机从沉重的负担和不断对其提高的性能的要求中解放出来，也把技术维护人员从繁重的维护升级工作中解脱出来。由于客户机把事务处理逻辑部分分给了功能服务器，使客户机一下子"苗条"了许多，不再负责处理复杂计算和数据访问等关键事务，只负责显示部分，所以维护人员不再为程序的维护工作奔波于每个客户机之间，而把主要精力放在功能服务器上程序的更新工作。这种三层结构在层与层之间相互独立，任何一层的改变不会影响其它层的功能。

1.3.2 IDEA简介

IDEA全称IntelliJ IDEA，是Java语言开发的集成环境，IntelliJ在业界被公认为最好的Java开发工具之一，尤其在智能代码助手、代码自动提示、重构、J2EE支持、各类版本工具(git、svn、github等)、JUnit、CVS整合、代码分析、创新的GUI设计等方面的功能可以说是超常的。IDEA是JetBrains公司的产品，这家公司总部位于捷克共和国的首都布拉格，开发人员以严谨著称的东欧程序员为主。它的旗舰版本还支持HTML，CSS，PHP，MySQL，Python 等。免费版只支持Java等少数语言。

1.3.3 JSP动态网络技术与Tomcat简介

JSP（JavaServer Pages）是Sun公司推出的一种动态网页技术。JSP技术是以Java语言作为脚本语言的，熟悉JAVA语言的人可以很快上手。

JSP本身虽然也是脚本语言，但是却和PHP、ASP有着本质的区别。PHP和ASP都是由语言引擎解释执行程序代码，而JSP代码却被编译成Servlet并由Java虚拟机执行，这种编译操作仅在对JSP页面的第一次请求时发生。因此普遍认为JSP的执行效率比PHP和ASP都高 $3$ 。

1.4 论文的工作内容及论文的结构

1.4.1 论文的工作内容

本文为校园二手交易平台提供了理论逻辑上的支持，包括需求分析、系统设计、详细设计与实现、软件测试部分，对个人实现的子系统功能进行用例设计，类设计，数据库设计，界面设计，在系统实现过程中，通过文档提供一定的理论逻辑设计。

1.4.2 论文的结构

本论文各章节安排如下：

第一章对论文的选题背景、意义进行了阐述，并对系统设计思想进行详细的分析，对项目的开发方向进行了初步界定。

第二章从本系统的用户需求角度开始分析，明确本项目的详细需求，供用户确认项目的功能和性能，和用户形成一致的理解和确认，确定用例并进行UML建模，明确系统所要实现的功能。

第三章从系统设计角度进行分析，详细设计分析需要实现的功能，确定软件的结构和需要实现的类，详细设计类图和顺序图，建立数据库模型设计数据库表结构。

第四章对信息通知管理系统的实现过程和方法进行了详细的描述并对设计中的遇到的一些问题进行了分析，演示代码运行后的界面效果。

第五章从软件测试角度分析系统成品的质量情况，测试本系统的功能性和质量。在代码编写完成后进行测试，持续完善系统的功能解决发现的问题，回顾了软件测试的相关知识后对每个输入数据进行测试，对各界面之间的跳转和数据库操作情况进行测试，修改测试出的问题。

第二章需求分析

本章将对校园二手交易平台进行需求分析，并确定出校园二手交易平台的基本数据需求、功能需求和性能需求，为以后系统的设计与实现提供依据。主要建立系统的事件表、用例图、用例描述、对象关系模型和顺序图等。

2.1 需求基础

2.1.1需求

校园二手交易平台主要是用于高校在校学生售卖以及购买二手闲置物品，为了满足学生低价买好物以及清理堆积闲置需要，应用目标为各大高校，作用范围为学生。系统将分为买家、卖家和平台管理员三种参与者，进行商品的浏览，购买，申诉；上架商品和下架商品；交易申诉以及介入矛盾交易。本平台为一个独立的软件，全部内容自含 $4$ 。

2.1.2 识别系统相关者

采用参与者词汇表进行描述，如表2-1所示。

表2-1 参与者词汇表

2.2系统用例模型

2.2.1 用例图

校园二手交易平台主要是用于高校在校学生售卖以及购买二手闲置物品，为了满足学生低价买好物以及清理堆积闲置需要，应用目标为各大高校，作用范围为学生。系统将分为买家、卖家和平台管理员三种参与者，进行商品的浏览，购买，申诉；上架商品和下架商品；交易申诉以及介入矛盾交易。

系统用例图如图2-1所示。

图2-1 系统用例图

2.2.2 关键用例描述

上架商品用例描述如下：

表3-3 上架用例描述（xxx编写）

|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 上架商品 |
| 用例ID | MSM1101 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 个人信息完整的用户 |
| 其他参与者 | 无。 |
| 描述 | 用户向系统提交商品的详细信息。 |
| 前置条件 | 用户登录且绑定信息完整。 |
| 后置条件 | 用户成功上架商品。 |
| 触发条件 | 用户成功上架商品。 |
| 基本流程 | 1.用户开始上架商品。 2.系统检查用户信息（学号、联系方式、姓名、身份证号、寝室门牌号）是否完整，若完整跳转至商品信息填写界面。 3.用户填写商品信息（商品名称、商品价格、商品数量）。 4.系统检查商品信息（商品价格、商品数量）完整正确，若完整且正确回显商品上架成功提示。 5.商品成功上架。 |
| 替代流程 | 2a.用户信息完整，跳转至商品信息填写界面。 2b.用户信息不完整，用户需完善个人信息。 4a.商品信息完整且正确，系统回显上架成功提示。 4b.商品信息不完整或不正确，用户需修改商品信息。 |
| 结束 | 用户商品上架成功。 |
| 实现约束和说明 | 商品信息需要用户手动输入。 |
| 待解决问题 | 无。 |

上架商品用例活动图如图3-3所示。

图3-3 上架商品用例活动图（xxx绘制）

下架商品用例描述如下：

表3-4 下架商品用例描述（xxx编写）

下架商品用例活动图如图3-4所示。

图3-4 下架商品用例活动图（xxx绘制）

编辑个人信息用例描述如下：

表3-5 编辑个人信息用例描述（xxx编写）

|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 编辑个人信息 |
| 用例ID | MSM1103 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 每个用户，系统 |
| 其他参与者 | 无 |
| 描述 | 该用例允许已注册的用户更新或修改他们的个人资料信息。用户可以通过此功能更改其姓名、联系方式、密码等个人信息。 |
| 前置条件 | 用户必须已经登录到系统。 |
| 后置条件 | 用户的个人信息将被更新，并在系统中反映出来。 |
| 触发条件 | 用户希望更新或更改存储在系统中的个人数据。 |
| 基本流程 | 1. 用户登录到系统。 2. 用户点击"个人资料"或"设置"链接。 3. 系统显示用户的当前个人信息。 4. 用户选择要编辑的信息字段，如姓名、联系方式、密码等。 5. 用户输入新的信息并点击"保存"按钮。 6. 系统验证新信息的有效性。 7. 如果新信息有效，系统将更新用户的个人信息。系统显示更新成功的信息。 |
| 结束 | 用户成功修改个人信息 |
| 实现约束和说明 | 无 |
| 待解决问题 | 无 |

编辑个人信息用例活动图如图3-5所示。

图3-5 编辑个人信息用例活动图（xxx绘制）

管理员发布系统公告用例描述如下：

表3-7 管理员发布系统公告用例描述（xxx编写）

|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 管理员发布系统公告 |
| 用例ID | MSM1104 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 管理员 |
| 描述 | 管理员在平台发布系统公告 |
| 前置条件 | 管理员必须已经以管理员身份登录系统。管理员需要进入"管理通知公告"页面，其中列出了已有的通知公告清单。 |
| 后置条件 | 系统公告成功发布，用户可在网站首页或其他指定位置看到新发布的公告。系统数据库更新，反映了新的公告信息状态。 |
| 触发条件 | 管理员决定发布新公告或更新现有公告。系统要求发布重要信息或变更通知。 |
| 基本流程 | 1. 管理员在后台登录系统，进入公告管理界面。 2. 管理员点击"发布公告"按钮，进入公告编辑页面，填写公告标题、内容、发布时间等信息。 3. 管理员点击"预览"按钮，查看公告效果。如果满意，点击"提交"按钮，将公告信息提交至系统审核。 4. 系统自动对公告内容进行审核，如无违规内容，审核通过。 5. 管理员再次确认发布，公告信息将在指定时间自动发布至网站首页或其他指定位置。 |
| 替代流程 | 4.如果系统审核未通过，管理员需根据反馈修改公告内容后重新提交。 |
| 结束 | 管理员成功发布系统公告 |
| 实现约束和说明 | 管理员必须有相应的权限才能进行公告的发布。公告内容应符合相关法律法规，避免包含敏感词汇。公告发布时间应准确，确保用户能够及时接收到信息。 |

管理员发布系统公告用例活动图如图3-6所示。

图3-6 管理员发布系统公告用例活动图（xxx绘制）

修改商品用例描述如下：

表3-7 修改商品用例描述（xxx编写）

|----------|---------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 修改商品 |
| 用例ID | MSM1102 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 个人信息完整的用户 |
| 其他参与者 | 无。 |
| 描述 | 用户修改商品的详细信息。 |
| 前置条件 | 用户登录且绑定信息完整且该商品已上架。 |
| 后置条件 | 用户成功修改商品信息。 |
| 触发条件 | 用户修改商品信息。 |
| 基本流程 | 1.用户开始修改商品信息。 2.系统检查用户信息（学号、联系方式、姓名、身份证号、寝室门牌号）是否完整，若完整跳转至商品信息界面。 3.用户可修改商品信息（商品名称、商品价格、商品数量）。 4.系统检查商品信息（商品价格、商品数量）是否正确，若正确显示修改成功提示。 5.商品信息成功修改。 |
| 替代流程 | 2a.用户信息完整，跳转至商品信息界面。 2b.用户信息不完整，用户需完善个人信息。 4a.商品信息完整且正确，系统显示修改成功提示。 4b.商品信息不正确，用户需重新修改商品信息。 |
| 结束 | 用户修改商品信息成功。 |
| 实现约束和说明 | 商品信息需要用户手动输入。 |

修改商品用例活动图如图3-7所示。

图3-7 查询订单列表用例活动图（xxx绘制）

搜索商品用例描述如下：

表3-8 搜索商品信息用例描述（xxx编写）

|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 用例名 | 搜索商品 |
| 用例ID | MSM1104 |
| 用例类型 | 业务用例 |
| 主要业务参与者 | 个人信息完整的用户 |
| 其他参与者 | 无。 |
| 描述 | 用户可通过搜索查看某商品的详细信息。 |
| 前置条件 | 用户登录且绑定信息完整。 |
| 后置条件 | 用户成功搜索到该的商品信息。 |
| 触发条件 | 用户搜索商品。 |
| 基本流程 | 1.用户启动商品搜索流程：用户打开应用或网站，选择"搜索商品"功能。 2.系统验证用户资料完整性：系统自动检查用户的个人资料，包括学号、联系方式、姓名、身份证号和寝室门牌号。如果所有信息均已正确填写且无遗漏，系统将允许用户进入下一步。如果信息不完整，系统将提示用户补充必要的资料。 3.用户进行商品搜索：在通过资料验证后，用户被引导至商品搜索界面。用户在搜索栏中输入想要查找的商品名称，然后提交搜索请求。 4.系统处理商品搜索请求：系统根据用户输入的商品名称在数据库中查找匹配的商品信息。如果找到对应的商品，系统会展示商品的详细信息，如价格、库存量、规格参数、用户评价等。如果未找到相应的商品，系统将显示一条提示信息，告知用户"未找到该商品"。 5.可选的后续操作：用户可以查看商品的详细信息，进行比较或添加至购物车。如果用户对搜索结果不满意，可以尝试使用不同的关键词重新搜索，或者使用系统的高级搜索功能来缩小搜索范围。对于未找到的商品，用户可以向系统提出反馈或建议，以便系统改进搜索算法或增加商品库存。 |
| 替代流程 | 2a. 若用户资料齐全，系统将自动跳转至商品信息界面：一旦用户的学号、联系方式、姓名、身份证号和寝室门牌号等信息被验证为完整无误，系统会立即将用户界面切换至商品信息展示页面。在这里，用户可以细致查看各商品的详细描述，包括价格、促销信息、用户评价以及相关图片等。 2b. 若用户资料不全，系统将提示完善个人信息：如果用户信息有遗漏或错误，系统会显示提示消息，引导用户完成信息填写或更正。用户需按照提示输入或修正所缺信息，并重新提交以供系统验证。 4a. 如果系统库存中包含该商品，将详细显示商品信息：搜索结果若显示出用户查询的商品，系统会详尽地列出该商品的各项参数，如品牌、规格、库存状态等。用户可以在此基础上进一步了解商品或进行购买操作。 4b. 如果系统库存中不包含该商品，将提示用户商品未找到，并返回搜索界面：若数据库中没有用户搜索的商品信息，系统会展示"未找到该商品"的消息，并可能提供相关商品的推荐。用户可以选择继续搜索其他商品或返回至搜索主界面，重新进行商品查找。 |
| 结束 | 用户搜索商品完成。 |
| 待解决问题 | 无。 |

搜索商品活动图如图3-8所示。

搜索商品用例活动图如图3-8所示。

绑定银行卡用例描述如下：

表3-9绑定银行卡用例描述（xxx编写）

绑定银行卡用例活动图如图3-10所示。

图3-10绑定银行卡用例活动图（xxx绘制）

交易评价用例描述如下：

表3-11 交易评价用例描述（xxx编写）

交易评价用例活动图如图3-12所示。

图3-12 交易评价用例活动图（xxx绘制）

支付结算用例描述如下：

表3-13支付结算用例描述（xxx编写）

|-----------|-----------------------------------------------------------------------------------------------|
| 用例条目 | 内容 |
| 名称 | 支付结算 |
| ID | MSM1110 |
| 主要业务参与者 | 用户 |
| 其他参与者 | 无 |
| 触发条件 | 用户点击支付选项 |
| 前置条件 | 用户进入购物车界面 |
| 后置条件 | 用户购物车清空，用户成功支付订单 |
| 基本流程 | 1用户点击支付选项 2系统根据用户购物车信息与商品库存信息判断商品库存是否满足 3系统根据用户购物车信息与用户个人信息生成支付订单 4用户支付，系统回显支付成功提示 5系统清空用户购物车 |
| 扩展流程 | 2a. 若商品库存不足，订单生成失败，并回显错误提示 2b. 若商品库存充足，订单生成成功，并回显订单信息 4a. 用户支付，回显支付成功提示 4b. 用户长时间未支付，回显操作超时提示 |
| 实现约束或特殊需求 | 若用户长时间无操作，提示操作超时并返回主页 |
| 待解决问题 | 无 |

支付结算用例活动图如图3-14所示。

图3-14 支付结算用例活动图

提交投诉详情用例描述如下：

表3-15提交投诉详情用例描述（xxx编写）

|----------|------------------------------------------------------------|
| 用例条目 | 内容 |
| 名称 | 提交投诉 |
| ID | MSM1108 |
| 主要业务参与者 | 用户 |
| 其他参与者 | 无 |
| 触发条件 | 用户点击投诉 |
| 前置条件 | 用户已经确认收货 |
| 后置条件 | 用户撤销申诉 |
| 基本流程 | 1用户点击申诉 2系统回显申诉信息表单 3用户填写表单 4系统回显操作提示 5系统回显操作成功提示用户等待平台介入 |
| 扩展流程 | 4a. 用户确认操作，系统回显操作成功提示 4b. 用户未确认操作 |

提交投诉用例活动图如图3-16所示。

图3-16 提交投诉详情用例活动图

2.3 对象模型分析

校园二手交易平台对象模型如图2-12所示。

图2-12 "易物"二手交易平台对象模型

2.4 非功能性需求分析

2.4.1 质量需求

性能(Performance)：系统后台会合理分配服务器，来面对高峰期巨大数据井喷式增长的情况，并且将会发挥出我们的算法优势。

安全性(Security)：系统力争将会保护所有用户的隐私信息,并且我们系统后台数据库将会加大安全系数。

精度

本系统中输入的各种数据均要求精确到小数点后2位。

时间特性要求

响应时间：一般来说，响应时间应该在几秒内完成，以确保用户的体验。

更新处理时间：更新处理时间应该尽可能地短，以确保数据的及时性和准确性。

灵活性

操作方式上的变化：该软件应具备良好的用户界面设计，使得用户可以方便地进行各种操作。当需求发生变化时，该软件应该可以通过简单的界面调整或功能添加来满足新的操作方式需求。

运行环境的变化：该软件应具备跨平台性，能够适应不同的操作系统和硬件环境。同时，在运行环境发生变化时，该软件应该具备自适应能力，可以在新的环境中正常运行，不影响用户的使用体验。

同其他软件的接口的变化：该软件可能需要和其他软件进行数据交换或接口调用。当其他软件接口发生变化时，该软件应该可以灵活地适应新的接口，并保证数据传输的准确性和完整性。

精度和有效时限的变化：对于精度和有效时限的变化，该软件应该能够根据需求变化做出相应的调整，并且在保证准确性的同时，能够满足时限的要求。

计划的变化或改进：在软件开发过程中，难免会出现计划的变化或需要进行改进。该软件应该具备良好的可维护性和可扩展性，能够容易地进行修改和扩展，以适应计划的变化或改进。

2.4.2 故障处理要求

软件故障：软件崩溃、死循环、数据损坏等，可能导致系统崩溃、无法正常使用，甚至可能导致数据丢失和安全问题。

硬件故障：硬盘故障、内存故障、CPU故障等，可能导致系统崩溃、无法正常使用，甚至可能导致数据丢失和安全问题。

2.5 其它约束和限制

安全保密要求：该系统需要满足用户单位的保密要求，比如数据加密、用户身份验证、访问控制等机制。同时，该系统还需要保证系统的可靠性和稳定性，以确保用户的信息安全。

使用方便要求：该系统需要提供易于使用的界面和操作方式，使用户可以方便地管理、查询、统计等操作。此外，该系统还需要具备良好的易用性和可操作性，以降低用户使用的难度。

可维护性、可补充性和易读性要求：该系统需要提供清晰、易读的代码和文档，并具备可维护性、可补充性和易读性，以方便后续的系统维护和更新。

2.6 本章小结

首先，本章在开头建立了参与表以及事件表对该系统的操作有了一定描述；之后对该系统的主要功能进行了简洁的介绍，并用系统总用例图描述了系统的主要功能及参与人员；然后描述了该系统中主要的十个用例并叙述了该用例的用例描述，对于每个用例画出了用例的活动图；之后对系统的整个概念模型进行了分析与总结，并描绘了该系统总的概念模型分析图；最后对系统的非功能性需求分析进行了一些描述以及其他约束。

第三章系统设计

3.1 软件结构

校园二手交易平台组件图，如图3-1所示；

图3-1 校园二手交易平台组件图

3.1.1 开发结构

IntelliJ IDEA 2021，后台数据库管理系统为MySQL，系统的运行平台为Windows。系统运行在客户机上，对数服务器进行访问，代理据库访问的并发处理由MySQL控制。

3.1.2 拓扑结构

校园二手交易平台部署图，如图3-2所示；

图3-2 校园二手交易平台部署图

3.2 功能设计

用户接口

（1）上架商品接口：提供商品信息录入表单，包括标题、描述、价格、图片等字段。支持用户选择商品分类和属性。提供预览和确认上架功能。

（2）修改商品接口：提供编辑已上架商品的界面，允许用户修改商品信息。修改后应显示更新成功的提示，并允许用户预览修改后的商品。

（3）下架商品接口：提供商品列表，允许用户选择想要下架的商品。提供确认下架按钮，下架成功后显示相应提示。

（4）搜索商品接口：设计搜索框，支持关键词搜索和筛选条件搜索。显示搜索结果列表，包括商品图片、标题、价格等信息。

（5）购买商品接口：提供商品详情页面，展示商品详细信息及购买选项。·支持用户选择购买数量，进入结算页面。

（6）评价交易接口：交易完成后，提示用户进行评价。提供评价表单，包括文字评价和星级评分。

（7）提交投诉接口：提供投诉入口，用户可填写投诉内容和相关证据。支持用户选择投诉类型，如商品质量问题、卖家服务态度等。

（8）用户编辑资料接口：提供个人资料编辑页面，允许用户修改个人信息，如姓名、联系方式、收货地址等。提供头像上传和修改功能。

（9）订单通知接口：通过系统消息或邮件方式，向用户发送订单状态变更通知，如订单创建、支付成功、发货通知等。

（10）支付结算接口：整合第三方支付接口，支持多种支付方式。显示支付金额和支付状态，提供支付成功后的订单详情查看功能。

（11）充值余额接口：提供充值入口，支持用户通过第三方支付平台进行余额充值。显示充值金额和充值状态，更新用户余额。

软件接口

（1）商品管理接口：提供商品信息的增删改查功能，确保数据的准确性和一致性。处理商品上架、修改和下架的后台逻辑。

（2）搜索引擎接口：根据用户输入的关键词和筛选条件，提供商品搜索结果的接口。优化搜索算法，提高搜索速度和准确性。

（3）订单处理接口：接收用户提交的购买请求，创建订单并处理支付逻辑。更新订单状态，通知用户和卖家。

（4）评价管理接口：存储和管理用户评价信息，确保评价的真实性和可靠性。提供评价数据的统计和分析功能。

（5）投诉处理接口：接收用户提交的投诉信息，并进行审核和处理。通知相关方进行协调或解决投诉问题。

（6）用户数据管理接口：存储和管理用户个人资料信息，确保数据的安全性和隐私性。提供用户数据的修改和查询功能。

（7）通知服务接口：发送订单通知、支付通知等系统消息或邮件通知。支持自定义通知模板和推送方式。

（8）支付接口：与第三方支付平台对接，处理支付请求和支付结果回调。确保支付过程的安全性和稳定性。

（9）余额管理接口：处理用户余额的充值、扣款和查询操作。确保余额数据的准确性和安全性。

其他接口

3.2.1 上架商品用例的详细设计

上架商品用例的分析类

在二手交易平台的上架商品用例中，我们同样可以识别出接口类（边界类boundary）、控制类（control）和实体类（entity）。

A.接口类/边界类（Boundary Classes）:

这些是系统与用户或其他外部系统交互的接口。在上架商品这个用例中，可能的接口类有：UserInputInterface: 负责接收用户输入的商品信息，如商品名称、描述、价格、图片等。DisplayInterface: 负责展示商品上架的结果或错误信息给用户。

B.控制类（Controller Classes）:

ProductListingController:负责处理上架商品的逻辑。它接收来自UserInputInterface 的商品信息，调用Model层的相应方法来保存商品信息，并通过DisplayInterface显示结果。

C.实体类（Entity Classes）:

实体类代表系统中的数据对象。在上架商品的用例中，我们可能需要的实体类有：Product:表示商品的信息，包括商品ID、名称、描述、价格、图片URL等属性，以及相关的getter和setter方法。User:表示用户的信息，如用户名、密码、邮箱等。在商品上架的过程中，可能需要验证用户的身份。

D.模型类（Model Classes）:

ProductRepository:负责商品信息的存储和检索。它提供了方法，如 addProduct(Product product)用于添加新商品到数据库中，getProduct(ProductId id)用于检索特定商品的信息等。UserRepository: 负责用户信息的存储和验证。它可能提供了 authenticateUser(User user) 用于验证用户登录等方法

上架商品用例的接口类、控制类、实体类如表3-1所示。

表3-1 上架商品用例的接口类、控制类、实体类（xxx编写）

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现上架商品的功能。

上架商品用例的类图如图3-1所示：

图3-1上架商品用例的类图（xxx绘制）

确定用例的行为模型
在上架商品的流程中，用户首先通过 UserInputInterface 输入商品信息。然后，ProductListingController 接收这些信息，并验证用户身份（通过 UserRepository）。如果验证通过，ProductListingController 会创建一个 Product 对象，并通过 ProductRepository 将其保存到数据库中。最后，ProductListingController 通过 DisplayInterface 显示上架结果给用户。

上架商品用例的顺序图如图3-2所示。

图3-2上架商品用例的顺序图（xxx绘制）

3.2.2 下架商品用例的详细设计

下架商品用例的分析类

在下架商品的用例中，我们需要识别相应的接口类（boundary），控制类（control），和实体类（entity）。这些类将协同工作以完成下架商品的功能。

A.接口类/边界类（Boundary Classes）:

UserInputInterface: 提供用户输入下架商品信息的接口，如商品ID、下架原因等。DisplayInterface: 显示商品下架操作的结果或错误信息给用户。

B.控制类（Controller Classes）:

ProductDelistingController: 负责处理下架商品的逻辑。它接收来自 UserInputInterface 的下架请求，调用模型层的相应方法来执行下架操作，并通过 DisplayInterface 显示结果。

C.实体类（Entity Classes）:

Product: 代表商品信息，包括商品ID、名称、描述、价格等属性。User: 代表用户信息，包含用户名、密码等属性。

D.模型类（Model Classes）:

ProductRepository: 负责商品信息的存储和检索。它提供方法，如 removeProduct(ProductId id) 用于下架指定ID的商品。UserRepository: 负责用户信息的验证和管理。它用于验证当前操作的用户是否有权限下架商品。

下架商品用例的接口类、控制类、实体类如表3-2所示。

表3-2 下架商品用例的接口类、控制类、实体类（xxx编写）

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现下架商品的功能。

下架商品类图如图3-3所示：

图3-3下架商品类图（xxx绘制）

确定用例的行为模型

下架商品用例的顺序图如图3-4所示。

图3-4下架商品用例的顺序图（xxx绘制）

在下架商品流程中，用户通过 UserInputInterface 输入下架商品的ID以及可能的下架原因。ProductDelistingController 接收下架请求，并通过 UserRepository 验证用户身份和权限。如果用户验证通过，ProductDelistingController 调用 ProductRepository 的 removeProduct 方法来下架商品。ProductRepository 执行下架操作中的可能涉及更新数据库商品状态或移除相关记录。ProductDelistingController 通过 DisplayInterface 显示下架操作的结果给用户，例如成功下架或下架失败的原因。

3.2.3 编辑个人信息用例的详细设计

编辑个人信息用例的分析类

A.接口类：

user profile page：用户的个人资料页面，显示用户当前的个人信息，并提供编辑个人信息的入口。

edit profile form：编辑个人资料表单，允许用户填写或修改他们的个人信息，如姓名、联系方式、密码等。

B.控制类：

profile controller：个人资料控制器，负责接收用户的编辑请求，验证输入数据的合法性，并调用相应的模型方法来更新用户信息。

C.实体类：

user model：用户模型，包含用户id、姓名、联系方式、密码等属性，以及更新用户信息的方法。

validation service：验证服务，用于验证用户提交的信息是否符合要求，如检查密码强度、联系方式格式等。

上架商品用例的接口类、控制类、实体类如表3-1所示。

表3-3 编辑个人信息用例的接口类、控制类、实体类（xxx编写）

编辑个人信息用例的类图如图3-5所示：

图3-5上架商品用例的类图（xxx绘制）

validation service依赖于user model用于验证用户资料是否符合要求

确定用例的行为模型

编辑个人信息用例的顺序图如图3-6所示。

图3-6编辑个人信息用例的顺序图（xxx绘制）

3.2.4管理员发布系统公告用例的详细设计

管理员发布系统公告用例的分析类

A.接口类：

New Announcement Page：新公告页面，用于展示创建或编辑公告的表单。

Announcement List Page：公告列表页面，展示所有系统公告的列表，支持搜索和过滤功能。

Announcement Details Page：公告详情页面，显示单个公告的详细信息，以及编辑和删除选项。

B.控制类：

AnnouncementController：公告控制器，提供系统公告管理的主界面，允许管理员进行各种公告操作

C.实体类：

Announcement：公告，包含公告的属性，如标题、内容、发布日期、有效期等。

Admin：管理员，包含管理员的相关属性，如ID、姓名、权限等级等。

AnnouncementRepository：公告业务逻辑层，定义了公告的存储和检索方法，如获取所有公告、获取单个公告详情、创建新公告等。

管理员发布系统公告的接口类、控制类、实体类如表3-4所示。

表3-4管理员发布系统公告的接口类、控制类、实体类（xxx编写）

|---------------------------|------------------------|-----------------------|
| 接口类 | 控制类 | 实体类 |
| Announcement Details Page | AnnouncementController | Announcement |
| New Announcement Page | | Admin |
| Announcement List Page | | AnnouncementRepositor |

管理员发布系统公告类图如图3-7所示：

图3-7管理员发布系统公告类图（xxx绘制）

AnnouncementController：控制器类作为模型和视图之间的中介，处理所有公告相关的操作请求。Announcement：此实体类包含了公告的所有属性，如标题、内容等。Admin：代表系统管理员，包含其基本信息如ID和姓名。AnnouncementRepository：处理公告数据的存储和检索。Announcement Details Page，New Announcement Page，Announcement List Page依赖于AnnouncementController，用于负责处理管理员的请求，如创建新公告、更新或删除现有公告。此控制器接收来自视图的数据，调用模型进行处理，并返回响应到视图。Admin，Announcement依赖于AnnouncementReposito定义公告的存储和检索方法，如获取所有公告、获取单个公告详情、创建新公告等。

确定用例的行为模型

管理员点击发布公告页面进入新公告页面，编辑公告信息后，由公告业务逻辑层（AnnouncementRepository）检验公告是否合规，随后对公告（Announcement）更新相关公告信息，管理员在新公告页面（New Announcement Page）点击发布按钮后，由公告业务逻辑层（AnnouncementRepository）验证管理员（Admin）权限信息，成功发布后跳转公告列表页面（Announcement List Page），最后提示管理员发布成功公告。

管理员发布系统公告的顺序图如图3-8所示。

图3-8管理员发布系统公告类图（xxx绘制）

3.2.5 提交投诉用例的详细设计

提交投诉用例的分析类

A.接口类/边界类（Boundary Classes）:

SubmitComplaintForm提交投诉界面: 它提供用户填写投诉信息的界面。

B.控制类（Controller Classes）:

ComplaintHandler投诉处理: 它负责接收来自SubmitComplaintForm的投诉信息，验证数据的合法性，并将其传递给相应的实体类进行存储。

C.实体类（Entity Classes）:

Complaint: 表示投诉的信息，包括包含投诉ID、投诉状态、投诉内容、优先级等属性。

User: 表示用户的信息，包含用户ID、姓名、联系方式等属性。

D.模型类（Model Classes）:

ComplaintType: 投诉系统需要支持多种类型的投诉，ComplaintType模型类来表示不同类型的投诉，每个类型包含了特定的属性和方法。

提交投诉用例的接口类、控制类、实体类如表3-1所示。

表3-5 提交投诉用例的接口类、控制类、实体类（xxx编写）

|---------------------|------------------|-------------|
| 接口类 | 控制类 | 实体类 |
| SubmitComplaintForm | ComplaintHandler | Complaint |
| | ComplaintType | User |

提交投诉用例的类图如图3-9所示：

图3-9提交投诉用例的类图（xxx绘制）

确定用例的行为模型

提交投诉用例的顺序图如图3-10所示。

图3-10提交投诉用例的顺序图

3.2.6 支付结算用例的详细设计

支付结算用例的分析类

在支付结算的用例中，我们需要识别相应的接口类（boundary），控制类（control），和实体类（entity）。这些类将协同工作以完成支付结算的功能。

A.接口类/边界类（Boundary Classes）:

PaymentInterface:它提供用户填写支付信息的界面。

B.控制类（Controller Classes）:

PaymentProcessor: 它负责接收来自PaymentInterface的数据，验证数据的合法性，并将其传递给相应的实体类进行存储。

C.实体类（Entity Classes）:

Payment: 代表支付信息，包括支付金额、支付方式、支付状态等属性。

User: 表示用户的信息，包含用户ID、姓名、联系方式等属性。

D.模型类（Model Classes）:

PaymentMethod: 支付系统需要支持多种类型的支付方式，模型类来表示不同的支付方式，每种方式包含了特定的属性和方法。

支付结算用例的接口类、控制类、实体类如表3-2所示。

表3-6 支付结算用例的接口类、控制类、实体类（xxx编写）

|------------------|------------------|-------------|
| 接口类 | 控制类 | 实体类 |
| PaymentInterface | PaymentProcessor | Payment |
| | PaymentMethod | User |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现支付结算的功能。

支付结算类图如图3-11所示：

图3-11支付结算类图（xxx绘制）

确定用例的行为模型

支付结算用例的顺序图如图3-12所示。

图3-12支付结算用例的顺序图（xxx绘制）

3.2.7 修改商品用例的详细设计

（1）修改商品用例的分析类

A. 接口类/边界类（Boundary Classes）：

W01-ProductList: 商品列表页，展示卖家已上架的商品列表，提供修改商品的入口。

W02-EditProductForm: 商品编辑表单，允许卖家输入或修改商品的信息，如标题、描述、价格等。

W03-ProductPreview: 商品预览页，显示卖家在编辑表单中修改后的商品信息，供卖家确认。

W04-ProductUpdatedConfirmation: 商品修改成功确认页，显示商品已成功修改的消息。

B. 控制类（Controller Classes）：

Edit Product Handler: 商品编辑处理类，负责接收来自商品列表页的修改请求，调用相应的实体类进行商品信息的更新，并处理相关的业务逻辑。

C. 实体类（Entity Classes）：

Product: 商品类，包含商品的唯一标识符（ID）、名称、描述、价格、图片 URL等属性，以及修改商品信息的方法。

ProductImage: 商品图片类（可选），如果平台支持存储图片的详细信息，这个类可以包含图片的URL、大小、格式等属性。

修改商品用例的接口类、控制类、实体类如表3-1所示。

表3-7 修改商品用例的接口类、控制类、实体类（xxx编写）

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过关联、依赖等关系相互连接，共同实现修改商品的功能。

修改商品用例的类图如图3-13所示：

图3-13修改商品用例的类图（xxx绘制）

（2）确定用例的行为模型

修改商品用例的顺序图如图3-14所示。

图3-14修改商品用例的顺序图

3.2.8 搜索商品用例的详细设计

搜索商品用例的分析类

A.接口类：

W01-SearchEntryPage：搜索入口页，提供搜索框供用户输入搜索关键词，并触发搜索请求。

W02-SearchResultPage：搜索结果页，展示根据用户搜索关键词匹配到的商品列表，并提供排序、筛选等交互功能。

W03-ProductDetailPage：商品详情页，当用户从搜索结果页点击某个商品时，展示该商品的详细信息。

B.控制类：

SearchHandler：搜索处理类，负责接收来自W01-SearchEntryPage的搜索请求，调用搜索服务进行商品搜索，并将搜索结果传递给W02-SearchResultPage进行展示。

SearchService：搜索服务类，封装了具体的搜索逻辑，如关键词匹配、排序、筛选等，并返回符合条件的商品列表。

C.实体类：

Product：商品类，包含商品ID、名称、描述、价格、图片URL、卖家ID等属性，以及商品的状态（如上架、下架、已售等）。

SearchResult：搜索结果类，包含搜索到的商品列表（List<Product>）以及可能的分页信息。

SearchCriteria：搜索条件类，封装了用户输入的搜索关键词、排序方式、筛选条件等信息，供SearchService使用。

搜索商品用例的接口类、控制类、实体类如表3-2所示。

表3-8 搜索商品用例的接口类、控制类、实体类（xxx编写）

搜索商品类图如图3-15所示：

图3-15搜索商品用例的类图（xxxz绘制）

确定用例的行为模型

修改商品用例的顺序图如图3-16所示。

图3-16搜索商品用例的顺序图

3.2.9 交易评价用例的详细设计

交易评价用例的分析类

A. 接口类/边界类（Boundary Classes）：

FeedbackInterface: 负责接收用户输入的评价信息，如评价内容、评分等。

DisplayInterface: 负责展示评价提交的结果或错误信息给用户。

B. 控制类（Controller Classes）：

C. 实体类（Entity Classes）：

Transaction: 表示交易的信息，包括交易ID、买卖双方的用户信息等属性，以及相关的 getter 和 setter 方法。

User: 表示用户的信息，如用户名、密码、邮箱等。在交易评价的过程中，需要验证用户的身份。

D. 模型类（Model Classes）：

TransactionRepository: 负责交易信息的存储和验证。它可能提供了 authenticateTransaction(Transaction transaction) 用于验证交易的有效性等方法。

评价交易商品用例的接口类、控制类、实体类如表3-1所示。

表3-9 评价交易用例的接口类、控制类、实体类（xxx编写）

|-------------------|-------------------------------|-------------|
| 接口类 | 控制类 | 实体类 |
| FeedbackInterface | EvaluateTransactionController | Transaction |
| DisplayInterface | FeedbackRepository | User |
| | TransactionRepository | |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现交易评价的功能。

EvaluateTransactionController接收FeedbackInterface 和 DisplayInterface的请求，并调用EvaluateTransactionService接口中的业务逻辑方法，同时 FeedbackRepository 和TransactionRepository实现EvaluateTransactionService接口，FeedbackRepository 和 TransactionRepository又分别依赖于Transaction 与 User ，Transaction 与 User 之间可能存在关联关系，因为多个评价通常与一个用户相关联。

交易评价用例的类图如图3-18所示：

图3-17交易评价类图（xxx绘制）

确定用例的行为模型

评价交易用例的顺序图如图3-19所示。

图3-18评价交易用例的顺序图（xxx绘制）

3.2.10 绑定银行卡用例的详细设计

绑定银行卡用例的分析类

A. 接口类/边界类（Boundary Classes）：

BankInterface：负责接收用户的银行卡信息，如卡号、持卡人姓名、有效期等。

DisplayInterface：负责向用户展示银行卡绑定的结果或错误信息。

B. 控制类（Controller Classes）：

C. 实体类（Entity Classes）：

BankCard：表示银行卡的信息，包括卡号、持卡人姓名、银行名称、有效期等属性，以及相关的 getter 和 setter 方法。

User：表示用户的信息，如用户名、密码、邮箱等。在绑定银行卡的过程中，需要验证用户的身份。

D. 模型类（Model Classes）：

UserRepository：负责用户信息的存储和验证。它可能提供了 authenticateUser(User user) 用于验证用户的有效性等方法。

表3-10绑定银行卡用例的接口类、控制类、实体类（xxx编写）

|------------------|------------------------|-------------|
| 接口类 | 控制类 | 实体类 |
| BankInterface | BindBankCardController | BankCard |
| DisplayInterface | BankCardRepository | User |
| | UserRepository | |

类图中的主要组成部分包括接口类（边界类）、控制类和实体类。这些类之间通过各种关系相互连接，共同实现绑定银行卡的功能。

BindBankCardController接收BankInterface 和 DisplayInterface的请求，并调用BindBankCardService接口中的业务逻辑方法，同时BankCardRepository 和UserRepository实现BindBankCardService接口，BankCardRepository 和 UserRepository又分别依赖于BankCard与User，BankCard与User之间可能存在关联关系，因为多个银行卡通常与一个用户相关联。

绑定银行卡用例的类图如图3-19所示：

图3-19绑定银行卡类图（xxx绘制）

确定用例的行为模型

绑定银行卡用例的顺序图如图3-20所示。

图3-20绑定银行卡用例的顺序图（xxx绘制）

3.3 数据库设计

3.3.1 逻辑结构设计

根据二手交易平台的基本功能，我设计了以下8个表，分别是t_announcement、 t_carousel、t_contact、t_contact_information、t_goods 、t_goods_type、t_message、 t_reserve_record、t_user

1.t_announcement表

t_announcement表如图6-1所示。

t_carousel表

t_carousel表如图6-2所示。

图6-2 t_carousel表图

t_contact表

t_contact表如图6-3所示。

图6-3 t_contact表图

t_contact_information表

t_contact_information表如图6-4所示。

图6-4 t_contact_information表图

t_goods表

t_goods表如图6-5所示。

图6-5 t_goods表图

t_goods_type表

t_goods_type表如图6-5所示。

图6-6 t_goods_type表图

t_message表

t_message表如图6-7所示。

图6-7 t_message表图

t_reserve_record表

t_reserve_record表如图6-8所示。

图6-8 t_reserve_record表图

t_user表

t_user表如图6-9所示。

3.3.2 物理结构设计

CREATE DATABASE `db_secondhandtrade`;

USE `db_secondhandtrade`;

/*Table structure for table `t_announcement` */

DROP TABLE IF EXISTS `t_announcement`;

CREATE TABLE `t_announcement` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`title` varchar(100) DEFAULT NULL COMMENT '标题',

`content` text COMMENT '内容',

`time` datetime DEFAULT NULL COMMENT '发布时间',

`click` int(11) DEFAULT NULL COMMENT '点击数',

`sortNum` int(11) DEFAULT NULL COMMENT '排序',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

/*Data for the table `t_announcement` */

/*Table structure for table `t_carousel` */

DROP TABLE IF EXISTS `t_carousel`;

CREATE TABLE `t_carousel` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`imageName` varchar(100) DEFAULT NULL COMMENT '图片名称',

`title` varchar(100) DEFAULT NULL COMMENT '标题',

`content` varchar(200) DEFAULT NULL COMMENT '描述',

`sortNum` int(11) DEFAULT NULL COMMENT '排列顺序',

`url` varchar(100) DEFAULT NULL COMMENT '链接',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8;

/*Data for the table `t_carousel` */

/*Table structure for table `t_contact` */

DROP TABLE IF EXISTS `t_contact`;

CREATE TABLE `t_contact` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`content` varchar(1000) DEFAULT NULL COMMENT '留言内容',

`reply` varchar(1000) DEFAULT NULL COMMENT '答复',

`time` datetime DEFAULT NULL COMMENT '留言时间',

`userId` int(11) DEFAULT NULL COMMENT '留言用户id（普通用户）',

`userIdReply` int(11) DEFAULT NULL COMMENT '回复用户id（管理员）',

PRIMARY KEY (`id`),

KEY `t_contact_ibfk_1` (`userId`),

CONSTRAINT `t_contact_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8;

/*Data for the table `t_contact` */

/*Table structure for table `t_contact_information` */

DROP TABLE IF EXISTS `t_contact_information`;

CREATE TABLE `t_contact_information` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`name` varchar(100) DEFAULT NULL COMMENT '名称',

`content` varchar(100) DEFAULT NULL COMMENT '内容',

`userId` int(11) DEFAULT NULL COMMENT '用户id',

PRIMARY KEY (`id`),

KEY `t_contact_information_ibfk_1` (`userId`),

CONSTRAINT `t_contact_information_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=utf8;

/*Data for the table `t_contact_information` */

Insert into `t_contact_information`(`id`,`name`,`content`,`userId`) values (1,'QQ','1203007466',56),(2,'微信','ledao303',56),(5,'手机','13667832012',56),(21,'微信','123434243',3),(22,'微信','2a231',2);

/*Table structure for table `t_goods` */

DROP TABLE IF EXISTS `t_goods`;

CREATE TABLE `t_goods` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`name` varchar(100) DEFAULT NULL COMMENT '商品名称',

`content` text COMMENT '商品详情',

`priceNow` decimal(10,0) DEFAULT NULL COMMENT '现在价格',

`priceLast` decimal(10,0) DEFAULT NULL COMMENT '上次价格',

`state` int(11) DEFAULT NULL COMMENT '商品状态,0为未审核,1为上架中,2为审核不通过,3为已下架,4为被预定,5为交易成功',

`reason` varchar(500) DEFAULT NULL COMMENT '审核不通过的理由',

`goodsTypeId` int(11) DEFAULT NULL COMMENT '商品类别id',

`userId` int(11) DEFAULT NULL COMMENT '发布者id',

`addTime` datetime DEFAULT NULL COMMENT '添加时间',

`isRecommend` int(11) DEFAULT NULL COMMENT '是否推荐,0为不推荐(默认),1为推荐',

`recommendTime` datetime DEFAULT NULL COMMENT '推荐时间',

`recommendDays` int(11) DEFAULT NULL COMMENT '推荐天数',

`click` int(11) DEFAULT NULL COMMENT '点击数',

PRIMARY KEY (`id`),

KEY `t_goods_ibfk_1` (`userId`),

KEY `t_goods_ibfk_2` (`goodsTypeId`),

CONSTRAINT `t_goods_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE,

CONSTRAINT `t_goods_ibfk_2` FOREIGN KEY (`goodsTypeId`) REFERENCES `t_goods_type` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=41 DEFAULT CHARSET=utf8;

/*Data for the table `t_goods` */

/*Table structure for table `t_goods_type` */

DROP TABLE IF EXISTS `t_goods_type`;

CREATE TABLE `t_goods_type` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`name` varchar(100) DEFAULT NULL COMMENT '名称',

`sortNum` int(11) DEFAULT NULL COMMENT '排序',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;

/*Data for the table `t_goods_type` */

/*Table structure for table `t_message` */

DROP TABLE IF EXISTS `t_message`;

CREATE TABLE `t_message` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`userId` int(11) DEFAULT NULL COMMENT '接收人id',

`content` varchar(500) DEFAULT NULL COMMENT '内容',

`time` datetime DEFAULT NULL COMMENT '添加时间',

`isRead` int(11) DEFAULT NULL COMMENT '是否已读,0表未读,1表示已读',

PRIMARY KEY (`id`),

KEY `t_message_ibfk_1` (`userId`),

CONSTRAINT `t_message_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=utf8;

/*Data for the table `t_message` */

/*Table structure for table `t_reserve_record` */

DROP TABLE IF EXISTS `t_reserve_record`;

CREATE TABLE `t_reserve_record` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`goodsId` int(11) DEFAULT NULL COMMENT '商品id',

`userId` int(11) DEFAULT NULL COMMENT '支付人id',

`reserveTime` datetime DEFAULT NULL COMMENT '支付时间',

`state` int(11) DEFAULT NULL COMMENT '是否取消,0代表未取消,1代表已取消',

PRIMARY KEY (`id`),

KEY `userId` (`userId`),

KEY `goodsId` (`goodsId`),

CONSTRAINT `t_reserve_record_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `t_user` (`id`) ON DELETE CASCADE,

CONSTRAINT `t_reserve_record_ibfk_2` FOREIGN KEY (`goodsId`) REFERENCES `t_goods` (`id`) ON DELETE CASCADE

) ENGINE=InnoDB AUTO_INCREMENT=37 DEFAULT CHARSET=utf8;

/*Data for the table `t_reserve_record` */

/*Table structure for table `t_user` */

DROP TABLE IF EXISTS `t_user`;

CREATE TABLE `t_user` (

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号',

`userName` varchar(50) DEFAULT NULL COMMENT '用户名',

`password` varchar(50) DEFAULT NULL COMMENT '密码',

`nickName` varchar(50) DEFAULT NULL COMMENT '昵称',

`type` int(11) DEFAULT NULL COMMENT '1代表管理员,2代表普通用户',

`email` varchar(50) DEFAULT NULL COMMENT '邮箱',

`status` int(11) DEFAULT NULL COMMENT '1代表正常,2代表封禁',

`imageName` varchar(50) DEFAULT NULL COMMENT '用户头像图片名',

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=58 DEFAULT CHARSET=utf8;

/*Data for the table `t_user` */

3.4 输入输出设计

3.4.1 界面设计

前台首页详细界面如图3-9所示：

图3-9前台首页界面设计图

后台详细界面如图3-10所示：

3.4.2 报表设计

t_user表如图3-11所示：

图3-11 t_user表图

t_reserve_record表如图3-12所示：

图3-12 t_reserve_record表图

t_message表如图3-13所示：

图3-13 t_message表图

t_goods_type表如图3-14所示：

图3-14 t_goods_type表图

t_goods表如图3-15所示：

图3-15 t_goods表图

t_contact_information表如图3-16所示：

图3-16 t_contact_information表图

t_contact表如图3-17所示：

图3-17 t_contact表图

t_carousel表如图3-18所示：

图3-18 t_carousel表图

t_announcement表如图3-19所示：

图3-19 t_announcement表图

3.4.3 通信接口设计

当不同用户分别从各自设备访问系统时，设备会分别连接串口、网口，并将信息传回系统消息接收接口。通信接口设计如图3-17所示

图3-17通信接口图

3.5 本章小结

本章实现了系统的设计。先绘画软件结构图，包括拓扑结构和软件结构。之后是过程的设计，包括接口的设计和详细设计。之后我们对每一个用例做了分类用例设计类和确定类属性、确定类行为和责任，做用例的设计图。然后是界面的设计，我们设计了各个界面的显示。最后我们完成了数据库的设计包括概念结构设计、逻辑结构设计、物理结构设计。

第四章系统的实现

4.1 用户信息管理模块的实现

登录界面主要功能是以管理员身份登录系统。进入用户管理界面，查看用户列表。选择一个用户，进行修改操作，验证是否成功执行。尝试修改不存在的用户，验证系统是否提示错误信息。添加一个用户，输入用户名、昵称、密码、邮箱。点击删除按钮来删除一个用户输入用户名。点击搜索按钮来查询一个用户登录等以上功能，界面如图4-1所示：

图4-1用户信息管理界面图

4.2 商品管理模块的实现

以用户身份登录系统,登录后自动跳转系统首页，在首页搜索框输入关键字搜索，进入分类页，点击各分类，用户进入商品发布页，输入商品名称、价格，商品详情，选择商品类别，上传图片，点击提交按钮，并顺利跳转我的商品页面。用户进入我的商品页面，在我的商品列表，点击查看详情，用户在我的商品列表，点击修改，任意修改商品数据，点击提交，跳转我的商品列表，并且再次点击商品详情，用户在我的商品列表，点击删除，删除成功。前台商品管理功能界面如图4-2所示：

图4-2前台商品管理界面图

以管理员身份登录系统，管理员进入商品类别管理页，点击添加，输入名称和排序，点击保存，管理员选中某个类别，点击修改，任意修改输入项，点击保存，管理员选中某个类别，点击删除，管理员进入商品管理页，选中某个商品，点击查看，管理员选中某个状态为未审核的商品，点击审核通过。

后台商品管理功能界面如图4-3所示：

图4-3后台商品管理界面图

4.3预定和购物车管理模块功能的实现

以用户身份登录系统。进入购物车页面，查看购物车列表。选择一个商品，进行预定。预定后检验弹出该商品是否成功预定提示。点击取消预订查看是否弹出确认取消提示页面。查看预定信息是否成功变更为预定已取消且操作变为不可操作，以管理员身份登陆系统，进入预定界面管理页面，显示预定商品信息，选择商品后点击查看按钮检验，选择商品后点击删除按钮，查看预定信息是否被删除。

预定管理功能前台界面如图4-3所示：

图4-4预定管理前台界面图

预定管理功能后台界面如图4-4所示：

图4-5 预定管理后台界面图

以用户身份登录系统。进入商品界面，查看商品列表。选择一个商品，进行加入购物车操作，确认是否添加到购物车列表里。以下是购物车功能界面如图4-6所示：

图4-6 购物车功能界面图

4.4留言模块功能的实现

以用户身份登录系统。登录后自动跳转系统首页，在首页点击个人中心，进入个人中心页，点击联系我们，输入留言内容（分别输入正常格式和异常格式），点击提交按钮，以管理员身份登录系统，进入用户联系方式管理页，点击用户留言管理，在用户名搜索框输入用户名关键字，点击搜索，勾选用户留言列表序号的复选框，点击答复，输入对用户留言的答复勾选用户留言列表序号的复选框，点击删除，跳转原页面。

留言管理功能前台界面如图4-7所示：

图4-7留言管理前台界面图

留言管理功能后台界面如图4-8所示：

图4-8留言管理后台台界面图

4.5 本章小结

本章内容主要展现系统的界面样式以及功能的实现，粗略地对每个功能进行大致的讲解，简单介绍了每个功能的大致用法以及实现，以及不同功能在不同情况下的反馈。

第五章系统测试

5.1 测试概要

下表5-1测试概要表列出了对"易物"二手交易平台的每一项测试的标识符及其测试内容，指明了实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，并说明了做出这种改变的原因。

表5-1测试概要表

|-------------------|-------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| 标识符 | 测试内容 | 与测试计划的差别及改变原因 |
| Management-01 | 对购买商品功能进行测试，包括审核用户是否登录、审核是否有添加信息权限、人机交互、对填写数据的核验等功能的测试 | 在实际进行测试过程中发现对填写数据的核验功能上还有很多地方需要增添测试用例因为数据的多样性及不同类型数据的要求不同，测试计划中并没有具体描述 |
| Management-02 | 对下架功能进行测试，包括删除商品、取消删除动作、确定删除动作、删除成功提示等功能的测试 | 在实际进行测试过程中在取消删除功能上增添了测试用例，即当通知信息不同时测试是否均可成功删除相关信息因为测试计划是从管理的角度对测试活动进行规划，但在实际测试中是从技术的角度出发的 |
| Management-03 | 对修改账户信息功能进行测试，包括点击修改按钮信息变成可编辑状态、验证修改数据的有效性、重置、确认修改动作、提示修改成功等功能的测试 | 实际进行的测试工作内容与测试计划中预先设计的内容之间并无差别 |
| UserManagement-01 | 对查看商品信息功能进行测试， | 实际进行的测试工作内容与测试计划中预先设计的内容之间并无差别 |

5.1.1 测试环境

下表5-2测试环境配置表说明了'易物'二手交易平台系统测试需要搭建的测试环境，测试环境中硬件、软件，包括测试工具的配置等内容。

表5-2 测试环境配置图

5.1.2 测试计划

测试计划使测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等。下表 5-3测试计划表确定了测试所需要的时间和资源，以确保其可获得性、有效性。

表5-3 测试计划

|-----------|------------|------------|------------|------------|--------|----------|
| 版本/时间 | 计划开始时间 | 实际开始时间 | 计划结束时间 | 实际结束时间 | 加班 | 增加资源 |
| 用户模块 | 6-18 | 5-18 | 6-19 | 5-19 | 否 | 否 |
| 订单模块 | 6-20 | 5-20 | 6-21 | 5-21 | 否 | 否 |
| 商品模块 | 6-22 | 5-22 | 6-24 | 5-24 | 否 | 否 |
| 留言模块 | 6-25 | 5-25 | 6-25 | 5-25 | 否 | 否 |

5.1.3 测试执行情况

系统测试人员：xxx、xxx、xxx、xxx、xxx

测试时间：2023年5月18日------2023年5月25日

遵循的原则：

（1）测试应尽早进行，最好是能够在需求阶段就开始介入。

（2）负责软件开发的人员应避免检查自己的程序。

（3）设计测试用例既要考虑到合法情况，也要考虑不合法情况。

（5）应长期保留所有测试用例，有助于以后修改程序后进行回归测试。

测试结果：用户模块、商品模块、订单模块和申诉模块与计划相符，测试无错误。

5.2 测试用例

5.2.1 功能性测试

5.2.2 性能性测试

一、性能测试

数据量准备

使用驱动对测试环境进行测试

硬件环境

处理器：英特尔 11th Gen Core i5-11400H @ 2.70GHz 六核

主板：华硕 FX506HCB

内存：16GB(3200 MHz/3200 MHz)

硬盘：512 GB(NVMe HFM512GD3JX013N)

显卡：英伟达 NVIDIA GeForce RTX 3050 Laptop GPU(4096MB)

软件环境

测试指导8.0

测试结果

软件和硬件环境可以完成此测试

二、压力测试

场景1：

内容：在这个场景中，有40个并发用户。同时，使用40个用户来操作客户端访问接口，一个周期一次。

结论：可运行，速度快。

场景2：

内容：在这个场景中，有20个并发用户，持续2小时。

结论：可运行，速度一般。

三、负载测试

场景1：

内容：在这个场景中，有100个并发用户。同时，使用100个用户来操作客户端访问接口，一个周期一次。

结论：软件过载，崩溃。

场景2：

内容：在这个场景中，有20个并发用户，持续2小时。

结论：软件过载，崩溃。

5.2.3 覆盖分析

本次测试对系统需求的覆盖情况为 需求覆盖率=Y（P）项/需求项总数 ×100%=100%

表5-4 覆盖分析

|------------|----------|----------|----------------------|
| 需求 /功能 | 测试类型 | 是否通过 | 备注 |
| 登录/注册 | 功能测试 | 是 | |
| 用户信息管理 | 功能测试 | 是 | 用户个人信息的维护（改、查） |
| 用户商品管理 | 功能测试 | 是 | 用户商品的维护（增、删、改、查） |
| 用户订单管理 | 功能测试 | 是 | 用户交易流程（查询、添加、购买、收货） |
| 用户购物车管理 | 功能测试 | 是 | 用户对个人购物车的维护（增、删、改、查） |
| 管理员留言管理 | 功能测试 | 是 | 管理员处理申诉流程（查询、处理） |

5.2.4 测试用例

用户信息管理测试用例相关详细信息如下表表3-1所示：

表3-1 用户信息管理测试用例（xxx编写）

|--------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
| 条目 | 内容 |
| 测试用例编号 | A001 |
| 功能名称 | 用户模块 |
| 测试日期 | 2024/6/8 |
| 测试人员 | xxx |
| 测试目的 | 确保用户信息的安全、准确和易用性 |
| 前置条件 | 无 |
| 测试步骤 | 1、以管理员身份登录系统。 2、进入用户管理界面，查看用户列表。 3、选择一个用户，进行修改操作，验证是否成功执行。 4、尝试修改不存在的用户，验证系统是否提示错误信息。 5、添加一个用户，输入用户名、昵称、密码、邮箱。 6、点击删除按钮来删除一个用户 7、输入用户名点击搜索按钮来查询一个用户 |
| 预期结果 | 3.1、用户信息修改成功。 3.2、新密码不符合规范，修改失败。 4.1、用户信息错误，修改失败。 5.1、用户添加成功。 5.2、信息不规范，添加失败。 6.1、删除用户成功。 7.1、查询到该用户并显示该用户信息。 7.2、未查询到该用户。 |
| 实际结果 | 3.1、新密码符合规范，用户信息修改成功。 3.2、新密码不符合规范，修改失败。 4.1、用户信息错误，修改失败。 5.1、用户添加成功 5.2、信息不规范，添加失败 6.1、删除用户成功 7.1、显示该用户信息 7.2、未查询到该用户 |
| 结论 | 测试结果与预期结果相符。 |

商品模块相关功能测试用例相关详细信息如下表表3-2所示：

表3-2 商品模块相关功能测试用例（xxx编写）

|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 条目 | 内容 |
| 测试用例编号 | A002 |
| 功能名称 | 商品模块 |
| 测试日期 | 2024/6/12 |
| 测试人员 | xxx |
| 测试目的 | 确保商品模块相关功能的安全、准确和易用性 |
| 前置条件 | 无 |
| 测试步骤 | 1. 以用户身份登录系统 2. 登录后自动跳转系统首页，验证首页是否能正常显示商品列表 3. 在首页搜索框输入关键字搜索，验证是否能够正常显示包含该关键字的商品 4. 进入分类页，点击各分类，验证是否能够分别显示各分类下对应的商品数据 5. 用户进入商品发布页，输入商品名称、价格，商品详情，选择商品类别，上传图片，点击提交按钮，验证商品是否发布成功，并顺利跳转我的商品页面 6. 用户进入我的商品页面，在我的商品列表，点击查看详情，验证是否能够显示商品详细信息（名称、价格、类别、详情/图片） 7. 用户在我的商品列表，点击修改，任意修改商品数据，点击提交，跳转我的商品列表，并且再次点击商品详情，验证是否与修改后的数据一致 8. 用户在我的商品列表，点击删除，验证是否删除成功 9. 以管理员身份登录系统 10. 管理员进入商品类别管理页，点击添加，输入名称和排序，点击保存，验证是否添加类别成功 |
| | 11. 管理员选中某个类别，点击修改，任意修改输入项，点击保存，验证是否修改成功 12. 管理员选中某个类别，点击删除，验证是否删除成功 13. 管理员进入商品管理页，选中某个商品，点击查看，验证是否能够显示该商品详细信息 14. 管理员选中某个状态为未审核的商品，点击审核通过，验证是否审核通过成功 15. 管理员选中某个状态为上架中的商品，点击推荐与否，点击确定，输入推荐天数，点击保存，验证是否推荐成功 16. 管理员选中某个状态为被推荐的商品，点击推荐与否，点击确定，验证是否不推荐成功 17. 管理员选中某个状态为非审核不通过的商品，点击审核不通过，点击确定，输入审核不通过理由，点击保存，验证是否审核不通过成功 18. 管理员选中任意商品，点击删除，验证是否删除成功 |
| 预期结果 | 11.1 商品类别修改成功，提示保存成功，在类别列表显示正确的修改后数据 12.1 删除成功，类别列表不再显示该条类别数据 13.1 成功显示该商品详细信息 14.1 审核通过成功，状态变为已上架 15.1 推荐成功，状态变为被推荐 15.2 推荐天数未填写，提示该输入项为必填项 16.1 提示不推荐成功，状态变为不推荐 17.1审核不通过成功，状态变为审核不通过 17.2 未填写审核不通过理由，提示该输入项为必需项 18.1 商品删除成功，商品列表不再显示该商品 |
| 实际结果 | 2.1商品列表能够正常显示 |
| | 3.1能够正常显示包含该关键字的商品 3.2 没有包含该关键字的商品，显示搜索该关键字的结果有0个，不显示任何商品数据 4.1能够分别显示各分类下对应的商品数据 4.2 该分类下没有数据，显示无数据，不显示任何商品 5.1商品发布成功，并顺利跳转我的商品页面 5.2 商品名称为空，提示必须填写该字段 5.3 商品类别为空，提示必须填写该字段 5.4 商品价格为空，提示必须填写该字段 5.5 商品详情为空，提示必须填写该字段 6.1能够显示商品详细信息（名称、价格、类别、详情/图片） 7.1 用户修改商品成功，与修改后的数据一致 8.1 用户删除商品成功，我的商品列表不再显示该商品 10.1 添加商品类别成功，成功显示到商品列表 10.2 商品类别名称为空，提示该输入项为必需项 10.3 商品类别排序为空，提示该输入项为必需项 11.1 商品类别修改成功，提示保存成功，类别列表显示 12.1 删除成功，类别列表不再显示该条类别数据 13.1 成功显示该商品详细信息 14.1 审核通过成功，状态变为已上架 15.1 推荐成功，状态变为被推荐 15.2 推荐天数未填写，提示该输入项为必填项 16.1 提示不推荐成功，状态变为不推荐 17.1审核不通过成功，状态变为审核不通过 17.2 未填写审核不通过理由，提示该输入项为必需项 18.1 商品删除成功，商品列表不再显示该商品 |
| 结论 | 测试结果与预期结果相符。 |

用户信息管理测试用例相关详细信息如下表表3-4所示：

表3-3 预定管理测试用例（xxx编写）

购物车管理测试用例相关详细信息如下表表3-3所示：

表3-4 购物车管理测试用例（xxx编写）

留言模块相关功能测试用例相关详细信息如下表表3-5所示：

表3-5 留言模块相关功能测试用例（xxx编写）

5.3 测试结果与结论

5.3.1 bug性质及模块分布图

校园二手交易平台系统bug类型及数量具体相关信息如下表5-10所示：

|---------|----|----|----|----|----|
| 模块 | Bug性质 |||||
| 模块 | A类 | B类 | C类 | D类 | 总数 |
| 登陆 | 0 | 1 | 0 | 0 | 1 |
| 注册 | 1 | 1 | 0 | 0 | 2 |
| 用户信息管理 | 1 | 2 | 1 | 0 | 4 |
| 用户商品管理 | 0 | 3 | 1 | 0 | 4 |
| 用户订单管理 | 0 | 0 | 1 | 0 | 1 |
| 管理员申诉管理 | 1 | 1 | 0 | 0 | 2 |

表5-10 bug类型及数量

软件测试合格须符合以下标准：

表5-11 测试合格标准

|------|------|
| 错误类型 | 合格标准 |
| A类错误 | 无 |
| B类错误 | 无 |
| C类错误 | <1% |
| D类错误 | <5% |

5.3.2 功能

系统正确实现了通过数据字典管理基础数据的功能，实现了基础数据管理，用户信息管理、商品信息管理、订单信息管理、购物车管理、申诉信息管理。

5.3.3 易用性

现有系统实现了如下易用性：查询，添加，删除，修改操作相关提示信息的一致性，可理解性；输入限制的正确性；输入限制提示信息的正确性，可理解性，一致性

现有系统存在如下易用性缺陷：界面排版不美观；输入，输出字段的可理解性差；输入缺少解释性说明

5.3.4 可靠性

目前的系统在可靠性方面存在一些不足，特别是在控制机制的实施上不够严密。许多关键的控制功能依赖于页面逻辑，倘若这些页面控制出现故障，就可能允许未经授权的数据直接插入数据库，这种情况可能导致严重的系统错误或数据不一致问题。

此外，系统在容错性方面的表现也不尽如人意。当系统遇到错误时，通常会返回"找不到页面"的错误提示，这种处理方式过于简单，并没有提供足够的错误信息，也未能提供恢复到出错前状态的功能。用户和管理员因此难以快速定位问题或进行有效的错误恢复，影响了系统的稳定性和用户的信任度。

为了提升系统的可靠性与健壮性，需要对现有的控制措施进行深入的审查和改进。我们应当实现多层防御策略，确保关键操作有更为严格的验证过程，并引入异常监测机制来预防和识别潜在的问题。同时，提高系统的容错能力也至关重要，设计更为详尽的错误处理流程，确保在出现错误时能够保留现场状态，提供详细的错误信息，并支持回滚到安全状态，从而保障系统的连续运行和数据的完整性。这些措施的实施将极大地增强系统应对各种突发状况的能力，提升整体的稳定性和用户满意度。

5.3.5 兼容性

现有系统支持Windows下的Edge浏览器和火狐浏览器。现有系统未进行其他兼容性测试。

5.3.6安全性

目前，系统已经妥善处理了以下安全性问题：

系统对用户名和密码的验证过程中，已经实现了对大小写的敏感性，从而增强了账户安全性。

不过，还有几项安全性问题尚未得到控制，这些包括：

（1）尚未设置登录错误次数限制。为了防止暴力破解攻击，系统应设定连续登录失败的次数上限，在达到该限制后进行账户锁定或采取其他安全措施。

（2）缺少对已登录页面的安全保护。如果用户在登录后将页面保存下来，目前的系统允许脱离登录状态单独操作这些页面，这可能会被恶意利用，因此需要确保即便保存下来的页面也不能绕过登录验证。

（3）未对直接输入Url访问进行限制。用户能够直接通过输入页面的Url来访问特定页面并进行操作，这一行为应当被限制以确保所有页面的访问都在正确的身份验证之后。

5.3.7 改进建议

（1）在项目启动初期，制定一系列标准是至关重要的。这包括编码规范、数据库设计准则以及需求变更流程等。开发和测试团队必须严格按照这些预先设定的标准执行工作。这一做法可以有效减少项目后期由于开发与测试不一致产生的问题，同时也能显著降低团队间的沟通成本，确保信息的准确传递和理解。

（2）当发布新的软件版本时，配置一个准确的测试环境显得尤为重要。这样做可以减少由于测试环境配置不当或测试数据库中的数据问题而引发的非真实bug。一个干净、准确、与生产环境相似的测试环境，能够更有效地模拟真实的用户场景，从而提升测试结果的可靠性。

（3）开发人员在解决bug的过程中，应当养成记录bug产生原因及解决方法的习惯。这不仅有助于当前问题的追踪，还能为未来可能出现的类似问题提供参考。通过详细记录，团队成员可以更快地定位问题，加速问题的解决进程。

（4）开发人员在对开发中的软件版本进行自测时，一旦发现bug，应立刻通知测试人员。因为开发员发现的bug很可能也会在测试版本中出现。此外，由于测试人员与开发人员在思考问题时的角度不同，可能存在测试人员未能发现的bug。这种及时的沟通协作机制，可以确保所有已识别的bug得到妥善处理和跟踪，进一步提升软件质量。

5.4 本章小结

本章着重于系统测试的实现，详细介绍了所搭建的测试环境、制定的测试计划，以及测试的执行过程和测试用例的设计。为了确保系统的各方面性能符合预期，我们的测试用例涵盖了多个维度。在功能性测试方面，我们细致地对每一个功能点进行了验证，确保每个功能都能正常工作，从而保障用户在使用过程中能够享受到顺畅和愉悦的体验。通过这样全面而严谨的测试流程，我们能够及时发现并解决潜在的问题，确保软件产品的质量达到最高标准。

总结

本文主要对之前四个文档进行总结，讲述了校园二手交易平台的主要的结构设计模型，包括国内外研究现状。系统的功能需求，利用系统事件表、用例图、用例描述、顺序图、活动图、类图等做了详细的说明和分析。系统软件设计这章主要讲述了系统的详细设计，包括系统的部署图、顺序图等，最后对数据库中所需要的表和表中的数据给出了具体的描述，并大概的描述了表之间的关联。系统软件实现这章主要展示了系统的前台和后台的布局样式，粗略地介绍了每个功能模块的页面内容分布和基本的实现方法。最后软件测试主要为系统实现测试功能，用户登录操作、用户创建订单操作部分进行了测试。

虽然进行了系统开发所需要的分析，但这些分析对于一个完善的网站系统来说还远远不足，并且本系统的各章节设计中仍存在着许多的不足和改进之处。本系统的整体设计需要进一步的完善，功能上只是完成了所需的最低功能，所以在系统功能上还需要不断增加。

参考文献

$1$ 黄锦川,金炜东.基于Android平台Web服务的应用研究 $J$ .铁路计算机应用.2010,19(11):1-7．

$2$ 佟立洲,牛阮霞,李青.

基于WEB系统的设计与实现
$J$ . 东方企业文化. 2013(23):7.

$3$ 韩思凡,Web开发中的JSP与H T ML的基础应用 $J$ .科学技术创新,2020(14):8.

$4$ 宫垂刚,韦一,张华丰.项目开发完全自学手册 $M$ .北京:机械工业出版社,2009:121--129:9-19.

$5$ 吴亚峰,索伊娜等.Android核心技术与实例讲解 $M$ .北京:北京工业出版社,2010:4-10．

$6$ 黄进华.J2EE平台基于Web Services的企业应用集成技术研究 $D$ .青岛大学,2006:12-13．

$7$ 徐涛编.深入理解JavaScript $M$ .北京:机械工业出版社,2010:38.

致谢

经过几个月的忙碌和工作，本次软件工程专业综合实验课程已经接近尾声，作为一个本科生的专业实践课程设计，由于我们的经验的匮乏，专业知识不够，难免有许多考虑不周全的地方。在整个系统的设计与实现过程中，特别感谢青巴图老师以及王楠老师耐心的帮助和悉心的指导。每当我们在设计与撰写中遇到无法解决的问题时，都是向老师耐心细致地为我们讲解，帮助我们走出各种误区，并给予我们极大的鼓励和支持。如果没有老师的督促指导，以及小组成员的团结协作，我们的系统设计的质量必然会有所下降。其次要感谢我们组的每位成员，感谢他们提出的宝贵意见和建议和在系统设计和实现中付出的努力，正是因为每位小组成员的付出本次课程设计才能圆满完成。

若觉得有帮助，欢迎点赞关注，一起成长进步~
声明：本文仅供学习交流，禁作商用；禁篡改、歪曲及有偿传播，引用需标明来源。侵权必究。

软件工程综合实践3实验报告——校园二手交易平台系统（黑龙江大学）

实验一 项目开发计划说明书

1 引言

1.1 编写目的

1.2 背景

1.3 定义

1.4 参考资料

2 项目概述

2.1 工作内容

2.2 主要参加人员

2.3 产品

2.3.1 程序

2.3.2 文件

2.3.3 服务

2.3.4 非移交的产品

2.4 验收标准

2.5 完成项目的最迟期限

2.6 本计划的批准者和批准日期

3 实施计划

3.1 工作任务的分解与人员分工

3.2 接口人员

3.3 进度

3.4 预算

3.5 关键问题

4 支持条件

4.1 计算机系统支持

4.2 需由用户承担的工作

5 专题计划要点

5.1 人员培训计划

6 可行性分析

6 .1 项目意向：

6 .2 政策支持：

6 .3 二手交易市场行业发展现状：

6 .4 服务对象：

6 .5 关键性问题

6 .6 解决方法

6 .7 厂址

6 .8 项目进度

6 .9 主要成本

6 .10 团队规模

6 .11 项目建设必要性

6 .12 项目的生命周期

6 .13 资金

6 .14 资金来源

实验二 需求规格说明书

1 文档简介

1.1 文档目的

1.2 背景

1.3 参考资料

1.4 术语与缩写解释

2 系统产品介绍

2.1 项目来源与目标

2.2 系统（或用户）的特点

2.3系统需要解决的主要问题

3 产品的功能性需求

3.1 确定业务参与者

3. 2 用例模型描述

3. 2 .1建立系统上下文用例模型

3. 2 .2 用例词汇表

3. 2 .3系统用例模型图

3. 2 .4 用例描述

3. 3 概念模型分析

4 产品的非功能需求

4.1 质量需求

4.1.1 精度

4.1.2 时间特性要求

4.1.3 灵活性

4. 2 故障处理要求

4. 3 其他专门要求

5 运行环境规定

5.1 开发环境

5.2 运行环境

实验三 系统设计说明书

1 系统概况

1.1 项目背景

1.2 当前应用现状

1.3 系统建设的意义

1.4 系统建设的初步构想

2. 系统设计

2.1 系统环境与平台

实验一项目开发计划说明书

实验二需求规格说明书

实验三系统设计说明书

实验四系统测试报告

实验五综合实践总结报告

第一章绪论

第二章需求分析