Mobius——项目系统设计与数据库设计

[Mobius__]

这个作业属于哪个课程	2022年福大-软件工程;软件工程实践-W班
这个作业要求在哪	团队作业三—概要设计与数据库设计
这个作业的目标	接着上一次的成果，将项目的设计落地，继续完善设计类图，并在正式开始开发之前设计好系统和数据库、制定好计划和分工
其他参考文献	UML之类图 , UML类图详解,详解设计模式六大原则,数据库表结构设计的几条准则,数据库表设计（一对多、多对多),常见web攻击方法及防御手段总结,用户密码加密,JavaWeb项目前后端分离,RBAC用户、角色、权限、组设计方案

---

目录

• 1.系统与数据库设计
• 1.1体系结构设计图
• 1.2功能模块层次图
• 1.3ER分析图
• 1.4数据库表结构设计
• 2.类图
• 2.1实体类
• 2.2MVC架构类
• 3.接口设计
• 3.1 接口设计规范
• 3.2 接口总览
• 4.系统安全和权限设计
• 4.1系统安全性设计说明及解决方案
• 4.1.1CSRF(跨站请求伪造)
• 4.1.2XSS攻击
• 4.1.3SQL注入
• 4.1.4数据加密
• 4.1.5JWT主动失效
• 4.2权限设计与鉴权说明
• 5.改进分析
• Q1:用户类的”今日心情“属性需要记录历史的今日心情吗？如是的话，作为一个属性是否合适？
• Q2:邮票只在用户中设立一个属性是否合理是否要抽象一个类代表不同面值?
• Q3:任务的分配是如何进行的呢？比如由哪位同学担任组长身份然后分配任务？有没有定一个各模块（比如前、后端）的负责人?
• Q4:用例图include错误使用且将用例组织成操作流程。
• Q5:类图中的"用户"类的操作与用例混淆。
• Q6:后台在配色和布局上可以再做一些优化.
• 6.团队绩效
• 6.1工作流程
• 6.2组员分工及贡献度比例
• 7.开发计划安排
• 7.1团队项目的预期开发计划时间安排
• 7.2团队项目的预期开发计划分工安排
• 8.相关链接

1.系统与数据库设计

1.1体系结构设计图

系统结构描述

系统采用MVC模式进行设计，前后端分离。当后端团队与前端团队共同设计协调好接口后，可实现前后端并行开发，提高开发效率。由于视图层与业务层分离，耦合性低，业务层的各层次职责单一，所以更易于后期维护。

各层次关系职责说明

Controller层：

• 负责接收前端的Http请求，根据请求路径匹配相应控制器进行处理，并调用Service层获取所需数据，将数据返回给前端展示。
  Service层：
• 由Controller调用，调用DAO层获取所需的基本数据，主要进行数据的处理和封装，并将处理完成的数据交给Controller返回给前端。
  DAO层：
• 由Service层调用，定义一系列操作数据库的方法来与数据库进行交互，根据Service层的需求访问数据库，获取数据，并封装为模型对象或对象集合交予Service层进行进一步加工处理。

1.2功能模块层次图

划分依据与原因：

• 本项目前台(Android端)主要分成 4 个模块（信箱模块、笔友模块、胶囊模块、主页模块）。用户可以通过四个模块进行写信、收信操作；
• 后台管理系统(Web端)主要分为“管理员”、“超级管理员”；
• 其中“管理员”主要拥有4个功能模块，分别是“账号管理模块”、“数据分析模块”、“反馈中心模块”、“应用管理模块”；
• “超级管理员”主要拥有“管理员管理”和“管理员拥有的全部功能”两个功能模块。

划分的主要依据是按照实际的功能划分，每个模块的功能单一，操作对象也尽可能单一，其目的是为了使得各个模块之间尽可能相互独立，在开发分工中可以并行开发不同的模块，避免因耦合度太高而带来合作难度的提高；

1.3ER分析图

设计思路
根据需求分析中所画类图实体，以及关系，结合实际场景以及数据库具体储存形式进行分析，分为系统模块，用户模块，写信模块，日志模块，消息通知，签到模块，邮票模块，举报模块，其中写信模块又分为匿名信，时空胶囊，给笔友写信。

各部分实体

1.4数据库表结构设计

数据库名称为monbius
存储位置:默认位置

设计思路
根据er图分析出数据库表的概念模型和逻辑模型，然后再借由可视化数据库管理系统软件Navicat构建出主要的表结构，最后根据er图中实体类之间的关联关系为各表加上外键，构建出最后的物理模型。

用户表

管理员表

管理员权限表

日志表

消息表

举报表

反馈表

