Concerto——项目系统设计与数据库设计
| 这个作业属于哪个课程 | 课程 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 团队名称 | Concerto |
| 这个作业的目标 | 完成原型设计 原型设计答辩PPT 项目需求规格说明书 需求汇报PPT |
预期开发计划时间安排
| 时间 | 开发安排 | 参与者 |
|---|---|---|
| 4.27-5.2 | 安卓端：完成界面的样式 | 蔡晗 李博威 王铭震 林雄 |
| 4.27-5.2 | ios：完成基本界面的样式 | 吴尚辉 |
| 4.27-5.2 | 后端：个人模块开发 | 林逸晖 |
| 4.27-5.2 | 后端：任务模块开发 | 吴世龙 |
| 4.27-5.2 | 后端：项目模块开发 | 陈晓暄 |
| 5.2 | 部署测试 | 吴世龙 陈晓暄 林逸晖 |
| 5.2-5.5 | 前后端交接调试 | 吴世龙 陈晓暄 林逸晖 吴尚辉 蔡晗 李博威 王铭震 林雄 |
| 5.6 | 一期开发工作完成 | -- 里程碑 -- |
| 5.8-5.31 | 一期开发工作总结，二期开发工作规划 | 吴世龙 陈晓暄 林逸晖 吴尚辉 蔡晗 |
| 6.1-6.3 | 二期开发需求，前后端文档 | 吴世龙 林逸晖 吴尚辉 |
| 6.1-6.3 | 需求原型调整 | 吴世龙 陈晓暄 |
| 6.4-6.11 | 安卓端：完成二期的样式 | 蔡晗 李博威 王铭震 林雄 |
| 6.4-6.11 | ios：完成二期界面的样式 | 吴尚辉 |
| 6.4-6.10 | 任务回滚实现 | 吴世龙 林逸晖 |
| 6.4-6.10 | 任务留言系统 | 陈晓暄 |
| 6.4-6.10 | 日程推荐算法改进 | 林逸晖 |
| 6.4-6.10 | 项目性能分析改进 | 吴世龙 陈晓暄 林逸晖 |
| 6.11-6.12 | 部署测试 | 吴世龙 陈晓暄 林逸晖 |
| 6.12-6.15 | 前后端交接调试 | 吴世龙 陈晓暄 林逸晖 吴尚辉 蔡晗 李博威 王铭震 林雄 |
| 6.18 | 二期开发工作完成 | -- 里程碑 -- |
预期开发计划分工安排
| 姓名 | 分工 |
|---|---|
| 吴世龙 | 协同后端开发 基础任务模块开发 |
| 陈晓暄 | 项目模块开发 |
| 林逸晖 | 个人模块开发 |
| 吴尚辉 | iOS端开发 |
| 蔡晗 | 协同安卓端开发 任务详细表单、任务编辑记录、新建任务 |
| 李博威 | 登录、注册、个人信息表单 |
| 王铭震 | 我的项目、我的 |
| 林雄 | 个人日程、项目详情页 |
| 邵研 | 已失联 |
结构设计
功能模块层次图
用户模块
用户模块主要包括登录注册和用户个人信息的管理还有个人日程模块。
用户的个人日程是根据用户所参与的项目中用户需要参与的任务生成的
推荐日程就是通过对每一个用户参与的任务的紧急程度 开始时间 结束时间 三项加权算出的一个值，通过这个值将任务从高到低排序。排在顶部的就是系统认为用户应该优先完成的任务。
在个人日程模块中可以调用更新任务状态的模块改变任务的状态。
项目模块
管理项目参与人员的模块包含查看项目参与人员和处理人员加入申请的模块
用户想要加入一个模块需要先调用加入项目模块 然后项目管理员调用处理加入申请模块
当项目管理员同意了用户加入申请后用户才可以进入项目。
任务模块
除了简单的修改任务信息的模块之外，还包含版本管理和添加子任务
任务的版本管理主要是防止用户的误操作导致任务信息的丢失。同时又记录了操作记录。使得同一项目的其他参与者可以看到是谁做的修改。
版本管理运算流程：在任务创建以及任务修改时，基本简单信息通过版本副本进行存储，tag以及参与者则记录相应的增加和删除操作。在版本回退时对操作进行相应的回滚。
ER图与表结构
ER图
设计思路
以类图为参照，研究类图之间的关系。先找到系统中关键的三个类-user,project,task类，先分开画这三个类的ER图，最后进行ER图合并。
ER图结构：层次结构。user类->project类->task类，这三个是主干，其余类属于各个层次的分支。
表结构
1：用户表 user
2：用户意见关联表 user_advice
3：系统消息表 message
4：项目表 project
5：用户项目关联表 user_project
6：任务表 task
7：任务版本表 task_version
8：用户任务关联表 user_task
9：项目任务关联表 project_task
10：标签表 tag
11：任务标签关联表 task_tag
12：任务子任务关联表 task_subtask
13：任务留言表 task_comment
14：任务参与者操作表 task_paticipant_operation
15：任务tag操作表 task_tag_operation
类图
设计思路
最重要的类为User、project和task，先构思出这三者之间的关系，再围绕这三者的作用抽象出其他的类。
一个用户可以与多个项目/任务关联，可以通过user_advice向开发者提供建议，通过message接收推送的消息，通过task_comment留言评论。
任务本身可以包含子任务（子任务也是任务）。
taskVersion类是task类的组成部分，用以记录某个任务版本的信息，可用来支持版本回滚等功能。
系统安全和权限设计
1.用户登录认证
用户在注册时，系统将用户密码进行加盐处理。用户在登陆的时候，系统将用户密码进行加密计算，如果与数据库中存的密文一致，则用户登陆成功。
2.设置token确认用户身份
用户登录校验，校验成功后就返回Token给客户端，客户端每次访问API是携带Token到服务器端。
对于每一次访问操作服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
3.防止用户直接操作数据库
用户只能通过给定的外部接口操作数据库。
4.对有关信息进行加密
对数据库中有关表和字段信息的进行加密、解密处理，保证传输的时候的信息安全性。
5.在app内将用户分角色，进行操作和权限的控制
对于所有用户,可以将进行注册登陆 修改自己的个人信息的操作。
对于某个项目成员，可以获取项目信息 任务信息 修改任务、任务状态。
对于项目创建者，可以进行批准人员进出的操作。
问题与改进
-
任务与子任务之间为什么需要一张关联表进行关联
因为设计经验不足，对于表的设计理解还需要欠缺，后面我们将会在任务中添加一个par_task_id字段来记录任务与子任务的关联，删除任务与子任务的关联表 -
任务子任务的组合模式没有一个一个抽象的类，具体的任务类会暴露
因为设计的时候叶子结点只有任务，所以在设计的时候没有想到用一个抽象类来进行模块之间的分层，后面将会针对任务的特征以及后面项目的拓展进行一定的调整。
工作流程与成员贡献度
本次的工作流程：
- 首先由组长、前端组长和后端组长来对前后端文档进行初步的确定，粗略地列出了所有的API、参数列表以及返回体。
- 由组长和后端组长来初步确定了数据库的表以及表的逻辑结构
- 每个成员负责一部分文档工作，主要是针对API与表来对类图、ER图、数据流图进行相应的绘制，以及对于接口进行整理。
- 在成员初步完成之后，由组长，后端组长对文档进行调整工作。
- 由组长进行整合工作
| 学号 | 姓名 | 工作内容 | 贡献度 |
|---|---|---|---|
| 2281801317 | 吴世龙 | 讨论API文档 数据流图 文档内容整合调整 PPT | 12.5 |
| 2281801431 | 陈晓暄 | sql建表 数据表拓扑图 数据库设计约定 | 12.5 |
| 081700318 | 林逸晖 | 讨论API文档 安全设计 文档内容调整 | 13 |
| 021800713 | 林雄 | 类图 类图设计思路 部分API接口整理 | 13.5 |
| 221801322 | 蔡晗 | 部分API接口整理 | 12.5 |
| 021800623 | 王铭震 | 用例图 用例图设计思路 部分API接口整理 | 13.5 |
| 081800330 | 吴尚辉 | 讨论API文档 整理API文档会议记录 | 10 |
| 221600234 | 李博威 | 评审表 部分API接口整理 | 12.5 |
| 221701105 | 邵研 | 0 |
