二手市场
1 系统分析
1.1 需求分析
项目背景
国内最大的二手服务商“易趣、淘宝”其注册用户有 61% 为在校大学生，其他占 25% 为社会人士注册，他们每年与学生的交易量占总交易量的 85% 以上.
“易淘”均不向交易双方任何用户提供商品质保和售后服务，所有 89% 的商品一经售出，一概不理，他们最大的弊端在于交易期的漫长等待互相信任度低，不提供对而售商品的技术鉴定和评估，让买方始终不放心，优点：规模大，先入市场，利用完善的电子商务网络交易，成本低廉，对商品的详细信息把握到位有一定的透明度。
鉴于“同一周期内，大学里学生需求有相似性与差异性，对而售商品需求日益旺盛，一些商品耐用性强，一部分大学生为减轻家庭负担，宁愿购买二手，校内交易可信性高，方便廉价无欺。“大四毕业生大多在忙于找工作，离家远东西托运不方便，不愿意浪费时间亲自处理自己带不走的东西,目前高校内部交易混乱各自位为政，甚至互相压榨坑害自己同学，另一面针对大学生提供专门的服务的市场在中国还是一片空白，潜力巨大在校学生生活单调，精神心理空虚不振等日益暴露，大四出去找工作，要面临好多困难，往往四处碰壁心灰意冷甚至自寻短见，即使找到一般的工作也会有住房对当地不熟安全等一系列社会问题发生而无助，迫切需要一个全国性的大学生组织帮他们一把！
需求说明
1） 身份认证就是新卖家与买家需通过注册验证身份，老用户需要登入账号密码验证身份才可进行其他功能操作。
2） 卖家身份认证后可以进行商品发布；商品发布就是可以对自己需要售出的商品进行标价、分类、传图、描述等。
3） 价格协商就是买卖家可以在交易前进行沟通，沟通后卖家可以对商品修改价格。
4） 投诉就是卖家或者买家对之间的交易不满意，可以对此订单进行投诉。
5） 客服需要对产生的投诉进行处理，处理后对交易进行仲裁。
6） 管理员需要发布公告提示用户系统的更变或者一些事情，对买卖家之间产生的交易进行审查，审查交易是否正常，是否构成违法行为。
业务规则
1） 买卖家的身份认证是需满 16 周岁
2） 商品的交易构成至少有一个商品存在
3） 商品的发布需要符合法律，不能发布违法商品
4） 每个交易都需要通过管理员审查
5） 买卖家需要通过身份认证登入才可进行交易
6） 交易商品数量不能大于卖家售卖的数量
7） 投诉需在交易构成存在的前提下
8） 交易后不能对价格商议
9） 客服的交易处理前提需要有交易投诉存在
1.2 用例分析与描述
1.2.1 用例分析
管理员
查看公告：管理员可以查看自己已经发布的公告信息。
发布公告：管理员可发布公告，所有用户可接收到公告。
升级用户身份：买家想要升级为卖家的时候，管理员可审核并决定是否将之升级。
交易审查：管理员可以在后台审查所有交易记录。
指定客服：管理员可以指定客服。
后台登陆：管理员可通过身份验证在后台登陆。
修改密码：管理员可以修改自己的登陆密码；
图 1 管理员用例图
客服
更改商品交易状态：客服审查商品交易侵权行为时，可以修改商品交易状态（1.成功，2.退款交易关闭）。
交易仲裁：出现交易纠纷的时候，由客服仲裁交易结果。
投诉处理：客服可以处理由卖家，买家用户提出的投诉。
修改密码：客服可以修改自己的登陆密码；
图 2 客服用例图
买家
申请升级：买家可通过提交申请升级为卖家。
购买商品：买家可在线购买想要的商品。
价格协商：买家可与想要买的商品所属的卖家联系协商商品价格。
投诉：买家可向平台提交投诉，客服可看到投诉。
查看公告：买家可以查看管理员发布的公告。
浏览商品：买家可以在平台上浏览所有已上架商品；
图 3 买家用例图
卖家
价格协商：卖家可与买家协商商品价格；也可以作为买家与其他卖家进行协商；
投诉：卖家可提交投诉；
购买商品：卖家可在线购买想要的商品；
查看公告：卖家可以查看管理员发布的公告。
浏览商品：卖家可以在平台上浏览所有已上架商品；
图 4 卖家用例图
1.2.2 用例描述
管理员：
| 用例编号 | A01 |
| 用例名称 | 查看公告 |
| 简要说明 | 管理员可以查看自己已经发布的公告信息 |
| 执行者 | 管理员 |
| 前置条件 | 以管理员身份登录 |
| 后置条件 | 查询到公告信息 |
| 基本事件流 | 1. 以管理员身份登录 2. 查看公告 3. 退出 |
| 扩展事件流 | 1.查询不到公告 |
| 用例编号 | A02 |
| 用例名称 | 发布公告 |
| 简要说明 | 管理员可发布公告，所有用户可接收到公告 |
| 执行者 | 管理员 |
| 前置条件 | 以管理员身份登录 |
| 后置条件 | 成功发布公告，并且用户可接收到 |
| 基本事件流 | 1.以管理员身份登录 2.发布公告 3.退出 |
| 扩展事件流 | 1.发布公告失败 |
| 用例编号 | A03 |
| 用例名称 | 升级用户身份 |
| 简要说明 | 买家想要升级为卖家的时候，管理员可审核并决定是否将之升级 |
| 执行者 | 管理员 |
| 前置条件 | 1. 以管理员身份登录 2. 买家提交请求 |
| 后置条件 | 1. 管理员升级用户身份 2. 管理员拒绝升级用户身份 |
| 基本事件流 | 1. 以管理员身份登录 2. 管理员升级用户身份 3. 退出 |
| 扩展事件流 | 1.用户不存在 |
| 用例编号 | A04 |
| 用例名称 | 交易审查 |
| 简要说明 | 管理员在后台审查所有交易记录 |
| 执行者 | 管理员 |
| 前置条件 | 1.以管理员身份登录 |
| 后置条件 | 管理员审查到所有交易记录 |
| 基本事件流 | 1. 以管理员身份登录 2. 管理员审查所有交易记录 |
| 扩展事件流 | 1.交易记录为 null |
| 用例编号 | A05 |
| 用例名称 | 指定客服 |
| 简要说明 | 管理员指定客服 |
| 执行者 | 管理员 |
| 前置条件 | 1. 以管理员身份登录 2. 用户请求客服 |
| 后置条件 | 管理员为用户指定客服 |
| 基本事件流 | 1. 以管理员身份登录 2. 管理员为用户指定客服 3. 退出 |
| 扩展事件流 | 能指定客服为 null |
| 用例编号 | A06 |
| 用例名称 | 后台登陆 |
| 简要说明 | 管理员通过身份验证在后台登陆 |
| 执行者 | 管理员 |
| 前置条件 | 1. 身份存在 2. 账户密码输入正确 |
| 后置条件 | 成功登陆 |
| 基本事件流 | 1.输入账号密码 2 验证密码 3 登陆 4.退出 |
| 扩展事件流 | 1.账号密码输入错误 |
| 用例编号 | A07 |
| 用例名称 | 修改密码 |
| 简要说明 | 管理员修改自己的登陆密码 |
| 执行者 | 管理员 |
| 前置条件 | 1.以管理员身份登录 |
| 后置条件 | 成功修改密码 |
| 基本事件流 | 1.输入账号密码 2 验证密码 3 登陆 3. 修改密码 4. 退出 |
| 扩展事件流 | 1.账号密码输入错误 |
客服：
| 用例编号 | S01 |
| 用例名称 | 更改商品交易状态 |
| 简要说明 | 客服审查商品交易侵权行为时，可以修改商品交易状态（1.成功，2.退款交易关闭）。 |
| 执行者 | 客服 |
| 前置条件 | 1. 以客服身份登录 2. 审查商品有交易侵权行为 |
| 后置条件 | 修改商品交易状态 |
| 基本事件流 | 1 以客服身份登录查看公告 2 修改商品交易状态 3 退出 |
| 扩展事件流 | 1.查询不到商品 |
| 用例编号 | S02 |
| 用例名称 | 交易仲裁 |
| 简要说明 | 出现交易纠纷的时候，由客服仲裁交易结果。 |
| 执行者 | 客服 |
| 前置条件 | 1. 以客服身份登录 2. 出现交易纠纷 |
| 后置条件 | 成功发布公告，并且用户可接收到 |
| 基本事件流 | 1.1.以客服身份登录 2.客服仲裁交易结果。3.退出 |
| 扩展事件流 |
| 用例编号 | S03 |
| 用例名称 | 投诉处理 |
| 简要说明 | 客服可以处理由卖家，买家用户提出的投诉。 |
| 执行者 | 客服 |
| 前置条件 | 1 以客服身份登录 2 买家用户提出投诉 |
| 后置条件 | 客服处理买家用户提出的投诉。 |
| 基本事件流 | 1. 以客服身份登录 2. 买家用户提出投诉 3. 客服处理买家用户提出的投诉 4. 退出 |
| 扩展事件流 | 登陆失败 |
| 用例编号 | S04 |
| 用例名称 | 修改密码 |
| 简要说明 | 客服修改自己的登陆密码 |
| 执行者 | 客服 |
| 前置条件 | 以客服身份登录 |
| 后置条件 | 成功修改密码 |
| 基本事件流 | 1.输入账号密码 2 验证密码 3 登陆 5. 修改密码 6. 退出 |
| 扩展事件流 | 账号密码输入错误 |
| 用例编号 | UB01 |
| 用例名称 | 申请升级 |
| 简要说明 | 买家通过提交申请升级为卖家。 |
| 执行者 | 买家 |
| 前置条件 | 1.以买家身份登录 |
| 后置条件 | 提交申请升级为卖家 |
| 基本事件流 | 1. 以买家身份登录 2. 提交申请升级为卖家 3. 退出 |
| 扩展事件流 | 申请被拒 |
| 用例编号 | UB02 |
| 用例名称 | 购买商品 |
| 简要说明 | 买家可在线购买想要的商品。 |
| 执行者 | 买家 |
| 前置条件 | 1.以买家身份登录 |
| 后置条件 | 购买到想要的商品 |
| 基本事件流 | 1. 以买家身份登录 2. 购买到想要的商品 3. 付款 4. 退出 |
| 扩展事件流 | 付款失败 |
| 用例编号 | UB03 |
| 用例名称 | 价格协商 |
| 简要说明 | 买家可与想要买的商品所属的卖家联系协商商品价格。 |
| 执行者 | 买家 |
| 前置条件 | 1. 以买家身份登录 2. 商品存在 |
| 后置条件 | 买家成功与想要买的商品所属的卖家联系协商商品价格 |
| 基本事件流 | 1 以买家身份登录 2 与想要买的商品所属的卖家联系协商商品价格 3 付款 4 退出 |
| 扩展事件流 | 协商失败 |
| 用例编号 | UB04 |
| 用例名称 | 投诉 |
| 简要说明 | 买家可向平台提交投诉，客服可看到投诉。 |
| 执行者 | 买家 |
| 前置条件 | 1 以买家身份登录 2 买家提交投诉 |
| 后置条件 | 买家成功向平台提交投诉，客服看到投诉 |
| 基本事件流 | 1 以买家身份登录 2 买家成功向平台提交投诉 3 客服看到投诉 4 退出 |
| 扩展事件流 | 1 登陆失败 2.无买家提交投诉 |
| 用例编号 | UB05 |
| 用例名称 | 查看公告 |
| 简要说明 | 买家可以查看管理员发布的公告 |
| 执行者 | 买家 |
| 前置条件 | 1 以买家身份登录 |
| 后置条件 | 买家查看管理员发布的公告 |
| 基本事件流 | 1 以买家身份登录 2 查看管理员发布的公告 3 退出 |
| 扩展事件流 | 无公告发布 |
| 用例编号 | UB06 |
| 用例名称 | 浏览商品 |
| 简要说明 | 买家可以在平台上浏览所有已上架商品 |
| 执行者 | 买家 |
| 前置条件 | 以买家身份登录 |
| 后置条件 | 买家在平台上浏览所有已上架商品； |
| 基本事件流 | 1 以买家身份登录 2 浏览所有已上架商品 3 退出 |
| 扩展事件流 | 登陆失败 |
| 用例编号 | US01 |
| 用例名称 | 价格协商 |
| 简要说明 | 卖家可与买家协商商品价格；也可以作为买家与其他卖家进行协商 |
| 执行者 | 卖家或买家 |
| 前置条件 | 以买家或卖家身份登录 |
| 后置条件 | 协商商品价格 |
| 基本事件流 | 1 以买家或卖家身份登录 2 协商商品价格 3 付款 4 退出 |
| 扩展事件流 | 1.登陆失败 2.协商价格失败 |
| 用例编号 | US02 |
| 用例名称 | 投诉 |
| 简要说明 | 卖家可提交投诉 |
| 执行者 | 卖家 |
| 前置条件 | 以卖家身份登录 |
| 后置条件 | 提交投诉 |
| 基本事件流 | 1 卖家身份登录 2 提交投诉 3 退出 |
| 扩展事件流 | 登陆失败 |
| 用例编号 | US03 |
| 用例名称 | 购买商品 |
| 简要说明 | 卖家可在线购买想要的商品 |
| 执行者 | 卖家 |
| 前置条件 | 以卖家身份登录 |
| 后置条件 | 可购买想要的商品 |
| 基本事件流 | 1 卖家身份登录 2 购买想要的商品 3 退出 |
| 扩展事件流 | 登录失败 |
| 用例编号 | SU04 |
| 用例名称 | 查看公告 |
| 简要说明 | 卖家可以查看管理员发布的公告。 |
| 执行者 | 卖家 |
| 前置条件 | 以卖家身份登录 |
| 后置条件 | 查看管理员发布的公告 |
| 基本事件流 | 1 卖家身份登录 2 查看管理员发布的公告 3 退出 |
| 扩展事件流 | 无公告发布 |
| 用例编号 | SU05 |
| 用例名称 | 浏览商品 |
| 简要说明 | 卖家可以在平台上浏览所有已上架商品。 |
| 执行者 | 卖家 |
| 前置条件 | 以卖家身份登录 |
| 后置条件 | 在平台上浏览所有已上架商品 |
| 基本事件流 | 1 卖家身份登录 2 在平台上浏览所有已上架商品 3 退出 |
| 扩展事件流 | 登录失败 |
2 系统设计
2.1 多层结构设计
项目整体采用的是 Springboot+Gradle+Mybatis+templeaf 框架构建项目，数据库采用的是 MySQL 5.7。
controller 控制层：主要负责逻辑处理和页面请求，接收数据并处理再返回视图层，运用了 Spring Boot 技术。
dao 服务层：主要是连接数据库，处理对数据库的请求，运用了 MyBatis 技术。
entity 实体层：主要是映射数据库，对数据库的表数据一一对应，通过 MyBatis 业务持久层。
Service 接口层：存放业务逻辑处理，也是一些关于数据库处理的操作
util 工具类层：主要是一些公共调用的方法，比如图形验证码
lib 包含的是一些外置导入的 jar 包
mappers 里面是 MyBatis 的映射文件，主要是存放数据库操作语句
static 里面包含项目界面回应用到的静态资源
templates 存放的是所有的动态页面
图 2.1 校园二手平台系统组件图
2.2 问题域设计
2.2.1 域模型设计
对于校园二手平台来说，最常见的角色莫过于是买家和卖家，所以它们也都是从需求描述中识别出来的实体。对于购买商品就会有商品和订单两个实体，还有卖家买家都可以投诉，所以就会有投诉单这个实体。后台系统由管理员和客服两个实体构成。
图 2.2 校园二手平台域模型
2.2.2 Service 接口设计
图 2.2 校园二手平台系统接口类图
2.3 持久化设计
2.3.1 数据库设计
数据库类型为关系数据库
管理员表格
客服表格
买家表格
卖家表格
商品表格
订单表格
投诉表格
公告表格
2.3.2 数据访问设计
数据库配置：
spring.datasource.druid.url=jdbc:mysql://localhost:3306/forsale?useUnicode=true&characterEncoding=UTF-8&allowMultiQueries=true&useSSL=false&serverTimezone=GMT%2B8&allowPublicKeyRetrieval=true
spring.datasource.druid.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.druid.username=root
spring.datasource.druid.password=162041MyBatis 的真正强大在于它的映射语句，这是它的魔力所在。由于它的异常强大，映射器的 XML 文件就显得相对简单。如果拿它跟具有相同功能的 JDBC 代码进行对比，你会立即发现省掉了将近 95% 的代码。MyBatis 为聚焦于 SQL 而构建，以尽可能地为你减少麻烦。所以我们没有使用 repository 类，使用的是 XML 映射文件。
2.4 界面设计
2.4.1 页面链接关系
表 2.1 URL 对应功能说明（pets）
| HTTP verb | URL | action | used for |
| POST | /pets/new | add | return an HTML form for creating a new pet |
| POST | /pets/new | create | create a new pet |
| POST | /pets/1/edit | edit | return an HTML form for editing a pet |
| POST | /pets/1/edit | update | update a specific pet |
模型如下图所示
图 2.2 校园二手平台系统页面跳转模型
2.4.2 页面设计
首页
游客首页
个人信息信息界面
发布商品界面
遍历商品
商品详情
管理员登录
客服登录
管理员界面
客服界面
![[数据结构]排序之 归并排序（有详细的递归图解）](https://i-blog.csdnimg.cn/direct/6b5fec2a539d45adbd53451e5705fed9.png)
![[贪心算法]买卖股票的最佳时机 买卖股票的最佳时机Ⅱ K次取反后最大化的数组和 按身高排序 优势洗牌（田忌赛马）](https://i-blog.csdnimg.cn/direct/df8b476b697e433f8778c2d7ea1ea0c6.png)
