团队作业第四次—项目系统设计与数据库设计

这个作业属于哪个课程	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。）

功能模块层次图

（分为普通用户功能模块和管理员功能模块）

设计类图

• 注册登录类

• 个人中心类

• 管理员类

• 广场类

• 拓展部分类

• 朋友列表类

• 漂流瓶类

• 深夜食堂类

ER分析

（注：实线表示标识关系，虚线表示非标识关系。实心圆端所在的那端为一对多关系中的多的那端。）

表结构设计

系统安全+权限设计

• 防止用户直接操作数据库
  用户只能通过给定的外部接口操作数据库：外部接口向内部接口传递参数，然后进行预编译sql语句后才能操作数据库，这从根本上杜绝了用户直接操作数据库的可能。

• 用户账号密码的加密
  账号不加密，密码后期进行相关加密技术进行加密（md5）

• 权限设置
  定义用户的权限，限制个别用户对某些功能的使用。如用户在与人聊天是收到举报并在管理员进行封号处理后，用户有一段时间不能与他人进行相遇的朋友界面的对话。在某个聊天室的被管理员进行关闭时，用户无权限访问聊天室聊天。在动态页面的某条动态收到管理员处理时，该条动态用户无权限查看。

• 视图控制
  系统定义视图，为不同的用户定义不同的视图，把数据对象限制在一定的范围内， 通过视图机制把要保密的数据对无权用户隐藏起来。

• 信息存取控制
  后期开发过后时间充裕的化进行对数据库中有关表和字段信息的加密、解密。初步决定采用用对称加密算法中的分组密码算法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