大型软件设计实验：多人点餐小程序—第二轮迭代 告

大型软件设计实验：多人点餐小程序—第二轮迭代 告

• • 1、需求再分析
  • 2、上轮迭代问题分析
  • 3、第二轮进度
  • • 3.1 更改篇
    • • 3.1.1 界面更改
      • 3.2 数据库更改
      • 3.3 代码结构更改
    • 3.2 新增篇
    • • 3.2.1 实现邀请好友
      • 3.2.2 实现消息同步
      • 3.2.3 实现房间偏好的选择
  • 4、第三轮迭代目标

1、需求再分析

为确保多人聚会时点餐活动顺利且愉悦的进行，本小组决定开发一微信小程序以实现同桌食客同时点餐并在一定程度上确保全体就餐人员获得满意的点餐体验。该小程序需具备以下基础功能：
食客端：
① 创建房间：创建虚拟房间，同桌的就餐人员可进入该房间中进行点餐；
② 多人同时点餐：菜品添加删减信息实时、同步的出现在同房间所有人员的客户端中；
③ 邀请好友：通过微信分享的功能将其他用餐人员拉入同一点餐房间中，此功能可邀请尚未到场的朋友加入共同点菜；
④ 标记“我”的忌口：每一食客可选择“我”不吃的配菜、调料等，以及“我”能接受的辣度，该信息将显示在房间信息之中；
⑤ 标记“我”不喜欢菜品：在菜单中按下“不喜欢”按钮表示自己不想吃此道菜或者对该菜品过敏，该标记信息会实时、同步出现在该房间全体成员的客户端中；
⑥ 结账：可选择仅支付个人所点菜品、AA制买单及请客等选项，并跳转微信或支付宝付款界面完成结账。
⑦ 智能推荐点单：根据本点餐房间中每个人口味的喜好（忌口）、历史点菜的记录与用餐人数等因素生成一份推荐菜单，以供参考。

商家端：
① 导入菜单：通过信息录入导入菜品价格、图片、类别及特征等信息；
② 订单查询：获得并查看顾客点单信息。

2、上轮迭代问题分析

通过展示后对其他组成员的采访，本小组产品经理获得诸多反馈，随后进行小组会议，针对每一问题提出解决方案：
① 界面
问题：界面元素繁多拥挤。
解决方案：将仅有的一个页面细分为多个分页。
② 用户交互
问题：交互方式复杂、不清晰，非常不友好。
解决方案：更改界面结构，采用指向明确、简介美观的小图标。
③ 功能
问题：他人点菜时无消息提示。
解决方案：采用信息弹出的方式对其他用户进行提示。
④ 数据库
问题：数据库组织不够清晰。
解决方案：重新规划数据存储方案，实现按食客端按房间组织，商家端按商家组织。

3、第二轮进度

3.1 更改篇

3.1.1 界面更改

前端设计是根据需求重新设计界面，以下为设计手稿：

3.2 数据库更改

因在云函数中创建的Collection的权限为仅创建者可读写，该权限下监听函数无法起作用，因此在每次建立房间时新建表格是不明智的决定（无法监听）。本小组经商讨后重新组织数据，除菜单外建立的Collection有members（就餐人员）,message（消息），order（点单）， rooms(房间偏好）。以下图片展示各个Collection中的项目格式。

Menu：

3.3 代码结构更改

统一代码风格（非promise风格），整理云函数结构。下图为云函数列表：

3.2.2 实现消息同步

当一人点餐时，点餐消息可以显示在多人客户端中。

3.2.3 实现房间偏好的选择

4、第三轮迭代目标

① 实现快速进入房间；
② 实现选择不喜欢后该项目变灰以向房间所有成员进行提醒；
③ 实现商家端菜单的导入（现在是直接向数据库提交）；
④ UI的细节优化；
⑤ 简单的推荐算法雏形。

文章知识点与官方知识档案匹配，可进一步学习相关知识小程序技能树首页概览3682 人正在系统学习中