基于Star UML3

去酒店后，向服务员或者前台人员订餐，这个时候服务人员会把菜单拿给我们进行选餐，服务人员可能会向我们询问口味以及其他方面问题，例如就餐人数，就餐时间、位置、生成订单等。

当服务人员把选好的菜单拿到后，会去酒店后厨房间查看菜品是否齐全，若是不齐全，那么就涉及到采买环节、以及食材库存等，这个时候要给予顾客进行反馈，酒店可能还会涉及到人员管理，例如新员工入职，信息采集、员工离职等、

以上加粗文字是通过名次识别法，找出相应的实体，以及对餐饮行业的调查所得出。

1.2任务定义

1.2.1功能定义:

考虑到以上问题的分析,我们的管理系统应为如下:

前台:

(1)主要负责对接顾客，和选餐，例如顾客订餐、顾客结账收银(结账等环节)。

其中订餐环节又包括到店消费、提前预定，选菜。换菜、选座等等。

(2)收银功能中还包括，预定缴纳押金、结余、以及收集用户信息等环节

后台:

(1) 主要是酒店对菜品制定、人管管理、库存管理等

(2)菜品制定包括、增加、删除、修改等、人员管理是对员工的增删改、库存是对库存余量的操作。

1.2.2确定用户

用户的确定是当用户缴纳押金提前预约、或者说是到店直接消费等流程环节、提前预约中包含提前选菜、缴纳押金等。

1.3功能模块设计

1.31包括登录管理>>前台/后台

用户通过注册app登录酒店的系统进行订餐(这一步骤可以是收银员代为操作)，或者顾客自己操作、根据登录者的身份不同进行不同的操作，例如当登录者身份是服务员或者前台收银员

当用户的身份是管理员，那么会直接登录到系统的后台界面，进行相应的操作。

1.32前台>>收银管理/客户反馈/顾客订餐

当登录者的身份是收银，那么订餐是的操作可以是多种多样，同时可以加进行更加深一步的操作，如果是客户自己订餐那么必须要选好菜品、时间、座位等生成订单、且必须缴纳押金，以及必要的身份信息。

1.33其中顾客订餐环节

前台订餐(收银员订餐)/或者顾客自己通过APP等移动终端订餐

1.34菜单管理

主要是对菜品的制定、修改、删除等操作

1.35财产管理

主要是对原料采买、物品信息统计等资产管理等操作

1.36员工管理

分配角色、分配权限

为入职员工或者其他员工分配相应的权限。例如管理员权限移交、前台收银的权限、

采购人员的权限。例如查看库存等等。

(二)系统功能分析

下面的一些问题就是针对、问题所分析的一些实例进行一步分析问题，把系统共进一步完善。

由于本系统是按照不同管理角色进行设计的，系统使用模块化的功能模块的划分方法，将整个系统大致分成两大部分：前台部分与后台部分。进行这样的划分是基于系统在管理过程中是否直接与客户接触而定的。前台部分就是直接与客户进行沟通的地方，而后台部分主要是系统管理员进行操作和管理的系统特殊功能。

将系统进行功能模块划分之后，系统的层次结构就清晰可见了。系统功能模块图(流程图)如下StarUML3.1版本所示图所示：

系统流程图:

2.1 前台

这是对整个系统的总体划分，前台总的来说就是对客户进行负责的总模块，这部分的功能主要是表现在与客户沟通。收银人员主要是为顾客结账，因此我们把它总体划分为前台部分。

2.1.1 收银结账

收银结账是由收银人员来操纵，当客户点完餐就可以到柜台进行结账，在收银台客户的用例主要有结账、打印账单、记录老顾客信息和接受顾客反馈。

2.2 后台

后台主要是对数据库进行直接交互的模块，后台中主要由管理员进行操纵。统计收银员主要是直接结账的信息，也就将库存信息、员工工资信息收集而来的收支数据成为合理的账单。系统主要起来统计的作用 ，系统管理员主要时行系统员工管理、系统参数设置、产品订购、信息查看。

2.2.1 菜单管理

管理员可以从系统的这个功能模块主获取菜单销售信息，对菜单进行调整（包括做法等）；将这些信息转化为专业的销售报告，从而制订出合理的菜单。

2.2.2 员工管理

这里所说的员工管理实际上也算是用户管理，员工管理主要是对员工信息基本维护（增删查改）、权限管理。主要部分在于权限管理，系统管理员可根据具体需求为员工分配相应的角色、权限。

二、用例设计建模

2.1用例图概述

用例图（英语：use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

2.2餐饮管理用例图:

2.2.1顾客订餐用例图

顾客订餐说明

用例编号 用例名称 简要说明

A 顾客登陆 输入账号密码类型登陆系统

B 查看订单 查看顾客某一订单的具体信息

C 订餐 预先点菜，选位，选时间。成功后获取号码，按时到店出示即可。

D 用餐 到店出示订餐号码，按订单上的信息就坐用餐。

E 用户反馈 当用户可对该餐厅的菜肴服务态度等信息进行评论。

