呜呼啦呼队——项目系统设计与数据库设计

这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/SE2020
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/SE2020/homework/11447
这个作业的目标	进一步细化团队的开发计划和时间计划 细化组员分工

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

周数	任务	目标
11	数据库设计、系统架构设计学习、微信小程序的开发	系统设计计划书，数据库初步设计
11	根据具体分工进行具体知识	原型最终定稿，后端接口文档
12	开始着手编程	小程序前端基本完成，前后端交互后基本完成目标
13	小程序上线测试	根据用户使用反馈改BUG

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

成员	分工
021800527施颖辉	后端架构设计、数据库设计，后端测试
031802507邓家俊	基础页面设计，会议记录
031802243张建娴	UI设计，前端代码编写
031802438张佳侨	页面逻辑设计，答辩PPT制作
031801125黄雨晨	UI设计，前端代码编写，博客编写
031802129吴涣祺	后端架构设计，Vlog制作
031802133谢林煌	后端算法模块，后端测试
031802642郑孙健	基础页面设计，答辩
031802420刘任世麒	博客编写
031802218廖启涵	前端测试

体系结构设计图

功能模块层次图

设计类图

E-R分析

表结构设计

用户表，用于存储用于登录所需要的相关信息

甜蜜券表，用来登记发券模版或者自定义信息

恋爱小报，用于生成恋爱小报

甜蜜券记录表，用于存储用户的历史收发甜蜜券的记录

甜蜜券赠送表，用于记录赠送对象和甜蜜券的关系

甜蜜券账户表，用于鉴定用户是否可以发送甜蜜券

账单表，用于存储甜蜜券收发的日期

赠送流水表，用于关联账单表和记录表

记录录入时间表，用于登记恋爱小报特定信息

设置预设表，存储用户偏好以用于推荐

用户个性表，用于记录用户个性化设置

系统安全和权限设计

5.1 异常设计

客户端封装异常处理类

（1）微信小程序官方提供的API，在发生异常时，均会通过回调函数fail回传错误信息。如果我们能采集这些数据，进行统计分析能有这些作用：为后续技术优化提供指导方向
（2）了解用户设备的兼容性，预防踩重复的坑由于官方提供的API，所有的异步方法都需要手动传入fail，因此手动给每个方法传入fail可能是不可行的。另外，小程序的更新频率很高，每隔一段时间就会出现许多新的API。因此，最佳的实践即是封装全局对象。

服务端异常处理

服务端我们采用node.js的express框架来编写代码。所以使用express异常处理中间件这个中间件有四个函数，按顺序分别是err,req,res,next，当程序发生异常时，就会执行异常处理中间件的回调函数

5.2 可用性

（1）方便操作，操作流程合理。尽量从用户角度出发，以方便使用本产品。
（2）控制必录入项。本系统能够对必须录入的项目进行控制，使用户能够确保信息录入的完整。同时对必录入项进行有效的统一的提示。
（3）容错能力。系统具有一定的容错和抗干扰能力，在非硬件故障或非通讯故障时，系统能够保证正常运行，并有足够的提示信息帮助用户有效正确地完成任务。
（4）操作完成时有统一规范的提示信息。例如删除操作时，系统可提示警示框“您确认删除记录吗？操作不可恢复！”，用户点击确认后，系统才执行删除操作，删除后可直接返回相关页面。

5.3 安全性

（1）权限控制根据自己的需求，我们可以让自己允许的人得到自己的位置信息，除此之外，我们的信息采用的是覆盖的方法，不会对用户的位置信息得到保留。
（2）重要数据加密对一些重要的数据按一定的算法进行加密，如用户口令、重要参数等。
（3）数据备份允许用户进行数据的备份和恢复，以弥补数据的破坏和丢失。
（4）记录日志本系统应该能够记录系统运行时所发生的所有错误，包括本机错误和网络错误。这些错误记录便于查找错误的原因。日志同时记录用户的关键性操作信息。

设计思路

（1）通过小程序特有的框架进行基础的页面设计，首先明白小程序框架的独特性，每个页面都得在app.js中进行注册。在这个基础上，应用插件功能，封装每个页面类似的代码，进行快速的前端页面设计
（2）小程序后端框架没有什么特别的要求，在小组成员熟悉的语言中，我们敲定了Java的spingboot，通过后端与mysql数据库的连接，进行快速迭代生成。并在后端配置的问题上，要严格注意跨域的问题，以及数据表索引的建立。
（3）将以小程序上线的方式上线小程序进行bug手机以及用户反馈，进行快速的代码更新。

