| 这个作业属于哪个课程 | <2020 春 W 班 (福州大学)> |
|---|---|
| 这个作业要求在哪里 | <作业要求> |
| 这个作业的目标 | 系统设计和数据库设计 |
| 作业正文 | <作业正文> |
| 其他参考文献 | <《构建之法》> |
part.01 团队预期开发计划时间安排
在完成本周的系统设计和数据库设计的作业之后，将进入代码实现部分。我们的计划安排如下：
| 时间 | 安排 |
|---|---|
| 04.12-04.19 | |
| 参考开源的优秀项目，完成项目的搭建，初步决定采用的第三方库并完成导入和测试。 | |
| 04.20-04.26 | |
| 后端：初步实现发布任务、失物招领、物品租赁三个模块的接口。 | |
| Web前台：初步实现发布任务、失物招领、物品租赁三个模块的界面。 | |
| Web后台：初步实现发布任务、失物招领、物品租赁三个模块的界面。 | |
| Android：初步实现发布任务、失物招领、物品租赁三个模块的界面。 | |
| 04.27-05.03 | |
| 后端：完善项目，并将后端部署到服务器，协助前端完成数据的交互。 | |
| Web前台：完善项目，与部署在服务器的后端进行交互。 | |
| Web后台：完善项目，与部署在服务器的后端进行交互。 | |
| Android：完善项目，与部署在服务器的后端进行交互。 | |
| 05.04-05.10 | |
| 后端：根据开发过程遇到的问题，对项目的细节进行优化。 | |
| Web前台：优化项目，并将Web端部署到服务器。 | |
| Web后台：优化项目，并将Web端部署到服务器。 | |
| Android：优化项目，并将Android端打包，发布到应用商店。 | |
| 05.11-05.17 | |
| 测试，小范围推广，优化，针对bug版本更新。 | |
| 05.25-05.31 | |
| 测试，大范围推广，维护，针对bug版本更新。 | |
| 05.18-05.24 | |
| 根据用户反馈，评估项目的合理性，对项目的功能进行调整和扩充，版本更新。 | |
| 06.01-06.07 | |
| 维护 |
part.02 预期开发计划分工安排
| 学号 | 安排 |
|---|---|
| 221701412 | 主导完成后端的架构，发布任务功能模块的开发。 |
| 221701414 | 负责Android部分的开发。 |
| 221701417 | 深入到潜在用户中进行调研、推广、收集用户反馈。参与前端界面的设计。 |
| 221701418 | 负责Web前台的开发。 |
| 221701420 | 负责Web后台的开发和维护。协助Web前台开发。 |
| 221701429 | 熟悉前后端的工作进度，参与后端数据库的开发，接口文档的撰写和维护。 |
| 221701431 | 主导数据库的设计和维护，完成后端失物招领和物品租赁模块。 |
| 221701439 | 对前后端的程序进行充分的测试，生成测试文档。 |
part.03 设计图及描述
体系结构设计
功能模块层次图
设计类图
ER 分析图
表结构设计
（列举部分）
用户表
管理员表
失物招领物品表
评论表
敏感词表
举报表
系统安全和权限设计
本数据库经由使用者名称及密码认证使用者的登入，若使用者名称有效且密码正确则建立联机。同时，登入者们有三种不同的数据库存储权限。
1.拥有者权限:对于数据库、使用者或对象建立所在的空间，系统将拥有权授予该空间的拥有者。拥有者为建立新对象的使用者或数据库(在 CREATE DATABASE / CREATEUSER 陈述的 FROM 子句中指定)。例如，数据表的拥有者具有隐含的权限，能够准许(GRANT)它自己对于其所拥有的数据表有 SELECT 的特权。
2.自动产生的权限:此为系统自动授予数据库、使用者或对象的建立者的权限，及授予新建的使用者或数据库的权限。
3.显示授予的权限:此为由任何具有 WITHGRANTOPTION 特权的使用者所授予的权限。显示授予(通过命令显示地以陈述方式授予)的权限可使用 Teradata 的 SQL GRANT 命令来授予。
同时使用数据库存取日记进行安全管理：
通过存取日志记录使用者在数据库中的所有活动，如果使用者尝试存取某一数据库对象，且该对象已包含在目前的日志定义中，则系统会记录其使用者识别码、对象名称及此一存取动作是否被相应的存取权限所允许。所使用的 SQL 语句也可以选择性的被记录下来。
设计思路
前后端完全分离，仅通过http接口进行交互，实现各端完全透明，代码的维护升级互不干扰，使用mysql + springboot + html + Android + vue进行开发。
part.04 本次作业队员贡献度
-
为了调动成员积极性，增加团队成员之间的配合以及加强在今后的合理分工，本团队从本次开始，引入对成员分工的工作进行加权，用文档记录，最后按总权分配贡献比。
-
团队分工文档下载：<团队分工文档>
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221701412 | 系统设计和数据库设计答辩 PPT（1）、进行答辩（1）、类图设计（1）、参与各部分修改与建议（0.5） | 17.5% |
| 221701414 | 编写完成博客（2)、参与各部分修改与建议（0.5） | 12.5% |
| 221701417 | 答辩打分（1）、系统设计和数据库设计评审表（1）、记录 Q&A 记录（0.5）、系统设计和数据库设计答辩 PPT（1） | 17.5% |
| 221701418 | 系统设计说明书（2） | 10% |
| 221701420 | 泳道图（1）、数据流图（1） | 10% |
| 221701429 | 数据库设计说明书（2） | 10% |
| 221701431 | 数据库设计说明书（2） | 10% |
| 221701439 | 系统设计说明书（2）、记录 Q&A 记录（0.5） | 12.5% |
Part.05 答辩汇总
选题答辩
-
1.平台是否支持校友租赁物品？
- A：不支持校友，已步入社会的校友加入，会增加很多隐患，使用 orc 读取校园的学生卡和教师卡，仅支持在校师生使用，可以写一个 Timer 定时器，一年更新一次数据库的用户，对于正则匹配的学号往后移 3 年已过期的用户将限制其功能的使用。
-
2.这些平台重要的是“维护者”，这一点如何保证？
- A：在本团队成员在校期间，我们是维护者，当我们离校后现在的打算是传给学弟学妹们继续维护，一代一代的维护。后续我们会考虑产品的商业盈利问题，有了收益，更有利于维护和发展。
-
3.往届做类似产品的很多，但是限于时间和技术，都无法开发出预期的所有功能，你们有做技术可行性分析吗？
- A：团队成员项目经验较同级一些同学相对来说要丰富，有在 ppt 中展示，且这次产品考虑的主要的三个模块，在以前团队的成员都有写过类似，这次的开发主要是建立在复用以前代码基础拓展新的功能且优化，有较大可行性。目前团队已经开始着手准备这一项目。
-
4、新的思考
- A：作为旗山的骄傲，我们是一个团队，在开发中需要始终保持一致的目标、明确的分工。我们的目标是开发出一个可维护、可迭代、可投入现实中使用的产品。为此，我们开始着手准备相关的知识。
原型答辩
-
1.租赁涉及到费用，如何交易？
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成。
-
2.如何处理交易争端？(租赁的物品被损坏并且租赁方不认为是自己的问题)
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成，如果出现租赁的物品被损坏并且租赁方不认为是自己的问题，本平台可为双方的交易争端提供平台的聊天内容作为证据。
-
3.对于涉密等敏感话题，打算采用什么算法？
- A：对于涉及涉密等敏感话题，主要通过两个途径，一个是管理员在后台的初步审核，一个是在答辩老师提醒增加的举报功能，在前台界面当一条疑似涉密等敏感话题的发布举报次数达到一定次数（如 100 次）时，逻辑处理模块会将此条发布在后台报警，以进行人工核实。
-
4.是否涉及押金？
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成，所以本平台并不涉及押金。
-
5、平台涉及的交易如何完成？
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成。
-
6、建议平台能提供举报这一功能。
- A：在答辩老师提醒增加的举报功能，在前台界面当一条疑似涉密等敏感话题的发布举报次数达到一定次数（如 100 次）时，逻辑处理模块会将此条发布在后台报警，以进行人工核实。
需求分析答辩
-
1、单独设立 失物招领 和 寻物启事 两个类，是否存在重复，这样的关系是否准确。
- A：不重复，因为这两个东西容易混淆，考虑到易于理解性，并且两个类含有的属性并不完全相同，我们决定将这两个类分开。
-
2、在发布任务功能，一个任务要体现发布任务者和领取任务者吗？
- A：我们的目标是提供一个发布信息、获取信息的平台，原则上只对涉及违规违法的敏感信息进行处理，不会干涉任务的处理进度。比如：某个用户在朋友圈发布了一条任务信息，另外一个用户获取任务信息后想要领取任务，对于领取任务这些具体的细节交由双方通过发布的信息中留下的联系方式，自行协商。
-
3、类似的物品租赁类的属性是否不够？
- A：我们已经在任务详情中对属性进行了补充。
-
4、如果不记录谁完成的话对后续信誉记录什么的会有影响吗？
- A：针对这个问题，我们增加了举报功能，对于破坏信誉的行为，用户可以在举报功能中，上传相关的信息，经后台审核后，对被举报的账号进行封号等操作，对于涉及违法的问题，会提供相关信息，协助举报人报警。
-
5、敏感词建议单独放一张表。
- A：感谢老师提出建议，我们在系统设计的时候做出了相应的修改。
Part.06 github仓库地址以及下载链接
-
Github 团队仓库链接：<点击进入>
-
旗山的骄傲_系统设计说明书.pdf：<点击下载>
-
旗山的骄傲_数据库设计说明书.pdf:<点击下载>
-
旗山的骄傲_系统设计和数据库设计答辩 PPT.pdf: <点击下载>
Part.07 本项目目前的全部附件
如果您觉得一个一个下麻烦的话，可以在这里下载本项目目前的全部附件
-
本项目目前的全部附件下载（百度云链接：提取码（yjuf)）：<本项目目前的全部附件>
Part.08 本次答辩的评审表
-
项目系统设计与数据库设计评审表：<点击进入>
Part.09 本次答辩Q&A回答以及对答辩的补充
-
汪老师：
-
1、此处使用继承，请解释一下，能否考虑用组合？
- A:此处使用继承是因为在分析阶段的类图在提取需求时，这三个实体类均有公共的属性，于是提取了一个发布的总类类作为父类型，然后继承下去三个子类型再实现对应不同属性，所以此处使用继承，组合关系中的整体直接掌握部件的生灭，聚合关系中的整体并不具有生灭部件的权力。一旦组合中的整体不存在时，其组合部件也不能单独存在，必须同时消灭。另外，外界也不能直接与部件沟通，必须通过整体代为传达消息。然而在此系统中子类型仍与其他的部分有直接的关联，所以本小组讨论后还是认为使用继承更为恰当。
-
2、虚线表示什么含义？
- A:ER图的虚线应该是表示week entity，即需要借助外键和标有虚线的partial key来确定的实体，但是在之前的这个ER图的该场景这样使用并不恰当，现已在博客上传了修改后的版本。
-
傅老师：
-
1、举报表没有涉及user_id?
- A:举报表没有涉及user_id，在之前是打算设计为由举报表的table_id在对应的发布类的表查询对应的user_id，即进行一个多表查询，在答辩后小组有对此设计进行讨论，认为在后续的开发阶段应该在举报表加入user_id，这样的设计明显更为合理。
-
2、实体之间的关系没有标注
- A：实体之间的关系现已进行标注，现已在博客上传了修改后的版本。
-
乐助教：
-
1、总的来说设计的不错；评审表布局可以稍微优化一下；ER图绘制的不太规范
- A：评审表布局现已进行了一定的调整，er图确实绘制的不规范现已在博客上传了修改后的版本。这次我们小组拿出的成果确实有一些不尽人意的地方，现已在博客更新了第九部分对答辩q&a进行回答以及对一些我们组认为在答辩中不足的地方进行了一定补充，我们在下次将吸取问题教训在继续发挥我们的长处的同时改正问题，我们会加油的！！！
-
对于答辩的一些补充：在答辩阶段并没有给出具体的接口设计，本着得尽量完整每一次的设计，这样才能将这样的一个完整的项目环环相扣的设计下去，在此博客里我们小组还是重新给出了接口设计，亡羊补牢为时应该不晚！！
