逐梦校友圈——项目系统设计与数据库设计
| 这个作业属于哪个课程 | <班级的链接> |
|---|---|
| 这个作业要求在哪里 | <作业要求的链接> |
| 这个作业的目标 | 1.项目系统设计 2.数据库设计 3.《系统设计说明书》 4.《数据库设计说明书》 5. 答辩ppt |
| 其他参考文献 | 1.阿里巴巴Mysql数据库规约 2.数据库设计说明书编写规范(国标) 3.数据库系统概论(第四版) 王珊，萨师煊编著 高等教育出版社 4.构建之法(第三版) 邹欣编著 人民邮电出版社 |
预计开发计划
时间安排
| 周 数 | 任务目标 | 具体日期 |
|---|---|---|
| 第8周 | 全体成员：完成系统设计和数据库设计任务（4.23止） 后续（增加知识储备）： 前端成员：跟进学习微信小程序开发知识，vue框架知识 后端成员：继续跟进SpringBoot框架的学习 |
4.19~4.25 |
| 第9周 | 继续学习开发框架，学习敏感词验证，审核策略等算法。 根据之前的分工，前后端开始进行开发 前端成员：1. 成员间做好任务分配 2. 完成部分微信小程序界面的开发，并做好简单交互功能 3. Web端后台界面同步开发 后端成员：1. 成员间做好任务分配 2. 对之前设置的接口,数据库进行编写 3. 与前端多加交流，调整任务 |
4.26~5.2 |
| 第10周 | 1. 继续完善上一周的任务 2. 对其他前面未完成的功能进行编写 3. 进行前后端整合及测试，修复遇到的bug 4.发布alpha版本 |
5.3~5.9 |
| 第11周 | 1. 完善功能 ，修复存在的bug 2. 反思alpha版本开发存在的问题 3. 讨论程序设计的问题或者缺陷，对程序进行必要的重新设计 |
5.10~5.16 |
| 第12周 | 1. 对上一次程序版本进行反思，寻求解决方案 2. 继续加强对开发相关知识的学习 |
5.17~5.23 |
| 第13周 | 继续加强对开发相关知识的学习 | 5.24~5.30 |
| 第14周 | 根据之前的反思结果方案进行再开发 | 5.31~6.6 |
| 第15周 | 编写和完善代码，对程序进行测试 | 6.7~6.13 |
| 第16周 | 1. 编写和完善代码，对程序进行测试 2. 发布beta版本 3. 事后总结 |
6.14-6.20 |
人员分工
| 学号 | 职位 | 工作内容 |
|---|---|---|
| 221801125 | PM | 项目进度安排，项目进度监督，项目文档更进 |
| 221801104 | 美工 | 界面UI，界面美化 |
| 221801209 | 后端 | 权限设置，数据库操作 |
| 221801215 | 后端 | 帖文页面接口 |
| 221801222 | 前端 | 前后端对接 |
| 221801230 | 前端 | 贴文卡片，组局卡片，消息卡片 |
| 221801231 | 前端 | 界面框架，界面拼接 |
| 221801321 | 后端 | 组局页面接口 |
| 221801411 | 后端 | 个人中心接口，微信认证 |
系统结构设计
结构设计
整个软件共分为7个模块，分别是
-
认证模块
-
校友圈模块
-
消息模块
-
发帖模块
-
拼局模块
-
个人模块
-
后台模块
一、认证模块
1.1学生基础信息认证模块
-提供学生基础信息验证
1.2学生个人证件认证模块
-提供学生个人证件图片上传
二、校友圈模块
2.1签到模块
-提供用户进行每日签到
2.2帖子搜索模块
-提供用户进行全局模糊搜索论文
2.3帖子详情模块
2.3.1评论帖子
-用户对帖子进行评论相关操作
2.3.2点赞帖子
-用户对帖子进行点赞相关操作
2.3.3赞赏帖子
-用户对帖子进行赞赏相关操作
2.3.4收藏帖子
-用户对帖子进行收藏相关操作
2.3.5拉黑帖子发布者
-用户对帖子发布者进行拉黑，不看他的相关帖子并且不与他私聊
2.3.6举报帖子
-用户对含有不正当内容的帖子进行举报
三、消息模块
3.1查看我的相关评论
-提供用户查看与其帖子相关的评论
3.2查看我的相关点赞
3.2.1查看我的相关赞赏
-提供用户查看与其帖子相关的赞赏
3.2.2查看我的相关点赏
-提供用户查看与其帖子相关的点赏
3.3查看我的相关拼局
-提供用户查看与其拼局相关的信息
3.4查看我的相关私聊
-提供用户与其他用户进行私聊
四、发帖模块
4.1帖子发布
4.1.1根据主题发布帖子
-提供用户根据主题帖子发布
4.1.2根据地址发布帖子
-提供用户根据地址帖子发布
五、拼局模块
5.1组局详情
5.1.1加入组局
-用户加入已创建好的组局
5.1.2评论组局
-用户评论已创建好的组局
5.2筛选组局信息
-用户根据条件显示想看到的组局内容
5.3发起组局
-用户创建新的拼局
5.4搜索组局
-用户搜索关键词相关组局
六、个人模块
6.1个人数据模块
6.1.1人品值记录模块
-显示用户的人品值数与人品值进出记录
6.1.2个人收藏模块
-显示用户的个人收藏记录
6.1.3个人帖子模块
-显示用户的个人帖子记录
6.1.3个人评论模块
-显示用户的个人评论记录
6.2附加功能模块
6.2.1新手帮助
-为用户提供使用该软件的新手帮助说明
6.2.2社区规范
-为用户提供使用该软件的社区规范说明
6.2.3逐梦树洞
-为用户提供私人的信息交流空间
6.2.4邀请校友
-为用户提供邀请校友进行分享
6.3系统模块
6.3.1设置模块
-对软件进行基础设置
6.3.2关于我们
-了解软件开发者相关信息和联系方式
6.3.3意见反馈模块
-对用户使用软件体验进行反馈
七、后台模块
7.1.1审核模块
-对用户的帖子评论图片等信息进行内容审核
7.1.2维护模块
-对软件的一些基础功能进行调整
功能模块层次图
.png)
ER图
从用户角度出发，寻找用户拥有的属性，寻找用户与其他类（帖文、组局等）的关联，确定之间的关系：1对多、1对1等，再补充其他类的拥有的属性。
用户和管理员部分
帖文(post)部分
组局部分
数据库表结构
数据库使用关系型数据库。数据库表结构设计在ER图的基础上，结合实体属性的存储方式，为各实体属性赋予相应的数据类型。
此外，为表示ER图中实体之间的一对多关系，数据库表中使用新增外键属性的方法对一对多的关系进行约束，例如帖子post与帖子的评论post_comment是一对多的关系，在post_comment中新增post_id属性与对应帖子post的id属性关联，建立外键约束，表示帖子评论所属的帖子，对帖子与帖子评论的一对多关系进行了刻画和约束。ER图中还出现了实体与自身的一对多约束，同样，在数据库设计时在表中建立了外键与自身关联，例如，一条帖子评论下可能包含有多条评论（楼中楼），设计时新增pre_id外键关联自身表的id属性，建立外键，表示帖子评论所属的上一级评论，对帖子评论与自身的一对多的关系进行了刻画和约束。
ER图中出现的多对多关系，考虑到要满足范式减少数据冗余，关系型数据库较难表示，与要对多对多关系进行转换（实际在ER图中已经转换），新建一个额外的表，存储多对多关联，将多对多关联分解为两个一对多关联，例如用户和组局之间的多对多关系，新增组局人员表对多对多进行转换，变为两个一对多的关系。
以上两种处理思路解决了系统的一对多和多对多约束。
为了符合一些行业规范，在各个表中新增加了gmt_create,gmt_modified对记录创建时间和最近一次修改时间进行了存储。还增加了deleted属性用于实现逻辑删除功能，方便后台管理查看记录。
- 用户表
| 名称 | 解释 |
|---|---|
| admittedYear | 毕业年份 |
| birthday | 出生年月 |
| certificateImageUrl | 用户证件照 |
| city | 城市 |
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 修改时间 |
| id | 用户ID(使用微信提供的openID) |
| isGraduated | 是否毕业 |
| province | 省份 |
| rpValue | 人品值 |
| school | 用户学校 |
| sex | 性别(0为女，1为男，2为无) |
| status | 用户状态(0为未审核，1为已审核) |
| userIconUrl | 用户头像 |
| username | 用户名 |
- 管理员表
- 黑名单表
| 名称 | 解释 |
|---|---|
| beUserId | 被拉黑用户ID |
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 修改时间 |
| id | 黑名单ID |
| userId | 用户ID |
- 组局表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| description | 组局描述 |
| gmtCreate | 创建时间 |
| gmtModified | 修改时间 |
| id | 组局ID |
| imageUrls | 图片url链接 |
| partyTypeId | 组局类型ID |
| peopleCnt | 组局人数限定 |
| publisherId | 发布者ID |
- 组局评论表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | 组局评论ID |
| idFrom | 评论者ID |
| information | 内容 |
| partyId | 对应组局ID |
| preId | 父评论ID |
| status | 评论状态0(正常状态）,1（举报过多被挂起），2（已被删除） |
- 组局成员表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | 组局参与表ID |
| participantId | 参与者ID |
| partyId | 对应组局ID |
- 组局类型表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | 组局类型ID |
| name | 组局类型名 |
- 帖文表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | 帖文ID |
| imageUrls | 帖子图片URL |
| message | 帖子文本内容 |
| postTypeId | 帖子类型ID，外键 |
| publisherId | 发布者ID，外键 |
| status | 帖子状态：0(正常状态）,1（举报过多被挂起），2（已被删除） |
- 帖文评论表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | ID |
| idFrom | 发布评论用户ID，外键 |
| message | 内容 |
| postId | 所属帖子ID，外键 |
| preId | 所属评论ID，外键 |
| status | 评论状态：0(正常状态）,1（举报过多被挂起），2（已被删除） |
- 帖文审核表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | ID |
| idFrom | 发布评论用户ID，外键 |
| postId | 所属帖子ID，外键 |
- 帖文收藏表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | ID |
| idFrom | 关注用户ID，外键 |
| postId | 帖子ID，外键 |
- 帖文赞赏表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | ID |
| idFrom | 发布评论用户ID，外键 |
| postId | 赞赏用户ID，外键 |
| amount | 赞赏数量 |
- 帖文类型表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | ID |
| name | 帖子类型名 |
| pre_id | 帖子类型父类ID，外键 |
- 私聊表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| fromId | 发送用户ID |
| gmtCreate | 创建时间 |
| gmtModified | 修改时间 |
| id | 私聊ID |
| message | 私聊信息 |
| toId | 接收用户ID |
- 举报表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| gmtCreate | 创建时间 |
| gmtModified | 最近一次修改时间 |
| id | ID |
| userId | 举报用户ID，外键 |
| postId | 被举报帖子ID，外键 |
- 树洞表
| 名称 | 解释 |
|---|---|
| deleted | 逻辑删除 |
| fromId | 用户ID |
| gmtCreate | 创建时间 |
| gmtModified | 修改时间 |
| id | 树洞ID |
| message | 树洞内容 |
类图
UML 类图用于描述系统中所包含的类以及它们之间的相互关系，帮助人们简化对系统的理解，它是系统分析和设计阶段的重要产物，也是系统编码和测试的重要模型依据。一个好的类图设计能够给编码开发一个好的开始。我们按照系统的功能模块划分，将类图设计部分分为4个部分单独设计（用户部分、管理员部分、贴文部分和组局部分），之后进行整合。当然，能够这样进行划分设计的前提是各个模块之间的关联并非很多，往往只是一个模块和另一个模块中的某个类有关联。所以，模块化的好处在于能够更清晰地发现类和拟定类的方法，并且不至于使类图过于庞大而影响最终的阅读。
我们在类图设计中结合了开发阶段所利用的语言、框架、操作系统等等因素。在这些开发环境的基础上组织我们的类。依据SpringBoot框架，我们将类分为Model，Dao，Service和Controller四大部分。其中，Model是系统中的实体类，负责规范数据结构，方便数据的传输和使用；Dao部分则为与数据库交互的接口，一个Model往往对应一个Dao；Service类则是系统的处理核心，负责起系统的大部分计算；Controller类则为前端提供接口。我们遵循设计为开发原则，杜绝无用功。
此外，我们在类图中加入了包，是类图组织有序，更易于观看
用户类图
发帖类图
组局类图
管理员类图
系统安全
不同需求对安全产生不同的定义，安全对我们来说就是数据安全，即数据不被窃取，数据不被篡改，数据不被伪造。安全设计的核心是信任域的划分，而基于安全域的原子权限则是数据的坚实保护。原子权限正是这次安全设计的核心思路。
系统（平台）层面的安全
软件运行所需的基础环境既是此处的系统，包括以下内容：操作系统，WEB服务器中间件，软件运行所需的程序语言环境。
在这个层面主要从这几个方面进行防护：
- 最小服务，通过减少与外界的接触面来降低入侵发生的可能性，只开放必要的服务端口
- 安全版本，使用各种应用的最新stable版本来防止入侵
- 合理的iptables设置，通过设置严格的出网规则来提高入侵的成本和难度
- 合理的配置，对于各种应用的配置不应当直接复制网上的demo，而应该了解每一个配置会产生的行为后进行设计
- Firewall的配置，禁止所有非TCP通信
- 安装安全软件识别已有特征的恶意软件和行为
- 根据入侵常用手段配置蜜罐，使得我们有可能在被入侵的时候得知
- 数据与程序环境的分离，保证在得到程序环境的时候无法直接得到数据，对各种密钥进行加密
- 合理的文件系统权限配置，保证得到网站权限无法修改网站代码
框架层面的安全
框架层面的安全即我们为了快速开发使用的框架
在这个层面从以下方面做好防范：
- 不要从网上copy配置项，应当了解每一个配置会产生的行为，再进行框架的设置
- 对于自己所使用的框架接口应当清楚会产生怎样的行为，而不是关注会产生怎样的结果
- 在使用框架开发时应对开发环境和生产环境进行区分，在生产环境去除一切其他不必要的功能，比如报错
代码层面的安全
在开发时我们应当遵守以下简单的规则进行安全防护：
- 简单了解owasptop10 后进行开发
- 使用框架提供的或团队提供的安全操作函数
- 在代码开发时应遵守OWASP安全编码指南
- 对所有web接口进行
- 在代码上线前使用白盒安全扫描工具进行测试，比如codeql
- 一切用户资源文件都上传至OSS中
传输层面的安全
在数据传输我们使用以下方法进行防御：
- 部署CDN防止发现真实IP
- 负载均衡增加入侵难度
- 部署云WAF防御恶意攻击
- 配置访问频率防止DDOS和拆解攻击
- 使用HTTPS加密传输数据
- 前端对敏感数据比如密码使用ECDH密钥交换+AES加密
客户端层面的安全
在客户端层面我们要做好以下防护：
- Csrf token 防止跨站请求伪造
- 验证码防止暴力拆解，资源滥用
- CSP防止恶意js脚本
- Httponly防止cookie窃取
安全设计结构图
处于成本考虑，以docker 为单元进行服务隔离
权限设计
权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。
迄今为止最为普及的权限设计模型是RBAC 模型,基于角色的访问控制。由于我们的记账系统是为已注册登录的用户提供服务
页面权限
- 普通用户 : 校友圈页面，个人页面，拼局页面
- 认证用户：校友圈页面，个人页面，拼局页面
- 管理员用户：认证验证页面，组局验证页面，贴文验证页面
功能权限
- 普通用户：修改个人资料，查看校友圈内容，参与个人认证，参与签到
- 认证用户：修改个人资料，查看校友圈内容，参与个人认证，查看消息，发送帖子，发起组局，匿名帖文，参与签到
- 管理员用户：通过验证，不通过验证
遗留问题
审核机制
手动写自动筛选功能，管理员在后期可以对这些帖文组局进行再筛查，从而做到自动化。同时发布相关公约约定，一旦发现违规行为将进行封号处理
认证机制
考虑到认证机制的要素过多但是同时不保证人员虚假，我们选择使用拍摄学生证上传，同时增强对数据方面的保护，保证人员的简单性
匿名功能
匿名功能没有作为我们的主打功能，但是是存在在我们的系统功能当中的，匿名发布消息需要消耗一定的人品值
本次作业贡献
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221801104 | 项目功能思维导图及分析 | 10.2 |
| 221801125 | 文档归纳，ppt，博客园文档 | 11.6 |
| 221801209 | 系统安全性分析，系统权限分析 | 10.4 |
| 221801215 | 类图，接口文档，数据库表，ER图 | 11.9 |
| 221801222 | 类图，接口文档，数据库表，ER图 | 12.1 |
| 221801230 | 数据流图，项目规划 | 10.4 |
| 221801231 | 功能模块层次图，接口文档 | 11.3 |
| 221801321 | 类图包图，接口文档，数据库表，ER图 | 11.8 |
| 221801411 | 泳道图 | 10.3 |