签到表

奖励表

签到记录表

邮票表

用户邮票关系表

事件表

信件内容表

匿名信表

笔友信表

时间胶囊表

---

2.类图

2.1实体类

详细说明

用户：用户号，手机号，密码，用户昵称，用户心情，成长值，用户状态，创建时间，修改时间

举报：举报号，举报用户号，信件号，信件类型，举报信息，举报时间，受理时间，是否受理

签到奖励：奖励号，奖励类型，奖励描述，奖励值，奖励创建时间，奖励修改时间

反馈：反馈号，反馈用户号，反馈信息，反馈时间，是否受理，受理时间

邮票：邮票号，邮票标签，邮票面值，邮票图像地址

匿名信：信件号，发信人号，信件内容号，信件创建时间，信件标题，信件的热度值/生命值，心情等级，喜欢人数，拥抱人数，父级信件的号，信件更新时间，是否阅读

时间胶囊：信件号，发信人号，信件内容号，信件创建时间，信件标题，逻辑删除状态，信件修改时间，送达时间，收信人号，是否阅读

笔友信：信件号，发信人号，信件内容号，送达时间，信件标题，突发事件号，信件创建时间，信件修改时间，是否已读，是否逻辑删除

信件内容：信件内容号，内容

突发事件：事件号，事件名称，发生概率，延迟时间，事件描述

管理员：管理员号，用户名，密码，状态

管理员角色：用户名，角色

日志：日志号，用户号，用户类型，概述，创建时间，操作状态，是否已读，修改时间

通知消息：消息号，用户号，通知信息，类型，创建时间，是否阅读，更新时间

2.2MVC架构类

---

3.接口设计

3.1 接口设计规范

项目的接口设计主要分为移动端和web端两个部分，严格遵循了RESTful规范，具体规范如下：

• 域名：用api关键字标识接口url

• 路径：api的具体网址中不包含动词，只能有名词

• 对资源的具体操作类型：

  • GET
  • POST
  • PUT
  • DELETE

• 返回状态码：使用标准HTTP状态码

好处：

• URL具有很强可读性的，具有自描述性；
• 资源描述与视图的松耦合；
• 可提供OpenAPI，便于第三方系统集成，提高互操作性；
• 如果提供无状态的服务接口，可提高应用的水平扩展性；

3.2 接口总览

主要分移动端和后台两个部分。

4.系统安全和权限设计

4.1系统安全性设计说明及解决方案

针对系统可能产生的安全问题进行分析与说明

4.1.1CSRF(跨站请求伪造)

问题：

• CSRF 用户A请求了正常的网站C，之后产生了cookie保存在客户端，之后用户A又浏览的恶意网站B，网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点C，恶意网站B产生恶意的请求去请求网站C，由于cookie是浏览器自动携带的结果C只能看到cookie是正确的，以为就是用户A的行为，从而产生损失。

目前防御CSRF有四种方案：

• 验证 HTTP Referer 字段
• 在请求地址中添加 token 并验证
• 在 HTTP 头中自定义属性并验证
• 验证码

服务器采用jwt鉴权方式，其内部实现用户通过账号密码登入，登入成功后服务器会颁发token给前端，前端存储token并且在每次请求手动把token加在http的请求头上，服务器对jwt解析获取相应信息进行鉴权，服务器没有采取传统的session-cookie机制进行鉴权，同时token为前端在每次请求手动的添加上就不存在跨站请求伪造的问题。

4.1.2XSS攻击

问题：

• 跨站脚本攻击（Cross Site Script为了区别于CSS简称为XSS）指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。

解决方案：

• 服务器不会直接信任用户传输的数据，会设计一个Xss过滤器专门来过滤可能存在的XSS攻击。

4.1.3SQL注入

问题：

• sql注入是指在sql语句预编译过程中混入了恶意sql代码导致sql错误执行，以不正当的手段多数据库信息进行操作。

解决方案：

• 后端会对要执行的sql语句进行预编译，保证预编译过程没有用户传来的参数，且执行的时候只需传参不会再次进行编译，不会导致恶意sql执行。

4.1.4数据加密

问题：

• 对用户密码等数据采用SpringSecurity中BCryptPasswordEncoder类通过SHA-256+随机盐+密钥对密码进行加密。

解决方案：

• 特点：通过hash算法加密每次加密后的密文都不相同且不可逆，保证了用户密码不能被解密，且通过匹配算法匹配未加密密码与加密后密码是否相同。

4.1.5JWT主动失效

问题：

