餐饮管理系统.docx
《餐饮管理系统.docx》由会员分享，可在线阅读，更多相关《餐饮管理系统.docx（18页珍藏版）》请在冰豆网上搜索。
餐饮管理系统
课程名称：
系统分析与设计
实验项目：
餐饮管理系统实验
实验地点：
行逸楼A103
专业班级：
软件1315学号：
2013005295
学生姓名：
杨博
指导教师：
杨丽凤
2015年11月11日
一、实验目的
通过《系统分析与设计》实验，使学生在实际的案例中完成系统分析与系统设计中的主要步骤，并熟悉信息系统开发的有关应用软件，加深对信息系统分析与设计课程基础理论、基本知识的理解，提高分析和解决实际问题的能力，使学生在实践中熟悉信息系统分析与设计的规范，为后继的学习打下良好的基础。
二、实验要求
学生以个人为单位完成，自选题目，班内题目不重复，使用UML进行系统分析与设计，并完成实验报告。
实验报告以纸质版（A4）在课程结束后二周上内提交（12周）。
3、实验主要设备：
四、实验内容
1.选题及项目背景
当今世界已进入了在计算机信息管理领域中激烈竞争的时代，应用计算机已经变得十分普遍了，如同我们离不开的自行车、汽车一样。
我们应该承认，谁掌握的知识多，信息量大，信息处理速度快，批量大，谁的效率就高，谁就能够在各种竞争中立于不败之地。
随着科学技术的不断提高,计算机科学日渐成熟,其强大的功能已为人们深刻认识,它已进入人类社会的各个领域并发挥着越来越重要的作用。
越来越多的管理人员意识到信息管理的重要性。
由于当前餐饮企业的管理还处于人工管理阶段，仅在财务部门使用了计算机，所以餐饮企业的管理效率不高。
由于缺乏科学的管理和现代化的管理工具，该饭店在管理上和业务的安排上都存在着不足。
（1）包间的管理不够科学方便，房间使用情况不直观。
（2）仓库管员不能随时掌握库存情况，不能及时发现商品缺货的情况，另外统计商品数量即费时又费力。
（3）由于该餐饮企业的商品种类多，菜样多变，靠人工方式管理商品和菜品信息有很多不便。
例如商品数量大导致查找商品信息困难等。
通过设计用户平台，使得操作计算机化，可有效节省人力物力。
2.定义
餐饮管理系统为所有工作人员提供登陆服务，只有被公司聘用人员才可以得到登陆账号和密码，登陆系统，完成不同的工作职责；
点菜系统：
餐厅服务人员登陆系统，最低权限，能且只能使用点菜系统，使用点菜系统形成订单，订单包括订单号，顾客所在的桌号，以及需要的菜品种类和菜品数量，完成点菜任务之后点击提交；订单生成，同步到后厨系统，收银系统，信息管理系统
后厨系统：
后厨服务人员登录系统，最低权限，能且只能使用后厨系统，查看当前订单信息，（需要制作完成的菜品种类和数量），每一道菜品制作完成之后点击完成（若同种菜品数量大于1，点击完成该数量减一）；若顾客取消相应菜品，则点击菜品任务后的取消，系统会自动记录。
直至订单全部菜品制作完成，订单被挂起，等待付款，然后推送给收银系统。
收银系统：
收银台人员登录系统，具有中级权限，可以使用点菜系统和收银系统，可以完成外卖任务，形成订单信息，推送给后厨系统，并将订单信息进行储存；同时完成收银任务，系统为每张订单计算订单消费总额，存储后，在月中（X月15日）并形成当月报表。
仓库系统：
通过查询收银系统每周的订单信息，累加计算下一周应该购买的原材料以及其他的商品等，并生成订购单，并由采购人员去按单购买。
信息管理系统：
饭店管理人员登录系统，具有最高权限可以使用其它3个子系统功能（除后厨系统），可以对所有人员进行人事任命，晋升，解雇，修调工资的功能；同时可以查看三个月以内所有的订单报表；还可以对菜品的种类和价格进行修改。
在月中形成工资单。
3.参考资料
[1]《软件工程案例教程》机械工业出版社；
[2]《软件工程》人民邮电出版社；
[3]《UML设计实作宝典》中国铁道出版社。
4.系统分析与设计
4.1需求分析
4.1.1识别参与者
系统管理员（SystemAdministrator）、服务员（Waiter）、收银员（Cashier）、厨师（Chief）、采购人员（Buyer）、顾客（Customer）。
4.1.2对需求进行捕获与描述
用例名称：
DeliverMeal（送餐）执行者：
服务员（Waiter）
目的：
在顾客点餐结束之后并且在收到厨师的取餐请求后，为顾客运送食物。
用例名称：
LogIn（登陆系统）执行者：
系统管理员（SystemAdministrator）、服务员（Waiter）、收银员（Cashier）、厨师（Chief）、采购人员（Buyer）
目的：
登陆餐饮管理系统，完成相应的工作。
用例名称：
PlaceAnOrder（下订单）执行者：
服务员（Waiter）、收银员（Cashier）
目的：
在顾客或者收银员查询菜单之后，可以进行下订单操作，订单信息包括：
菜品种类及数量，顾客所在桌号以及总金额等。
用例名称：
Orderfrom（订单）执行者：
服务员（Waiter）、收银员（Cashier）
目的：
完成下订单操作之后，生成的订单。
是制作报表和采购单的重要依据。
用例名称：
CallforDeliverMeal（取餐指令）执行者：
厨师（Chief）
目的：
将顾客需要的已完成的菜品送到顾客所在的餐桌上。
用例名称：
QueryMenu（查询菜单）执行者：
顾客（Customer）、收银员（Cashier）
目的：
让顾客查看本饭店的所有菜品，供消费者选择。
用例名称：
CollectMoney（收银）执行者：
收银员（Cashier）
目的：
顾客在本店消费之后，有收银员收取相应的金钱。
用例名称：
GenerateReport（生成报表）执行者：
收银员（Cashier）
目的：
根据每日的订单生成月中的报表，其中包括企业总销售额、支出明细、收入明细、纯利润等。
用例名称：
PayBill（付款）执行者：
顾客（Customer）
目的：
顾客在消费完之后，向收银员支付消费金额。
用例名称：
Changereward（修改工资）执行者：
系统管理员（SystemAdministrator）
目的：
由系统管理员修改每位员工的工资。
用例名称：
Recruitsomeone（人事调整）执行者：
系统管理员（SystemAdministrator）
目的：
对员工的职位进行调整或者增加解雇员工。
用例名称：
Changemeals（修改菜品信息）执行者：
系统管理员（SystemAdministrator）
目的：
顺应市场需求，对企业的菜品信息进行增加或者删减。
PlaceAnOrder（下订单）用例描述：
003.1
用例ID号及用例名
UC_003PlaceAnOrder（下订单）
003.2
用例概述
该用例描述一个餐饮管理系统中，服务员或者收银员（接受顾客的之时）提交一份菜品订单，系统验证菜品的可用性，将各条目加入订单中，系统生成订单，订单信息会保存在企业数据库中，等待顾客付款。
003.3
参与者：
服务员（Waiter）、收银员（Cashier）
101.4
前置条件（Pre-Conditions）
服务员、收银员登录餐饮管理系统
003.5
后置条件（Post-Conditions）
如果用例执行成功，所提供的点菜信息将被创建或更新；否则系统状态不变。
订单被记录下来，保存在数据库中
100.6
事件流
100.6.1
基本事件流
（BasicFlow）
当顾客点菜，服务员希望提交点菜信息时，本用例开始执行
a.系统显示本餐厅菜单
b.客户所点菜名
c.系统检索出该菜名所对应单价等信息
d.对与列表中的菜品信息，服务员输入相关份数，如果客户没有点到的菜品，其相应份数可以为空，服务员可以修改点菜信息
100.6.2
扩展事件流（AlternativeFlows）
在主流程中，如果本餐厅没有相关菜品，系统将显示信息错误，服务员接受此信息，用例结束
）
4.1.3用例图
4.1.4分析与讨论
1）建模用例图的步骤、方法？
用例分析是一个迭代和增量的过程，首先构建初始用例模型，其次是细化用例模型，具体步骤如下：
1.确定系统的边界和范围
2.识别系统参与者
3.发现用例
4.描述用例及确定用例关系
5.建立用例图
6.定义用例图的层次结构
2）如何识别系统的参与者？
应该如何划分用例，应注意哪些问题？
谁使用系统的主要功能；谁改变系统的数据；谁从系统获取数据；谁支持，维护系统；谁需要借助系统的支持来完成正常的工作；系统需要操纵哪些硬件；系统需要和那些外部系统交互；谁对系统运行结果感兴趣？
用例的来源是参与者对系统的期望，所以识别用例的最好的办法是从用户的需求入手，从参与者入手。
每个参与者在这个系统中打算做那些事情？
参与者使用该系统要实现的目标是什么？
参与者是否会在系统中创建，修改，删除，访问，存储数据？
如果是，如何完成？
参与者是否会将外部的某些事件通知给该系统？
系统是否会将内部的某些事件通知给该参与者？
3）心得
角色代表参与者，可能由人担当，也可能由系统担当，甚至可以是专门从事注册活动的某个组织；角色不是对职位建模。
用例是对系统行为的描述，从用户的角度，站在系统的外部观察系统的功能考虑系统做什么，而不考虑系统内部怎么做。
4.2建立对象模型
4.2.1候选类的数据字典
（1）数据流条目
工作人员信息=姓名+性别+年龄+职位+工号
订单=订单号+桌号+菜品明细+总金额+支付方式
菜品明细=菜品种类+菜品数量+菜品价格
支付方式=支付种类+支付账号+签名
工资单=月份+工号+姓名+应发工资+扣费项目+实发工资
采购单=采购单号+采购项目+采购数量+采购商品单价+总金额+审批人+执行人
（2）数据存储条目
文件名：
订单信息
组成：
订单号+桌号+菜品明细+总金额+支付方式
组织：
索引文件，以订单号为关键码
文件名：
工资单
组成：
月份+工号+姓名+应发工资+扣费项目+实发工资
组织：
索引文件，以工号和月份为联合主码
文件名：
采购单
组成：
采购单号+采购项目+采购数量+采购商品单价+总金额+审批人+执行人
组织：
索引文件，以采购单号为关键码
......
（3）数据项
姓名：
别名：
无
类型：
字符型
长度：
{字母}18-2
工资：
别名：
本月工资、员工收入
类型：
实型
长度：
5位，小数点后2位
菜品：
别名：
菜品信息、菜单
类型：
枚举类型
长度：
{字符}10-5
（4）加工条目
加工名：
餐饮管理系统
编号：
无
输入：
员工账号及密码
加工逻辑：
匹配数据库，存在记录则登陆成功。
输出：
操作主界面
加工名:
订单录入、存储处理
编号：
1
输入：
桌号
加工逻辑：
根据桌号，创建一个订单实例
If如果没有输入菜品信息
Then10分钟后，删除订单
Elseif输入菜品信息
Then计算订单的消费金额
输出：
附有桌号信息的订单表
......
4.2.2定义类（部分）
4.2.3绘制类图
4.2.4包图
对于大型复杂系统，常需要把大量的模型元素用包组织起来，以方便处理。
对所选系统的类进行分组，以便更清晰地了解系统的结构。
4.2.5分析与讨论
1）建模类图的步骤、方法？
1.分析系统模型元素（比如类或用例），把概念上或语义上相近的模型纳入一个包。
比如把类图中关系紧密的类放到一个保重，也常常把用例模型中业务相关或相似的用例分组到一个包中。
2.确定包之间的关系。
3.标出包内元素的可见性。
2）识别类有哪些方法，你是如何识别类的？
类是组成任何面向对象系统的核心，类的识别是UML建模的基础和关键，也是面向对象方法的一个难点。
只有通过对实际系统的分析和设计，逐步加深理解。
首先，找出候选类，采用名词识别法：
标识系统描述或用例描述中的所有名词，得到候选类，然后考察每个候选类，从中去掉不必要的类。
3）解释关联的多重性？
如何确定类的属性、操作、类之间的关联关系、组织类之间的继承？
关联关系是对象之间的关系。
分析关联的多重性：
对于每个关联，从一端看本端的一个对象可能与另一端的几个对象进行联系，把结果标注到连线的另一端。
4.3建立动态模型
4.3.1顺序图
4.3.2通信图
4.3.3活动图
活动图的主要作用是表示系统的业务工作流和并发处理过程。
针对自选系统主要的业务工作流绘制活动图。
绘制活动图需要确定参与活动的对象、动作状态、动作流，以及对象流。
4.3.4状态图
状态机图表现一个对象（类）的生命史。
对于一些实现重要行为动作的对象应当绘制状态机图。
绘制状态机图需要确定一个对象的生命期可能出现的全部状态，哪些事件将引起状态的转移，将会发生哪些动作。
4.3.5分析与讨论
比较顺序图与通信图、活动图与状态图的应用。
活动图（activitydiagram，动态图）是阐明了业务用例实现的工作流程。
业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。
业务用例由一系列活动组成，它们共同为业务主角生成某些工件。
工作流程通常包括一个基本工作流程和一个或多个备选工作流程。
工作流程的结构使用活动图来进行说明。
活动图是状态图的一种特殊形式。
其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。
状态图（StatechartDiagram）是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。
通常我们创建一个UML状态图是为了以下的研究目的：
研究类、角色、子系统、或组件的复杂行为。
状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。
顺序图是将交互关系表示为一个二维图。
纵向是时间轴，时间沿竖线向下延伸。
横向轴代表了在协作中各独立对象的类元角色。
类元角色用生命线表示。
当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。
顺序图是一种动态建模方法。
UML顺序图一般用于：
确认和丰富一个使用情境的逻辑。
4.4物理模型
4.4.1建立构件图
系统实现的源代码、二进制码、执行码可以按照模块化的思想，用构件分别组织起来，明确系统各部分的功能职责和软件结构。
4.4.2建立部署图
升级会员 