回答上次作业中大家提出的问题

其他队伍的问题

Q1、答辩收集使用的资料应该有更有专业性 ，准确性
A1:关于这个问题，我们在之后的答辩中会注意选择更具专业性、更权威的信息。但作为小程序的设计，我们认为应该把对专业性和准确性的关注放在设计本身，而不是其他内容上。

Q2:小程序功能是否可以适当增加？
A2:我们设计这个小程序是为了增加恋爱中的仪式感，更好地维系情侣之间的关系，例如在吵架时作为和好的工具，它不需要太多很复杂的功能（那些功能在情侣空间等其他情侣间的应用上都有啦hh)，当然我们在之后的过程中也会讨论是否可以增加其他的功能，也欢迎大家给我们提建议~

Q3:发劵能否切实解决矛盾，线上交流比线下交流是否更有效？ 是否会演变成以劵求和解走形式？
A3:情侣之间并不能总是待在一起，特别是对异地情侣来说，线下的交流比较困难，有时矛盾之所以解决不了，是因为双方都没有找到合适的方式，都碍于面子不愿意道歉认错，此时线下的见面反而会使矛盾的解决变得缓慢且尴尬，通过线上隔着屏幕的方式，以发券为契机，反而有利于双方冷静地看待并解决矛盾。对于是否会演变成以劵求和解走形式，这就取决于恋爱双方了，一千对情侣有一千种相处模式，但我们相信并希望发送券的一方是满怀真挚的情感送出DIY券的，因为当送券成为了一种没有情感的形式主义，这个小程序对他们也就没有意义了。

Q4:用户数据安全性如何保障？所谓冷静期如何实现？如果通过所谓券的形式久而久之是否会太单调？
A4:我们对数据库的访问设置了权限。
冷静期通过限制刚解除关系的双方在解除关系一个月后不得绑定新关系来实现。

送券是为了增加恋爱中的仪式感，而恋爱中的仪式感有很多种形式，每种形式也有不同的内容，虽然都是送券，但每次收到和送出的券内容不一样，从“一起晚自习”券到“抱抱券”到“火锅券”、“刷碗券”等，它可以涵盖学习、生活甚至工作的方方面面，每次收券和领券的情形和心情都是不同的，所以它并不会变得单调，更何况它传递的是世间最美好的情感呢。

改进部分和改进过程

可以根据冲刺阶段同学们的学习进度，考虑对后端架构的更换。

可以根据新的UI设计，考虑更换原型设计

可以根据新的需求，考虑增添数据库

本次作业工作流程

根据需求文档以及原型初稿对数据库进行了初步设计，确定了数据库的模式和表的数量以及类型，并且我们分析了所需要的接口数据，并系统架构进行了分层设计，在经过讨论之后，敲定了《系统设计说明书》和《数据库设计说明书》两份文档。

组员分工及贡献度比例

成员	分工	贡献度
021800527施颖辉	数据库设计，E-R图绘制.系统设计说明书制作	13%
031802507邓家俊	ppt制作	10%
031802243张建娴	系统设计说明书制作	10%
031802438张佳侨	ppt制作	10%
031801125黄雨晨	数据库设计,系统设计说明书制作	12%
031802129吴涣祺	系统设计说明书制作,E-R图绘制	13%
031802133谢林煌	系统设计说明书制作,E-R图绘制	13%
031802642郑孙健	系统设计说明书制作	9%
031802420刘任世麒	博客撰写	5%
031802218廖启涵	博客撰写	5%
github团队仓库链接https://github.com/021800527/wuhulahu
相关文档的链接
系统设计和数据库设计答辩PPT
[https://pan.baidu.com/s/1SOQWnFewWcNrNeGAuS9aMw]（提取码：021r)
系统设计说明书
[https://pan.baidu.com/s/1sCyBLytPwaj6s3VqdHRjNQ]（提取码：mgf2）
数据库设计说明书链接：
https://pan.baidu.com/s/1ixyOyf975_PxtD5hcVRtkg 提取码：u005