栋哥说的都队——项目系统设计与数据库设计
作者：互联网
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/SE2020 |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/SE2020/homework/11447 |
| 团队名称 | <栋哥说的都队> |
| 这个作业的目标 | <项目落地，具体设计> |
开发计划时间安排
| 周数 | 总体计划 |
|---|---|
| 第 11 周 | 编程语言进一步学习，后端数据库部署和接口开发 |
| 第 12 周 | 前后端完整实现，数据导入，内测 |
一、后期主要分工安排
| 姓名 | 分工 |
|---|---|
| 程灵飞 | < 项目负责人 > |
| 陈锦辉 | < 前端 > |
| 吴端己 | < 食堂资料收集 > |
| 陈新平 | < 前端 > |
| 李辰钰 | < 测试 > |
| 史金易 | < 食堂资料收集 > |
| 林江鸿 | < 食堂资料收集 > |
| 姜博 | < 测试 > |
| 兰杰 | < 后端 > |
| 黄展 | < 后端 > |
| 张孚楠 | < 食堂资料收集 > |
二、功能模块层次图
三、接口设计
评论接口
- 功能要求：用户对菜品进行。
- 前端输入项： 菜品评论信息。
- 后端输出项： 用户评论成功与否。
获取推荐接口
- 功能要求：用户获取推荐菜品。
- 前端输入项：用户选择的标签。
- 后端输出项： 推荐菜品信息。
获取收藏接口
- 功能要求：用户查看收藏的菜品。
- 前端输入项：用户的id。
- 后端输出项： 收藏菜品信息。
搜索功能接口
- 功能要求：用户搜索想要的菜品。
- 前端输入项：搜索字段。
- 后端输出项： 搜索结果的菜品信息。
查看菜品详细信息接口
- 功能要求：用户查看菜品的详细信息。
- 前端输入项：菜品的id。
- 后端输出项： 菜品的详细信息。
四、用例图
五、设计类图
六、ER分析
七、表结构设计
八、系统安全和权限设计
- 用户根据评论和功能存在等级差别，需要后端确认用户之间评论发布的限制，防止用户绕过系统限制；
- 据调查，可通过恶意购买大量手机号认证登录，进行大量刷好（恶）评、刷星行为，不仅需要对初始用户的评论有所限制，还需要添加一定的验证和恶意行为特征检查；
- 同上，同时恶意登录认证、查询菜品时发送请求，会造成服务器拥塞导致服务瘫痪，一方面采用硬核方法，升级服务器配置，一方面合理处理并发请求；
- 同上，请求数量突变的情况还会发生于饭点前后、用餐期间，处理方式同上；
- 后端数据库参数化查询防止恶意输入和注入。
九、需求分析与原型设计部分的回顾
评论回复
- 第一个问题的回答 —— 竞品分析作为上一次的作业和答辩环节中有着重分析过，所以这次没有提及。这次需求分析也是从NABC方面出发，D推广分析在上次答辩中有同学提到过该程序缺少用户激励等问题，我们也有多加思考并根据问卷调查进行策略应对。
- 第二个问题的回答 —— 这个片段的真相其实是（苦笑）。。。我们考虑到商家入驻的想法有可能不太现实，考虑到导入数据量大和后台设计比较复杂，“他们（食堂人员）不会用（我们数据管理后台）的”，然后想这个需求是否需要更改。
一些问题上的改进
- 是否有再细化过用户群体，比如大三大四基本点外卖不吃食堂？
- 所以我们进一步细化了用户群体：主要面向线下主动去食堂吃的人，再一步细化有————大一、大二对本校食堂并非那么了解的同学，经常吃同一家临时想换一换口味的同学，已经知道全校大部分店家但是没吃过的同学，已经知道全校大部分店家并且吃过的同学但是纯粹想逛一逛顺便评论一下的同学，喜欢评论并推荐校内美食的同学
- 是否有考虑到店家开店时间诸如此类的细节？
- 我们小组觉得是个好问题！我们采纳了并且已经在收集了，欢迎大家补充。
- 上次 blog 出现苹果端无法正常显示的问题？
- 修改了模板，已解决。
十、贡献度
说是改为在线文档填写，此处忽略
十一、总结
- 组长和大部分人最近比较忙，基本每晚 11-12 点以后才有空开始处理这些事情，所以这周工作没能很好带领起来，下周努力吧（争取深更半夜顶着寒风开会？）；
- 从现场编程基本看到了小组成员的编码实力，感觉 alpha 冲刺阶段一半的编码人员起步会很艰难；
- 这次任务很难分配，完成度一般。
标签：栋哥,数据库,用户,接口,评论,菜品,设计,食堂 来源： https://www.cnblogs.com/NO8ruangong/p/13951889.html