• 使用Jwt有许多好处但缺点也相应而来，由于Jwt的无状态性服务器只知道这个token是否合法以及是否过期，存在一定程度局限性，因为服务器不知道此时token是否有效，例如如果用户账号密码被盗，由于Jwt的无状态性，服务器会在一段时间内都认为jwt有效，此时用户修改密码，并不能使之前以及颁发过的token失效，就存在安全漏洞。

解决方案：

• 我们在 项目中的方案使用Jwt黑名单策略。例如在注销等场景将该token加入黑名单。当用户发出请求后， 如果该token在黑名单中，则阻止用户的后续操作，返回Invalid token 错误。对于名单的维护使用redis，token的过期时间和redis中数 据的存活时间保持一致。

Jwt的状态图

模拟用户修改密码Jwt失效活动图

4.2权限设计与鉴权说明

• 认证策略：服务器采用SpringSecurity框架+jwt令牌以及使用redis认证方式，Jwt通过签名加密的方式保证不被其他人仿造颁发jwt。
• 鉴权：采用SpringSecurity框架对每一个接口限制权限，只有具有相应权限的用户才能调用相应的接口且通过jwt存储的用户信息对私人内容进行鉴权；同时jwt是无状态的，因此通过redis维护黑名单使jwt主动失效。
• 权限设计：项目分三种角色 用户，管理员，超级管理员，每个角色有相应的权限，具有相应的权限才能访问相应的方法
• 用户可通过前台App操作相应的笔友模块，信箱模块，时空胶囊模块和主页模块。
• 管理员可通过后台Web对用户账号管理，平台数据分析，以及反馈举报处理，以及应用管理。
• 超级管理员：超级管理员在管理员的基础可以对管理员账号进行管理

---

5.改进分析

Q1:用户类的”今日心情“属性需要记录历史的今日心情吗？如是的话，作为一个属性是否合适？

A:用户类的”今日心情“没有记录历史的今日心情，用户的今日心情用户对今日的匿名信箱收信的时候的算法匹配，没有对历史的心情进行分析。

Q2:邮票只在用户中设立一个属性是否合理是否要抽象一个类代表不同面值?

A:项目需求分析阶段并没有考虑到邮票这方面的处理，小组讨论过后为了更加贴近现实送信且认为这是一个特色且为一个可玩性较强的建议，采纳并且在项目中增加了相应的设计。

Q3:任务的分配是如何进行的呢？比如由哪位同学担任组长身份然后分配任务？有没有定一个各模块（比如前、后端）的负责人?

A:任务的分配过程是通过每次作业的第一次会议对任务进行拆分为一个个大模块，并且对每一个模块设立一个负责人，例如在需求分析的作业中会设立原型设计的负责人，需求分析的负责人等等，由黄欧成同学担任组长分配模块人物且指定模块负责人，再通过组长与模块负责人讨论拆叫模块内小人物。

Q4:用例图include错误使用且将用例组织成操作流程。

我们对用例图进行了修改，对include使用错误的地方进行了更正，修改后用例图如下——

Q5:类图中的"用户"类的操作与用例混淆。

我们对类图进行了修改，对“用户”类的操作进行了更正，修改后“用户”类如下——

Q6:后台在配色和布局上可以再做一些优化.

A:后台配色和布局已经做了一些调整，取了前台配色，同时使用相近颜色作为补充和修饰，布局上调整了一些细节，整体遵从网页设计规范，进一步完善了原型。

---

6.团队绩效

6.1工作流程

• 使用工具：
  • 腾讯文档：《系统设计说明书》及《数据库设计说明书》的编写
  • ShowDoc：接口文档的编写
  • Xmind：绘制功能模块图
  • gitcode：文档上传
  • startUML：完善类图
  • 社群讨论：确定分工及撰写部分整合、贡献度分配

文档编辑记录

6.2组员分工及贡献度比例

学号	姓名	工作内容	贡献度
221900217	黄欧成	数据库设计，数据库设计说明书编写，系统设计说明书编写，博客编写，答辩ppt制作，答辩ppt演讲，开会考勤	14.500
221900422	王彬	系统设计说明书编写，开会考勤	7.750
221900420	沈启航	系统设计说明书编写，数据库设计说明书编写，数据库设计，答辩ppt制作，开会考勤	14.460
221900214	何震东	系统设计说明书编写，数据库设计说明书编写，数据库设计，开会考勤	8.000
221900428	杨鸿	系统设计说明书编写，开会考勤	11.044
221900122	苏海元	系统设计说明书编写，开会考勤	8.570
221900336	洪曙新	答辩ppt制作，系统设计说明书编写，出勤	9.356
221900203	伍泳乐	系统设计说明书编写，开会考勤	8.570
221900227	叶林忠	系统设计说明书编写，开会考勤	7.750
221900238	巫舒静	博客撰写，开会考勤，系统设计说明书编写	10.000

