基于Star UML3.1版本的课程结业设计餐饮管理系统

Code攻城狮

已于 2023-12-01 00:40:29 修改

阅读量2.3w

点赞数 92

文章标签： uml

于 2021-06-12 13:16:26 首次发布

本文链接：https://blog.csdn.net/helpluozhao123/article/details/117844884

版权

文档和工程文件
地址如下:
链接: 文档和工程文件存储地址

课程论文报告

教学院计算机学院
课程名称 UML建模技术
题目餐饮管理系统
专业计算机科学与技术
班级
学号
姓名
指导教师
2021 年 6 月 20 日

引言

随着社会的进步，人民生活水平的不断提高，餐饮酒店以及学校食堂等消费行业得到了迅猛的发展。现在的餐饮行业正向着规模化，集团化方向发展，传统的经营管理模式已经不能适应这种发展势趋。这样就迫切需要一个高效率的管理方式来引导餐饮行业的发展.
我们设计的餐饮管理系统操作界面简洁、直观，非常容易上手；下订单、点菜、结账、收银可在最短时间内飞速完成,可以大大帮助企业节约成本，节省人力，同时也能提高企业的工作效率，并且能够提升顾客整体的体验感。

课题背景

餐饮业一直是服务行业最重要的组成部分之一。薄利多销一直是餐饮业的营销理念。如何在当前餐饮行业日趋激烈的竞争环境中脱颖而出并吸引更多的顾客，已成为每位餐饮业经营者所追求的目标。
经过多年发展，餐馆管理已经逐渐由简单而繁琐的人工管理，进入科学系统管理的阶段。如何有效的节约人力成本是餐饮业致力于解决的首要问题。当前最有效的手段就是采用系统的自动化电脑管理取代过去的人工方式,并且可以借助移动互联网的方式，使用户能够，远程下单、一方面能够节省用户的时间和经历，另一方面也能方便企业解决成本，从繁杂的劳动中解脱出来，提高工作效率。
故借这次UML结业后我通过所学知识，经过一段时间的设计规划划，查询资料，参照了同类软件和ＵＭＬ书中实例及设计要求，设计了这款餐饮服务系统。该系统保持了灵活性和易操作性，并具有良好人性化的用户界面，在制作课程设计的时候，本人自学了UML3.1版本的用法，UML3.1版本相比老版本的UML更加快捷，页面简洁，容易上手，但是毕竟学习的时间较短，有不足之初还请老师批评指正。

一、系统需求分析

(一)问题分析

主要从几个方面考虑，餐饮系统做的是服务行业，我们每个人从小到大都去过饭店，对去饭店点餐，就餐、结账等环节都不陌生，下面通过模拟就餐场景我们来进行分析问题，但是我们对酒店和饭店等后台工作环节，可能还不是很清楚，所以我们为了对问题更加深入的剖析，为了能够使我们的所设计的UML图能够在开发软件时候，尽最大的能够给与我们开发人员以及后期软件上线，给予用户最好的体验，我们可以通过实地考察，更深一步了解酒店餐饮等行业后台的工作流程，询问酒店的管理人员、服务人员、后台厨师、采购等人员日常的工作流程，我们经过严格的论证以及生活经验我们可以得出以下问题:
去酒店后，向服务员或者前台人员订餐，这个时候服务人员会把菜单拿给我们进行选餐，服务人员可能会向我们询问口味以及其他方面问题，例如就餐人数，就餐时间、位置、生成订单等。
当服务人员把选好的菜单拿到后，会去酒店后厨房间查看菜品是否齐全，若是不齐全，那么就涉及到采买环节、以及食材库存等，这个时候要给予顾客进行反馈，酒店可能还会涉及到人员管理，例如新员工入职，信息采集、员工离职等、

以上加粗文字是通过名次识别法，找出相应的实体，以及对餐饮行业的调查所得出。
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.预订成功。
后置条件：订餐成功，数据库更新。

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用户取消订餐时序图：
在这里插入图片描述

4.2.5管理员管理库存时序图：
在这里插入图片描述

4.2.6管理员管理员工信息时序图：

在这里插入图片描述

五、通信图(合作图)

5.1通信图概述：

协作图，又作“通信图”。即Communication Diagram，而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。故UML 2.0以后通信图不再是协作图，没有专门的”协作图“，只有”协作“。
，但是本例设计中，我个人认为通信图的叫法也确实是更好一些，因为通信代表者数据的传说，协作则是说明两个方法或者2个类之间的协作，但是面向抽象的思维，我个人感觉叫通信图更好一些，但是在本例中图片上我标的是协作图，就是通信图。，用通信图更好一些。

5.2构建通信图

5.2.1顾客订餐协作图：
1.create 用户要进行选座、2.查询当前剩余作为、3.结果在终端上显示、4.查询菜单、
5．菜单显示于终端上。、6.选择完毕后，最后确定就餐时的订单
在这里插入图片描述

5.2.2顾客取消订单协作图：
7.顾客登录app、9.查看自己的订单(也只是能查看自己的订单)、
10.订单信息反馈给用户或者说显示在终端上、8。顾客删除(取消)订单。

在这里插入图片描述

5.2.3收银员管理点餐协作图：

收银员登录系统后，对顾客信息进行录入、根据顾客的意见选择座位、菜单、最后生成订单、生成账单
在这里插入图片描述

5.2.4管理员添加员工信息协作图：

管理员登录后台，对员工的信息进行录入、修改等

在这里插入图片描述

5.2.5管理员删除员工协作图：
管理员登录后台，对员工信息进行查询，结果进行反馈，最后对员工的信息删除，或者对
员工的某些信息删除，例如权限删除
在这里插入图片描述

5.2.6管理员修改员工资料协作图：
管理员登录后台系统，对员工的信息就行修改
在这里插入图片描述

管理员处理库存和处理菜单与员工管理相同。

六、活动图

6.1活动图概述

活动图（Activity Diagram），描述了活动的顺序，展现从一个活动到另一个活动的控制流，即活动图是一种流程图。活动图描述了业务实现用例的工作流程。活动图主要由活动和动作构成，也可以支持分支、迭代、并行。在UML中，活动图主要用于计算性和组织性过程（即工作流）建模。

6.2构建活动图

6.2.1客户订餐活动图
客户登录使用移动终端进行查看订单(若有订单则进行处理订单业务)，若没有订单则
添加订单
在这里插入图片描述

6.2.2管理员管理活动图
管理员登录后台系统后。会进行菜单信息的处理、员工的信息处理、库存的信息处理
在这里插入图片描述

6.2.3收银员管理活动图
收银员为顾客进行订餐的操作流程以及逻辑判断，执行的先后顺序

在这里插入图片描述

七、状态图

7.1状态图概述:

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。
状态机用于对模型元素的动态行为进行建模，更具体地说，就是对系统行为中受事件驱动的方面进行建模（请参见概念：事件与信号）。状态机专门用于定义依赖于状态的行为（即根据模型元素所处的状态而有所变化的行为）。其行为不会随着其元素状态发生变化的模型元素不需要用状态机来描述其行为（这些元素通常是主要负载管理数据的被动类）。