南斗六星-系统设计

需求的改进

从同学中得到的建议

1. 浏览书籍的时候没有图片，导致筛选出自己心仪的书籍很麻烦
2. 每页只有十本书，每次刷完十本都要点击下一页好麻烦
3. 每次只能卖一本书，但我有一大堆书，一本一本上传好麻烦
4. 访问网站要输入IP地址，我记不住

改进策略

（1）关于书籍的图片，我们可以租用阿里云的对象存储OSS服务来提供，但这笔花销该不该花，值不值得花对我们来说是个问题。毕竟我们只是在做一个作业，并不是在搞未来能赚钱的商业项目。
（2）我们会努力学习前端的相关知识，争取做出像淘宝那样的无限刷新的页面
（3）将来会上线批量上传的功能的
（4）解决IP地址的问题需要申请域名，这方面我们也没太好的办法。如果我们当初做的是微信小程序也许就不用烦恼这个问题了。

综上，我们团队暂时有机会解决的只有（2）和（3），其他要花钱的和涉及到一些互联网管理的内容我们暂时不去了解。

卖家的User Story

以卖家的视角来看，应该是这样子来描述的：

我的书已经堆满整个书架了，都是些现在用不着、未来不知道能不能用着的书，真想把这些书卖了。但是，我又没有在网络上卖过东西，这样子的书要一本本的发快递发出去感觉好麻烦。而且我也没寄过快递，要跟快递工作人员打交道感觉好麻烦。算了还是不卖了，就那几个钱，直接把书扔垃圾桶算了，让收拾垃圾的阿姨大叔捡去卖算了。

网站潜在的卖家就是这样子想的，因为怕麻烦所以干脆不卖，反正也值不了几个钱。改变他观念的方法有两种：

1. 让他觉得手上的东西值很多
2. 让他觉得卖出去好像也没有想象中的麻烦

我们试图采用第二种方法，让卖家将手中的书籍交给我们的平台来处理

我们可以采用线上生成订单，线下处理订单的方式来运行。卖家只需要将书籍运送到指定地点，打包好，我们就会派工作人员处理这些书。

买家的User Story

以买家的视角来看，应该是这样子来描述的：

学校的教材怎么那么贵？我一个学期基本上不怎么用这些书，就在考试前几天用，却要用这么多钱来买也太亏了。

基于买家的这种心理，只要我们能够提供相对低廉的价格的书籍、教材，买家就会心动。这也解释了为什么我们在改变卖家观念的时候选择第二种方法，因为第一种方法势必会导致书籍的价格上涨，最终导致买家的流失。

系统设计

架构设计

本次团队项目采用开发框架式SSM（Spring + SpringMVC + Mybatis）

系统采用三层体系结构，分别是：

1. 表示层
2. WEB应用层
3. 数据层

利用SpringBoot进行项目的后端开发，前端使用React框架来开发

工作架构大概是这样的：

从买家的角度来看，系统应该是这样工作的：

从卖家的角度来看，系统应该是这样工作的：

在我们的预想中，买家对待售书籍只能预订，而不能真正的成功购买。买家一旦进行预订，卖家的后台就会出现买家对待售书籍的订单，同一本待售书籍可能会对应多个订单，卖家决定卖给谁，就由买卖双方通过聊天协商决定。

数据库设计

create table user
(
    id int unsigned primary key auto_increment comment '用户ID',
    username varchar(20) not null comment '用户名',
    password varchar(50) not null comment '密码',
    nickname varchar(20) default '' comment '昵称',
    email varchar(128) default '' comment '邮箱',
    user_img varchar(128) default '' null comment '头像',
    update_time date not null comment '更新时间',
    create_time date not null comment '创建时间',
    power tinyint not null default 1 comment '权限'
)default character set utf8mb4 comment '用户表';

由于用户头像的使用到的存储空间是不定的，一般不将用户头像存储在数据库中，所以将用户头像定义成一个URL，这样未来租用阿里云的对象存储服务OSS就可以用URL加载头像。

另外，我们的二手交易平台最终不仅仅要有普通的用户，还会有管理员用户来管理平台的运行。所以用户之间会有权限的差异，所以定义管理权限字段。

书籍表单设计

我们打算做书籍分类功能，所以需要一个记录书籍分类的表单

create table book_type
(
    id int unsigned primary key auto_increment comment '类别ID',
    name varchar(20) not null comment '类别名'
)default character set utf8mb4 comment '书籍类别';

关于待售书籍，我们设计这样一个表单来存储信息：

create table book
(
    id int unsigned primary key auto_increment comment '书籍ID',
    name varchar(50) not null comment '书籍名称',
    type_id int unsigned not null comment '类别',
    price decimal(12, 2) not null comment '价格',
    isbn varchar(20) not null comment 'ISBN号',
    img varchar(128) null comment '头像',
    detail varchar(500) default '' null comment '书籍描述',
    release_time date not null comment '上架时间',
    seller_id int unsigned not null comment '卖家ID',
    purchased int not null comment '是否已被购买',
)default character set utf8mb4 comment '待售书籍';