F 帮助说明 提示用户如何进行操作

A系统登陆

用例规约：

用例名称： 顾客登陆

用例ID： A

角色： 顾客

用例说明： 顾客登陆系统.

前置条件： 用户打开系统进入登陆界面.

事件流： 1．顾客输入对应的用户名和密码，类型。

2．登陆成功后弹出主界面。

后置条件： 进入各自的主界面.

B订单查询

用例规约：

用例名称： 订单查询

用例ID： B

角色： 顾客

用例说明： 顾客可以通过点击界面上的订单号来了解某一订单的内容。

前置条件： 顾客登陆主界面，并进入查询订单界面。

事件流： 1．顾客点击查询订单界面上列出的某一订单号。

2．得到该订单信息。

后置条件： 后台中有关该订单消息将显示出来。

C订餐

用例规约：

用例名称： 订餐

用例ID： C

角色： 顾客

用例说明： 顾客订餐。通过输入点菜信息，位置，时间来进行预定。需支付一定的定金。预定成功后会获取一个订餐号码，按时到店出示。

前置条件： 顾客登陆后，进入订餐界面。

基本事件流： 1．顾客输入预订者姓名，预订者身份证，预订者电话，所选的位置，到店时间段，并通过查看菜单选择要订的菜肴。

2．输入完成后点击“确认预订”。

3．交纳订金。

4．订餐号码将发送到顾客的手机。

5．预订成功。

后置条件： 订餐成功，数据库更新。

D用餐

用例规约：

用例名称： 用餐

用例ID： D

角色： 顾客，收银员

用例说明： 顾客在预定时间内到店出示订餐号码，按订单上的信息就坐用餐。

前置条件： 顾客到达该餐厅。

基本事件流： 1. 顾客到前台出示订单号码

2. 前台收银员核对订单号码，如果确实存在并在预定时间内则通知服务员，按照订单的信息安排顾客。

3. 顾客用餐

后置条件： 用餐完毕，修改顾客的订单状态为“订单完成”。

E用户反馈

用例规约：

用例名称： 用户反馈

用例ID： E

角色： 顾客

用例说明： 顾客可以在用户反馈界面输入对该餐厅的菜肴服务态度等信息的评论或者建议等等

前置条件： 顾客登陆主界面，进入用户反馈界面，并且顾客账号有已完成的订单。

事件流： 1. 顾客填写反馈意见。

后置条件： 填写成功，内容加入数据库。

F帮助说明

用例规约：

用例名称： 帮助说明

用例ID： F

角色： 顾客

用例说明： 顾客可以通过点击帮助说明界面来了解帮助信息。

前置条件： 顾客登陆主界面，并进入帮助界面。

事件流： 1. 顾客点击帮助界面的目录信息。

2. 得到该条目的具体信息。

后置条件： 后台中有关该信息将显示出来。

2.2.2收银员订餐用例图

收银员订餐说明

用例编号 用例名称 简要说明

A 收银员登陆 输入账号密码类型登陆系统

B 查看订单 查看所以顾客的订单具体信息

C 订餐 点菜，选位，口味选择。

D 用餐 按订单上的信息就坐用餐。

E 用户反馈 当用户可对该餐厅的菜肴服务态度等信息进行评论。

F 记录账单 打印账单及记录

A系统登陆

用例规约：

用例名称： 收银员登陆

用例ID： A

角色： 收银员

用例说明： 收银员登陆系统.

前置条件： 打开系统进入登陆界面.

事件流： 1．输入对应的用户名和密码，类型。

2．登陆成功后弹出主界面。

后置条件： 进入各自的主界面.

B订单查询

用例规约：

用例名称： 订单查询

用例ID： B

角色： 收银员+顾客

用例说明： 收银员根据顾客订餐情况查询订单状态，打印订单。

前置条件： 收银员登陆主界面，并进入查询订单界面。

事件流： 3．收银员点击查询订单界面上列出的某一订单号。

4．得到该订单信息。

后置条件： 后台中有关该订单消息将显示出来。

C订餐

用例规约：

用例名称： 订餐

用例ID： C

角色： 顾客+收银员

用例说明： 顾客订餐。通过查询菜单信息，位置，需支付一定的定金。预定成功后会获取一个订餐号码，按时到店出示。

前置条件： 收银员登陆后，进入订餐界面。

基本事件流： 1.顾客报上预订者姓名，预订者身份证，预订者电话，所选的位置，到店时间段，并通过查看菜单选择要订的菜肴。

2.输入完成后点击“确认预订”。

3.交纳订金。

4.订餐号码将发送到顾客的手机。

5.预订成功。

后置条件： 订餐成功，数据库更新。

D用餐

用例规约：

用例名称： 用餐

用例ID： D

角色： 顾客，收银员

用例说明： 顾客在预定时间内到店出示订餐号码，按订单上的信息就坐用餐。

前置条件： 顾客到达该餐厅。

基本事件流： 1. 顾客到前台出示订单号码