---

7.开发计划安排

7.1团队项目的预期开发计划时间安排

时间	产出成果	里程碑
第一周（4.10-4.16） 数据库和系统设计	系统设计说明书 数据库设计说明书 系统设计和数据库设计答辩PPT 团队项目预期开发计划时间安排及分工安排 原型设计完善 部分功能补充	数据库和系统设计完成
第二周（4.17-4.23） 小组技术学习及开发框架熟悉	开发框架熟悉并删除冗余代码 对需要用到的开发语言进一步学习	开发流程全部安排完成
第三周（4.24-4.30） alpha冲刺第一轮	前台登录注册模块 前台信箱模块 前台胶囊模块 前台主页模块 后台管理系统管理员账号管理模块 后台管理系统管理员反馈中心模块
第四周（5.1-5.7） alpha冲刺第二轮	前台信箱模块完善 前台笔友模块 后台管理系统超级管理员模块 后台管理系统管理员应用管理模块 后台管理系统管理员数据分析模块	Alpha版本完成
第五周（5.8-5.14） 软件测评	进行软件测评
第六周（5.15-5.21） 软件测评	完成软件测评 准备答辩相关	软件测评完成
第七周（5.22-5.28） beta冲刺第一周	Alpha版本功能完善 完善个人主页中心模块细节 测试模块功能 进行前后端整合
第八周（5.29-6.4） beta冲刺第二周	添加信封解锁功能 前后端整合测试 整体测试 优化代码
第九周（6.5-6.11） beta冲刺第三周	对算法适配效果进行测试 继续完善功能 测试功能
第十周（6.12-6.18） beta冲刺第四周	优化代码 对页面适配效果进行调整 测试功能 准备汇报答辩	Beta版本发布

7.2团队项目的预期开发计划分工安排

学号	姓名	分工角色	Alpha冲刺	Beta冲刺
221900203	伍泳乐	Android端	Android端笔友模块开发 Android端胶囊模块开发	笔友模块测试 胶囊模块测试 整体测试
221900122	苏海元	Android端	Android端信箱模块开发 Android端主页模块开发	信箱模块测试 主页模块测试 整体测试
221900428	杨鸿	Web端、微信小程序	Web端反馈中心、数据分析、应用管理-人工审核页面 微信小程序笔友模块	所做功能测试 整体测试
221900336	洪曙新	Web端、微信小程序	Web端登录、账号管理、应用管理-奖励池、应用管理-突发事件页面 微信小程序信箱模块	所做功能测试 整体测试
221900238	巫舒静	微信小程序	微信小程序登录、时空胶囊模块、主页模块	所做功能测试 整体测试
221900227	叶林忠	后端	信件推送算法，心情匹配算法，信件内容过滤算法	算法应用效果分析 整体测试
221900217	黄欧成	后端	用户管理模块，信件功能模块，后台数据分析模块	用户管理模块测试 信件功能模块测试 后台数据分析模块测试 整体测试
221900422	王彬	后端	信件推送算法，心情匹配算法，信件内容过滤算法	信件推送模块测试 心情匹配模块测试 信件内容过滤算法效果分析 整体测试
221900420	沈启航	后端	用户管理模块，信件功能模块，后台应用模块	用户管理模块测试 信件功能模块测试 后台应用模块测试 整体测试
221900214	何震东	后端	用户管理模块，信件功能模块，后台应用模块	用户管理模块测试 信件功能模块测试 后台应用模块测试 整体测试

8.相关链接

《系统设计说明书》、《数据库设计说明书》、答辩PPT

• gitcode团队仓库链接

[221900420_沈启航]

@Jingbin-Wang 回复问题1： 笔友表即ums_user_user_relation表，字段包括主键id，用户1id，用户2id，关系创建时间，关系变化时间，关系状态，用户id与用户表id有外键关联关系，关联级别为级联修改和删除。 回复问题2：举报类不算特殊的反馈类。类图中的举报类仅针对信件进行举报，会涉及到信件内容，用户信息。反馈类是包括应用漏洞、产品建议等用户的产品使用反馈信息。二者在后台都会进行管理。 回复问题3：表的命名规则在《数据库设计说明书》的2.3中有明确说明。表的命名规则会根据：1. 业务模块 2. 表的逻辑关系 3. 阿里巴巴的数据库表命名规则进行命名。

[Jingbin-Wang]

有笔友表吗，具体结构？
举报类是特殊的反馈类？
数据表的命名要求是否有在文档中进行说明？