平台只负责管理待售的书籍，而不会试图去管理用户不再想要售卖的书籍或者已经卖出去的商品，所以需要 purchased 字段来标识。但这样子就是说，用户每挂售一个书籍，就只支持一次交易，这样做是考虑到我们面向的个人卖家和个人买家，而不是专门面向二手书售卖商。

订单表单设计

create table `order`
(
    id int unsigned primary key auto_increment comment '订单ID',
    user_id int unsigned not null comment '用户ID',
    book_id int unsigned not null comment '书籍ID',
    pay_time date not null comment '下单时间',
    address varchar(100) not null comment '收货地址',
    status tinyint not null comment '订单状态',
)default character set utf8mb4 comment '订单';

买家管理自己买某些书的意愿

卖家可以查看自己卖了哪些书，并可以查看有哪些人希望买这本书。

卖家通过书籍ID去查找买家；买家可以通过用户ID查看自己想要买哪些书。

聊天记录表单设计

create table `connection`
(
    id int unsigned primary key auto_increment comment '连接ID',
    user1_id int unsigned not null comment '用户1的ID',
    user2_id int unsigned not null comment '用户2的ID'
)default character set utf8mb4 comment '聊天连接';

create table `record`
(
    connect_id int unsigned not null unique,
    sender_id int unsigned not null comment '发送方ID',
    reciever_id int unsigned not null comment '接收方ID',
    number int unsigned auto_increment comment '记录编号',
    type int unsigned not null default 1 comment '记录类型',
    content varchar(150) not null comment '记录'
)default character set utf8mb4 comment '聊天记录';

接收方ID和发送方ID来自于connection表单中的用户1的ID或用户2的ID。

也就说，在一个连接中，一个用户要么是发送方要么是接收方。

而number编号，是用来表示发送的顺序的，也就是说编号越小发送得越早。

type是用来解释记录中存储的内容的，比如我们可以这样子规定：

1. type=1：content为文字记录
2. type=2：content为图片URL
3. type=3：content为视频URL
4. ...

这样就可以做到存储不同的聊天记录的效果

表单之间的关系

ER图：

erDiagram USER ||--o{ BOOK : sell USER ||--o{ BOOK : purchase USER ||--o{ ORDER : purchase BOOK ||--|| TYPE : belongTo USER { id int username string password string nickname string email string userImg url updateTime date createTime date power int } BOOK { id int name string price double isbn string img url detail string releaseTime date sellerId int purchased bool } ORDER { id int buyerId int bookId int payTime date address string status int } TYPE { id int name string }

以上显示出来的外键约束并非是真正落实到数据库上的约束，也就是说实际上并没有添加外键约束，只是为了说明表之间的关系。

真实开发中我们会采用代码层面的逻辑外键约束，方便删除表项

接口文档设计

本次项目采用前后端分离的架构，所以前端和后端之间需要一个开发共识，就是接口文档。

我们为每一个接口进行了详细的设计，以便于开发的流畅。

由于接口文档过于冗长，所以我们编写了另外一篇随笔用来展示接口文档：

接口文档

工具的使用

本次Alpha冲刺中，我们采用Apifox这个工具用作接口的开发和测试

使用git作为版本管理工具

使用docker进行项目运行环境的部署

后端使用IDEA进行Java代码的编写（使用到了SpringBoot，Mybatis，Spring，SpringMVC，MySQL，Redis）

前端时候JS框架React，并使用AntDesign这个组件库

Alpha任务分配计划

前端

由郭亮和吴鸿洲结对完成前端的用户交互逻辑。

后端

模块间的依赖关系：

各个模块的负责人：

1. 用户模块：黄俊杰
2. 书籍模块：黄俊超
3. 订单模块：杨宝烨
4. 聊天模块：张永祥

后端将按照接口文档，为前端提供交互的端口

冲刺计划

事先预测三天完成项目，剩余时间就是测试和修改，以及配合前端的需求进行开发

测试计划

测试人员：张永祥

依赖环境测试

由于项目最终会部署到服务器上，所以在搭建环境的时候使用了docker进行环境的搭建。

配置好环境之后，能让前端、后端、测试都能简单地搭建起后端服务，这样对开发时非常有利的。

不用陷入令人困惑的环境配置中

后端接口测试

以接口为单位

利用Apifox对后端接口进行测试

针对每一个开发完成的后端接口，尽可能模拟所有可能的用户输入，验证结果，以保证后端能够提供正确的服务。

这样前端在开发的时候，就可以不用担心后端接口出现的问题，专心编写交互逻辑。

前端页面结合后端进行测试

前端由于Ajax的各种特性，可能会和后端所写的服务器不匹配导致请求出错，首先需要测试在服务器是否能处理前端Ajax发出的探测请求。

确认服务器能正确处理请求后，开始以功能为单位，对前端页面进行测试。

主要完成：

1. 功能是否正常运行
2. 运行的时间是否符合预期
3. 交互的逻辑是否符合当下人们的常识
4. 交互逻辑的正确性验证

保证用户能得到接近于淘宝这样的大网站的服务。

另外，加分项：由于我们是面向大学生的网站，那炫酷的页面也是吸引年轻人的一大亮点。