餐饮系统大拆解,理清订单与桌台之间的各种异常(3)

0 评论 4097 浏览 13 收藏 6 分钟

导读:这是餐饮系统大拆解第三篇。在第一篇中,我们用类图拆解了员工信息;在第二篇中,我们用类图拆解了套餐和桌台信息;本篇将用类图拆解订单信息,从而将订单的异常考虑全。同样,本文也会讲《图解产品》一书中未讲的知识,且阅读本文需有该书的知识背景。

01用户下单流程

用户要点餐,他既可在网上自主下单,还可在现场由服务人员代为下单。为说明主要问题,我们只考虑由服务员下单这种情况,而其操作流程是:

  • 开台:服务员点击开台,表示该桌台已经被顾客使用
  • 点餐:服务员操作点餐系统,代顾客点餐
  • 下单:服务员点击下单,订单信息下发到厨房
  • 结账:用户吃完后到前台结账,收银员确认该用于已结账
  • 清台:保洁员清理桌台,之后服务员点击已经清台,则下桌客人就可用餐了

以上,就是服务员的操作流程。为了便于理解,该流程做了简化。

那现在的问题是,如何将订单的各种情况都考虑全?

这里有三个方法,分别是用例驱动、流程驱动和领域驱动。这三个方法都要运用,才能考虑全面。

在《图解产品》一书中,用例驱动和流程驱动讲的较多,但领域驱动讲的少。本文就说说领域驱动这个方法。

02 领域驱动下的类图

按照《图解产品》一书的知识,你就可以梳理出订单的类图,梳理的方法有:看竞品和进行用户访谈,书中还讲了具体的步骤。下图就是是按此方法梳理出来的结果。

该图表达了订单是由订单项(菜单的条目),支付信息与发票信息等组成的。如果你没有看过书,我简单解释一下该图。

在线条两边的数字,表示两个类之间的数量关系,更准确地是对象间的数量关系)。如该系统支持一个订单可以有多个支付,即用户可同时使用购物卡和微信,来共同支付一个订单。

为什么要梳理数量关系?因为这将影响原型设计。如一个订单支持多个支付,那么在界面上,就要显示购物卡抵扣的金额,再加上需要用微信支付的余额。

但上图少了订单与桌台之间的数量关系,请你思考一下,两者之间的数量关系是什么?

03 订单与桌台关系

按照《图解产品》的思路分析,订单与桌台之间应为多对多的关系。即一个订单可以关联多个桌台,且一个桌台也可以关联多个订单。

一个订单关联多个桌台的情况,如是公司的人一起吃饭,这就可能需要同时占用多个桌台。一个桌台有多个订单的情况,当一个桌子只坐了一位客人,如允许第二个客人也在这个桌子上吃饭,也就是允许拼桌,则一个桌台就有多个订单。

而这个多对多的关系,我们也要在原型里体现出来。

但这还不够,我们还应基于桌台信息,再考虑TA对订单的影响,即需要将“桌台”这个类的信息列出,如桌台的属性有:位置、是否有包间费用,可坐几人等;桌台的状态有:空闲、非空闲(已开台、正清洁等)、维修等状态。

然后基于桌台的这些信息,再将订单逻辑考虑周到。

  • 比如,非空闲的桌台是不能再下单的。但如允许拼桌,则也可再下一单。
  • 再如,用户的就餐人数(在订单里反应)应小于该桌台人数,如不符合就要有提醒。

最后,如该桌台有包间费则应累计到订单中。同时还需考虑一个订单下,如果一个桌台有包间费,另一个桌台无包间费,又应如何计算费用。

总之,你需要考虑订单与桌台信息之间个各种交叉情况,即一对多,多对多等情况。如考虑不全,就可能导致研发重做,所以尤其要重视。

好了,这就是今天的内容。总之学好UML,就能考虑周全,避免返工!希望本文能帮到你,全文完!

TIPS:

有些人认为设计就是看起来长什么样。但是如果你深入挖掘就会发现,设计更关乎如何运作。——史蒂夫·乔布斯。

产品经理则要用好UML,从而抽象出运作逻辑。

 

作者:擎苍,《“图解”产品:产品经理业务设计与UML建模》作者,公众号:图解产品设计

本文由 @图解产品设计 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!