| 这个作业属于哪个课程 | 2020春-S班(福州大学) |
|---|---|
| 这个作业的要求在那里 | 团队作业第四次—项目系统设计与数据库设计 |
| 团队名称 | Hail Hydra(九头蛇) |
| 这个作业的目标 | 完成项目的系统设计和数据库设计 |
| 作业正文 | |
| 其他参考文献 | 百度，CSDN |
开发计划时间表
| 工作安排 | 截止时间 | 完成情况 |
|---|---|---|
| 完成系统设计，学习所需技术框架，完成前后端交互测试 | 2020-4-7 | 完成 |
| 完成数据库设计，确定接口传输数据格式，搭建项目基本框架 | 2020-4-13 | |
| 前端完成静态页面，后端完成对应接口的数据处理 | 2020-4-19 | 待完成 |
| 前后端进行对接，完成接口测试，处理错误，发布Alpha版本 | 2020-4-26 | |
| 前端对界面细节进行优化，后端完成权限处理，增强系统健壮性 | 2020-5-3 | |
| 前后端进行功能测试，修复bug | 2020-5-10 | |
| 正式版本完善，将项目部署到云服务器，完成项目使用手册，完善项目文档 | 2020-5-17 | |
| 正式版本发布，项目总结和汇报 | 2020-5-24 | 带完成 |
团队项目的预期开发计划分工安排
前端
| 姓名 | 分工 |
|---|---|
| 袁锦辉 | 完成登录界面；普通用户登录界面的静态页面；完成登录、首页、等你来答，搜索框，详情界面的数据交互 |
| 黄子峻 | 完成个人中心我的问题、我的回复、我的消息、修改密码的数据交互、完成前端普通用户部分所需文档 |
| 唐志豪 | 完成管理员界面静态页面,举报信息管理、用户管理，积分管理，新增板块管理的数据交互 |
| 黄忠雄 | 完成个人信息板块数据的交互，后期协同测试、完成前端后台页面所需文档 |
后端
| 翁绍鸿 | 完成功能模块中的回复模块、消息模块、奖励模块 |
| 张嘉伟 | 完成问题模块、投诉信息管理模块 |
| 刘成华 | 完成用户账号管理、临时板块管理、权限管理 |
| 韦琛 | 负责测试，并跟进各个阶段的文档 |
项目体系设计
架构设计
采用原因
本系统采用MVC设计架构，目的是为了使得前后端可以完全分离，后端团队在于前端团队确定好接口和数据结构后二者可以并行开发，从而提高效率。同时采用MVC架构使得前端视图和后端业务相分离，更容易改变程序的业务规则，提高了项目开发的灵活性和控制性。
数据流图
各层次之间配合流程
（1）Controller层：获取前端数据，并判断应调用的Service对象/函数
（2）Service层：对Controller层传入的参数进行处理，将数据转换为Model层对象，并对数据库进行增删查改操作，在处理结束后将前端所需的Model数据封装成 View对象返回给Controller层
（3）Controller层：将Service层返回的对象加上状态码等信息进一步进行封装，并返回给前端。
功能模块层次图
划分依据与原因
本项目主要分成7个模块（用户账号管理、问题管理、回复管理、临时板块管理、投诉信息管理、奖励管理和消息管理）。划分的主要依据是按照实际的功能划分，模块的功能尽可能的单一，操作对象也尽可能单一，其目的是为了使得各个模块之间尽可能相互独立，在开发分工中可以并行开发不同的模块，避免因耦合度太高而带来合作难度的提高。
设计类图
Controller类与Service类依赖关系图
第1、4行是系统的控制层，主要为前端提供数据接口，接受前端的数据请求，并经过判断后调用相应的服务层对象对数据进行处理，最后对服务层返回的数据结果进行包装返回前端。控制层的设计是根据功能模块的划分，即每个功能模块都有自己对应的控制类，共包含9个控制类分别为：QuestionController、ResponseController、MessageController、AttentionController、BlockController、ReportController、LoginController、UserController、RewardController
第2、3行对应的是服务层对象，作用是为控制层的功能进行具体实现，负责对数据的处理，数据库的更新，并将处理后的结果返回包装成对应的视图层对象返回给控制层。
QuestionService细节类图
在QuestionService类的设计中我们采用了策略模式对类的列表获取方式算法进行封装，因为在系统的前台页面中有多个界面都要获取问题列表，但是排序方式却不尽相同，若将这些算法全部都写在QuestionService类内部则会导致类十分的臃肿，增加了类的设计和实现难度，同时也给后期维护带来了困难。因此我们采用策略模式对类中获取列表方式的算法进行封装，通过继承公共类的方式使得相互之间可以替换，从而实现更换获取算法却不影响客户端的效果。
ResponseService细节类图
ResponseService类设计与QuestionService类似，是对获取回复列表的方式进行封装。
MessageService细节类图
MessageService类也采取了策略模式，主要是因为针对不同的消息系统有不同的处理方式，不同的处理方式写在不同的策略类中会提高系统的可扩展性。同时因为本系统有涉及积分的计算，很多的操作都会影响用户的积分，如：写问题，回复问题等，若将积分的处理分散在系统的各个地方则会给后期维护带来困难，因此我将积分的处理也放在了策略类中。 设计带来的好处：1.提高了类的可扩展性 (开闭原则)2.提高了程序的可维护性 (单一职责原则)3.使用聚合的方式设计策略类，有利于其他类对策略类的复用 (合成复用原则)4.使逻辑更加清晰，处理方法可以独立变化不相互影响5.简化了MessageService的设计和实现难度。
实体类图
数据库设计
数据库表设计概述
在数据库设计方面我们采用的关系型数据库，共设计了10张表，每个实体类都有对应的数据库存储表。其中为了提高问题表的查询和更新效率，我们将问题的标题和内容分别单独提取出来设置一张表来存储。
用户表：存储用户的基本个人信息
账户信息表：存储用户的账户信息，如经验值，等级等
问题表：用于存储问题的数据信息，如回复数，投诉数等
回复表：用于存储回复的数据信息，如点赞数，点灭数等
标题表：用于将问题的标题单独放到一张表中存储
内容表：用于将问题和回复的内容单独放到一张表里存储。
关注表：用于记录用户的关注问题
消息表：用于存储用户的消息记录
奖励申请表：用于记录所有用户的奖励申请记录
临时板块表：用于保存前台临时板块的信息
具体更为细节的设计说明请参考《数据库设计说明书》
ER分析
用户信息局部ER图
我们将账户数据（如积分，经验值等）从用户表中剥离出来，主要是为了使得表所对应的实体类能更清晰，不包含一些不必要的信息（如管理员用户不需要积分，经验值等账户数据）；所对应的代码设计是将账户数据作为一个类成员对象作为用户类的属性，当不需要该属性时，该属性可以为空。在表中二者体现为拥有关系。在数据库中存放的消息与用户之间的关联主要是通过消息表中的被操作者id，用户作为表中的操作对象，用于前台页面的消息展示。
用户对应数据库表中的用户表，在类图中对应User类
账户数据对应数据库表中的账户信息表，在类图中对应AccountData类
奖励记录局部ER图
在表的设计中，用户和奖励记录建的关系是申请关系，即用户申请后创建的奖励记录，二者通过奖励记录中的用户id外键关联，一个用户可以有多个奖励记录，因此二者之间是一对多的关系。
用户对应数据表中的用户表，在类图中对应User类
奖励记录对应数据库中的奖励申请表，在类图中对应Reward类
用户-问题局部ER图
用户和问题之间主要有两种方式关联：
一是通过问题的作者id外键关联，体现为创建关系，是用户创建问题，因为一个用户可以创建多个问题，因此二者间体现的是一对多的关系。
二是通过关注，用户通过关注问题可以与问题产生关联，这里因为别人的问题和用户之间没有直接字段上的关联，因此我们在中间加入了一个关注表，用于记录用户和问题之间的关注信息，用户和关注间体现1对多的关系（一个用户可以关注多个问题），问题和关注之间也是一对多的关旭（一个问题可以被多个用户关注）
问题对应数据库表中的问题表，在类图中对应Question类
用户对应数据表中的用户表，在类图中的对应User类
关注对应数据表中的关注表，在类图中对应Attention类
用户-问题-回复局部ER图
用户和问题，回复之间主要是通过实体中的作者id作为外键关联，体现的是创建关系，回复与问题之间通过回复表的问题编号产生多对一的关联，体现一个问题可以有多个回复。
回复对用数据库表中的回复表，在类图中对应Response类
问题对用数据表中的问题表，在类图中对应Question类
问题-回复局部ER图
在问题和回复中都有一些数据较为庞大的字段——内容/标题，该部分字段不仅数据较大，而且很少更新（主要更新的是点赞数，评论数等数据），根据设计约定第四条，我们将标题和内容从表中抽离，单独形成一张表，通过回复/问题的外键相关联，提高表的查询，更新效率。
内容对应数据表中的内容表，在类图中对应Content类
标题对应数据表中的标题表，在类图中对应Title类
回复对应数据表中的回复表，在类图中对应Response类
问题对应数据表中的问题表，在类图中对应Question类
总ER图
系统安全和权限设计
系统安全性
针对系统的安全性，我们考虑了以下几种常见的web攻击方式，并制定了一下几种应对策略
CSRF(跨站请求伪造)
CSRF是指在用户登录后系统会将用户信息保存到用户浏览器存储，若用户同时一些恶意的网站，这些网站可能会利用存储的用户信息进入系统，从而可以对数据进行读取和破坏
解决方案：在过滤器中进行referer识别，若referer为空或不属于自身域及子域，则拒绝后续操作
SQL注入
SQL注入是指某些用户在输入某些数据的时候会故意加上一些SQL语句，若没有经过处理直接拿这些数据进行数据库操作可能会导致跨越权限或对数据造成损坏。
解决方案：登录账号在进行数据查询前会进行字符检查，账号只能由字母和数字组成。例：输入为“123 or ‘1’ = ‘1’”的账号将不会进行数据库查询，直接判为账号错误
SSX(跨站脚本攻击)
SSX是指某些用户存入数据库的信息（如系统中的问题标题等）中夹杂js代码，若使用jsp等方式直接将值嵌入html语句中有可能在页面加载时执行该部分语句达到某些目的。
解决方案：前端内容赋值全部通过js改变dom对象的innerHTML属性可以避免该情况的发生
其他的数据安全性设计
在前后端数据传输的过程中对用户的数据进行加密处理（具体的加密算法还没有决定，等到项目进行安全性部分时再决定具体采用那种加密算法）
系统权限设计
本系统共有两种用户，三种角色每种角色对应的权限如下：
管理员(管理员用户)：
登录进入的是后台页面，能够对所有用户具有增删查改权限；同时也对文章和评论具有查看、删除权限；对奖励记录具有查看和删除权限；
老师(普通用户)：
进入前台页面，具有对问题、回复进行新建和查找权限；具有查看和修改本用户信息的权限；相较于另一个普通用户老师没有兑换奖励的权限
学生(普通用户)：
进入前台页面，对问题、回复具有新建和查看权限，同时具有兑换奖励权限；用户操作只具备查看和修改本用户的权限
针对老师助教和其他同学提出的建议进行的改进
类图
在类图方面，我们在上次作业中完成的不是很完整，我们这次在进行系统结构设计后，根据系统的结构设计和功能划分对类图进行了更为细致的设计，使得每个功能和接口都有对应的类进行处理
传输数据的加密
在上次答辩中我们在安全性方面漏考虑的数据在传输过程的加密，在讨论后我们决定最后在安全性实现阶段在数据传输前进行加密，以保证敏感数据不会被窃取。
完成这次工作的工作流程
- 初步学习了项目所需要的技术框架，进行了简单的测试（包括前后端交互测试，数据库增删查改测试）
- 根据测试讨论项目具体的实现方式
- 后端讨论并细化类图设计，与前端人员确定接口并整理成数据文档
- 前后端讨论并确定前后端借口具体传输的数据格式，并整理成文档
- 根据系统设计搭建项目上传
贡献度表格
| 学号 | 贡献度 | ||
|---|---|---|---|
| 021700613 | 参与管理员界面接口设计，并完成相应文档 | 10 | |
| 221600313 | 参与普通用户前台页面的接口设计，并完成相应文档 | ||
| 221701118 | 参与数据库设计，系统架构设计，完成活动图 | 12 | |
| 221701136 | 寻找并学习管理员界面所需要的前端技术，参与管理员页面的接口设计 | 15 | |
| 221701219 | 完成系统设计说明书部分内容，完成数据库设计说明书部分内容，完成数据库设计ER图 | ||
| 221701240（生病） | 郑逸豪 | 生病住院 | |
| 221701316 | 参与数据库设计，系统架构设计 | 11 | |
| 221701335 | 学习前台普通用户界面所需要的前端知识，参与普通用户界面接口设计 | 14 | |
| 221701421 | 参与接口设计，数据库设计，系统架构设计，完成部分部分系统设计说明书，完成部分数据库设计说明书，答辩+制作PPT，完成博客 | 16 |
附件链接
Github 团队仓库链接
校园帮帮网_系统设计说明书
校园帮帮网_系统设计和数据库设计答辩PPT
校园帮帮网_数据库设计说明书
接口传输数据设计