团队做业第四次—项目系统设计与数据库设计
| 这个做业属于哪一个课程 | 2020春|W班(福州大学) |
|---|---|
| 这个做业要求在哪里 | 团队做业第四次—项目系统设计与数据库设计 |
| 团队名称 | RATE-MAX |
| 这个做业的目标 | 完善需求分析，新增系统设计、数据库设计 |
| 做业正文 | 下文 |
| 其余参考文献 | ... |
团队项目的预期开发计划时间安排
| 时间 | 活动产出 |
|---|---|
| 阶段1（4.7-4.11） 数据库设计 |
系统及数据库设计复审 sql文件及复审 项目计划时间及分工 自学技术 |
| 阶段2（4.12-4.18） 软件测试 |
环境配置 目录结构约束 接口复审 服务器部署 自学技术 |
| 阶段3（4.19-4.25） Alpha第一周 |
完成“我的中心”模块 完成“私聊”模块 测试上述两个模块功能 |
| 阶段4（4.26-5.1） Alpha第二周 |
完成“广场”模块 实现管理员：查看列表 测试模块功能 准备答辩事宜 |
| 阶段5（5.3-5.16） Beta第一二周 |
Alpha功能完善 小模块功能添加 细节调整 |
| 阶段6（5.18-5.25） Beta第三周 |
完成“深夜食堂”模块 测试模块功能 |
| 阶段7（5.26-6.2） Beta第四周 |
完成“漂流瓶”模块 完成“广告页”模块 测试模块功能 实现管理员功能：封号、封聊天室、举报处理 |
| 阶段8（6.3-6.5） Beta第五周 |
优化 修补 |
团队项目的预期开发计划分工安排
| 模块 | 前端人员 | 后端人员 |
|---|---|---|
| 聊天模块 | 林海峰 | 洪楷滨，陈炀 |
| 我的中心模块 | 林露 | 李波 |
| 广场功能模块 | 陈如滨 | 黄毅，黄筱宇 |
| 管理员模块 | 林露，陈如滨 | 李波，陈炀 |
| 深夜食堂模块 | 林露，陈如滨 | 洪楷滨，黄筱宇 |
| 漂流瓶模块 | 林海峰 | 黄毅 |
相关设计图
体系结构图
（本系统的设计主要是基于MVC设计模式，M表明模型Model，V表明视图View，C表明控制器Controller。）
html
功能模块层次图
（分为普通用户功能模块和管理员功能模块）
前端
设计类图
- 注册登陆类
- 我的中心类
- 管理员类
- 广场类
- 拓展部分类
- 朋友列表类
- 漂流瓶类
- 深夜食堂类
ER分析
（注：实线表示标识关系，虚线表示非标识关系。实心圆端所在的那端为一对多关系中的多的那端。）git
表结构设计
系统安全+权限设计
-
防止用户直接操做数据库
用户只能经过给定的外部接口操做数据库：外部接口向内部接口传递参数，而后进行预编译sql语句后才能操做数据库，这从根本上杜绝了用户直接操做数据库的可能。
github -
用户帐号密码的加密
帐号不加密，密码后期进行相关加密技术进行加密（md5）
算法 -
权限设置
定义用户的权限，限制个别用户对某些功能的使用。如用户在与人聊天是收到举报并在管理员进行封号处理后，用户有一段时间不能与他人进行相遇的朋友界面的对话。在某个聊天室的被管理员进行关闭时，用户无权限访问聊天室聊天。在动态页面的某条动态收到管理员处理时，该条动态用户无权限查看。
sql -
视图控制
系统定义视图，为不一样的用户定义不一样的视图，把数据对象限制在必定的范围内， 经过视图机制把要保密的数据对无权用户隐藏起来。
数据库 -
信息存取控制
后期开发事后时间充裕的化进行对数据库中有关表和字段信息的加密、解密。初步决定采用用对称加密算法中的分组密码算法DES实现。若是有更进一步的健壮性要求，采用三重DES、IDEA等加密算法。
后端 -
保密安全设置
后台设置拦截器防止同一IP在短期内进行大量的恶意请求，形成服务器资源紧张，瘫痪的现象。
后端设置过滤机制，使用过滤器对没有注册登陆用户的请求进行拦截，不予放行，防止非法用户恶意操做，只有通过常规途径注册并登陆的用户才能使用系统。
设计模式
问题回答&需求分析改进
补充说明
-
Q：QQ邮箱的漂流瓶玩法已经凉了好几年了，大家的漂流瓶功能如何吸引用户？
A：由于咱们的项目主要功能主打聊天和匿名发言，谈心还有不受生活拘束的自由自在的聊天，因此漂流瓶只是个额外的趣味性功能，能让用户闲暇时间能体会以前的漂流瓶的趣味，并不考虑用漂流瓶吸引用户。
安全 -
Q：有跟其余系统接入的情形吗？
A：以前有考虑外部的系统的接入，主要是外部的信息屏蔽系统，短信系统，还有以后可留做拓展的举报审核系统。 -
Q：那么在需求中是否有考虑他们与现有类的关系？或者数据流关系？
A：以前需求中仅仅只是考虑现有内部类的关系，将外部系统隔离在外，并未创建联系，以后在类图中有添加。如登录模块中与外部短信接口进行联系，同时举报也有响应的外部接口进行联系。
数据流图有相应的审核功能和身份验证功能保证外部系统的交互。 -
Q：这个当初推行的是全匿名的聊天这个用户的昵称是怎么处理的？
A：自行设置 -
Q：每次聊天的时候都新建一个昵称吗？
A：是的 -
Q：是随机产生的匿名昵称吗？
A：用户自带昵称。
系统设计讨论
-
P：用户使用场景图，好像面向对象课上有过相似的例子，登录选课系统那个例子。记得是说登录包括其余用况的话“登录”用况的功能不单一，必需要了解系统的全部其余模块才能描述清楚“登录”用况，从维护的角度来看，会忘记对“登录”用况进行修改。建议将登录用况彻底独立于其余用况。
A：将登录用况独立出来。 -
P：发布动态以及评论的相关接口，表情和图片应该和动态内容是一块儿传递的？
A：图片先不设置单独类型进行传递，采用与文字内容一块儿传递的方式 -
P：相遇的朋友 第七个 查看朋友信息 下面还有“不太清楚怎么设计”
A：添加举报信息返回接口。 -
P：捞漂流瓶的传递参数问题。
A：开始设计时讲手机号做为主键，后修改成用户Id,并将全部的接口参数进行修改。 -
P：泳道图的设置标签？
A：添加设置标签事件。
数据库讨论
-
P：用户状态须要字段吗？
A：封禁 采用额外设置一个封禁表 -
P：本周标签用id仍是id名？
A：为了快速查看页面，本周标签用逗号分隔 -
P：本周标签的个数？
A：本周标签便可以添加也能够删除直到有三个标签，且容许为空。 -
P：过往标签，是直接用上周标签仍是统计过去全部的标签？
A: 包括全部的，按过往标签次数来显示。 -
P：用户标签表问题？若是我这周跟上周选择了同样的标签,那主键不是有问题?
A：标签表存放过往标签，加一个标签次数做为统计区分，同时删除标签类型字段。 -
P：朋友和信赖的概念问题？
A：这个“朋友”不是咱们平常的那种相识的朋友,意思清楚就好了 -
P：深夜食堂类要有时间？
A：要有，存开始与结束时间。 -
P：评论表中被评论人id改为动态id?
A：修改 -
P：管理员功能？
A：查看用户信息 、封号。 -
P：漂流瓶表应该关联仓库表？抛和捞的上限？
A：用户信息表增长与漂流瓶仓库表的关联。用户信息表记录漂流瓶打捞与抛出个数（每日零点置零） -
P：漂流瓶编辑的关联表须要有时间吗？
A：加上edit_date字段。 -
P：举报类和举报表的肯定？
A：举报缘由就设计成列表让用户选吧，举报应该有类型，毕竟后台管理也要知道是啥类型的对象才能处理。因此是举报类型,举报项目+举报内容,没有图片 -
P：个人钱包问题？
A：支付系统由于…是扩展功能中的扩展功能，估摸着时间不够作不了。 -
P：聊天室搜索问题？
A：按聊天室名称的模糊搜索。以后看状况添加标签搜索。 -
P：数据库名称？
A：Hebdo。
本次工做流程、组员分工、组员贡献度比例
| 学号 | 工做内容 | 贡献度 |
|---|---|---|
| 221701123 | 体系结构设计；接口设计，安全健壮性设计； 编写sql文件；预期开发计划安排；原型复审 |
13 |
| 221701101 | 设计与完善ER分析+表结构；制做评审表； 数据库设计文档整合复审 |
12.5 |
| 221701108 | 制做与完善数据流图；编写sql文件； 原型修改完善；类图复审 |
12 |
| 221701120 | 功能模块层次设计；编写sql文件； 系统设计文档复审 |
12.5 |
| 221701122 | 类图修改完善；制做答辩PPT； sql文件复审 |
12 |
| 221701133 | 评审表设计；接口设计，安全健壮性设计； 预期开发计划安排；答辩PPT复审；答辩准备 |
13 |
| 221701139 | 接口设计，安全健壮性设计；预期开发计划安排； 设计项目开发技术及版本约束sql文件复审 |
13.5 |
| 221701202 | 制做泳道图；编写数据库设计文档引言； 数据库设计文档整合复审；撰写随笔 |
11.5 |
github仓库及文件下载连接
github仓库：sevenDays
RATE-MAX_系统设计说明书
RATE-MAX_数据库设计说明书
RATE-MAX_系统设计和数据库设计答辩PPT