系统设计和数据库设计

这个作业属于哪个课程 <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 语句也可以选择性的被记录下来。


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 文档汇总



猜你喜欢

转载自www.cnblogs.com/thePrideOfFlagHill/p/12660833.html