2. 前台收银员核对订单号码，如果确实存在并在预定时间内则通知服务员，按照订单的信息安排顾客。

3. 顾客用餐

后置条件： 用餐完毕，修改顾客的订单状态为“订单完成”。

E用户反馈

用例规约：

用例名称： 用户反馈

用例ID： E

角色： 顾客

用例说明： 顾客可以在用户反馈界面输入对该餐厅的菜肴服务态度等信息的评论或者建议等等

前置条件： 顾客登陆主界面，进入用户反馈界面，并且顾客账号有已完成的订单。

事件流： 1. 顾客填写反馈意见。

后置条件： 填写成功，内容加入数据库。

F记录账单

用例规约：

用例名称： 记录账单

用例ID： F

角色： 收银员

用例说明： 收银员打印账单后，自动记录消费记录。

前置条件： 收银员登陆主界面。

事件流： 1. 打印账单。

2. 记录账单的具体信息。

后置条件： 后台中有关该信息将显示出来。

2.2.3管理员管理店铺用例图

管理员管理店铺说明

用例编号 用例名称 简要说明

A 管理员登陆 输入账号密码类型登陆系统

B 查员工信息 查看所有员工信息。

C 菜单管理 管理菜单。

D 财产管理 管理财产信息。

E 库存管理 管理库存信息

F 查看用户反馈 查看用户对该餐厅的菜肴服务态度等信息进行评论。

A系统登陆

用例规约：

用例名称： 管理员登陆

用例ID： A

角色： 管理员

用例说明： 管理员登陆系统.

前置条件： 打开系统进入登陆界面.

事件流： 1．输入对应的用户名和密码，类型。

2．登陆成功后弹出主界面。

后置条件： 进入各自的主界面.

B查看员工信息

用例规约：

用例名称： 查看员工信息

用例ID： B

角色： 管理员

用例说明： 管理员查看员工信息。

前置条件： 管理员登陆主界面。

事件流： 1. 列出员工信息。

2. 对员工信息进行处理。

后置条件： 后台中有关该信息将显示出来。

可以修改、删除、添加员工信息。

C查看菜单信息

用例规约：

用例名称： 查看菜单信息

用例ID： C

角色： 管理员

用例说明： 管理员查看菜单信息。

前置条件： 管理员登陆主界面。

事件流： 1. 列出菜单信息。

2. 对菜单信息进行处理。

后置条件： 后台中有关该信息将显示出来。

可以修改、删除、添加菜单信息。

D财产管理

用例规约：

用例名称： 查看收支

用例ID： D

角色： 管理员

用例说明： 管理员查看财产信息。

前置条件： 管理员登陆主界面。

事件流： 1. 列出收支状况。。

后置条件： 后台中有关该信息将显示出来。

E库存管理

用例规约：

用例名称： 查看库存

用例ID： E

角色： 管理员

用例说明： 管理员查看库存信息。

前置条件： 管理员登陆主界面。

事件流： 1. 列出库存信息。

后置条件： 后台中有关该信息将显示出来。

可以修改、删除、添加各项库存信息。

F查看用户反馈

用例规约：

用例名称： 查看用户反馈

用例ID： F

角色： 管理员

用例说明： 管理员查看用户反馈的信息。

前置条件： 管理员登陆主界面。

事件流： 1. 反馈信息。

后置条件： 后台中有关该信息将显示出来。

三、类图设计建模

该图是我们系统当中实体类之间的联系、以及类的属性方法、和其访问权限，

其中关联关系又分为1 N 、0 N、 0 0、N N 、1 1等等

包括泛化关系、其他关系、关联关系等等。

四、顺序图设计建模

4.1顺序图概述:

以下是百度百科所给的定义，也有我自己的理解:

顺序图也称之为(时序图)是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

4.2构建顺序图

4.2.1用户订餐时序图：

因为新版本的UML3.1中与就版本中的某些功能进行了删改，无法单独设置控制焦点

Activation，这主要体现激活期上，但是考虑数轴是时间线，这样理解也是可以的。

说明:当顾客自己通过终端进行订餐时，先选好座位、菜单、确认好订单后、会进行订单提交缴纳押金或者付款等环节、最后才是就餐，当然也可以到店直接消费。该时序图，也可以表示提前预定、和直接到店就餐等环节。

4.2.2收银员点餐时序图：

收银员订餐，与用户订餐相比较而言就是多了打印菜单就餐、加菜/换菜等环节其他功能基本一样，下面的其他顺序图就不多加解释说明了，因为图的方式已经能够说明问题了。

4.2.3用户修改订餐时序图：

4.2.4用户取消订餐时序图：
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

结语

小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。

我们选择的这个行业就一直要持续的学习，又很吃青春饭。

虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。

送给每一位想学习Java小伙伴，用来提升自己。

本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

结语

小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。

我们选择的这个行业就一直要持续的学习，又很吃青春饭。

虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。

送给每一位想学习Java小伙伴，用来提升自己。

[外链图片转存中…(img-2eOvp1eF-1713612874517)]

本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！