餐厅订餐管理系统建模作业
酒店订餐管理系统UML建模

郑州大学软件学院《UML系统建模基础教程》大作业酒店订餐管理系统UML建模一、需求分析随着科学技术和互联网的迅猛发展,网络已经改变了我们的生活,通过网络交易成为当下的一种时尚,受到越来越多的人青睐,各个行业也将其当成一种重要的营销手段,酒店订餐管理系统也得益于网络的发展,提高了管理水平,扩大了营销范围。
酒店订餐管理系统是中小型酒店餐饮企业用来对客人的订餐活动进行管理的信息管理系统。
该信息系统不仅能够为客人提供方便的订餐功能,同时也能够达到提高酒店餐饮企业管理水平的目的。
订餐系统的功能性需求包括以下内容:(1)酒店的接待员使用电话为客人提供订餐服务,根据客人的订餐要求,在指定的时间和桌号安排好客人的就餐事宜;按客人的要求执行修改订单的操作;在客人临时取消预订时删除订餐信息;在客人订餐时间到达前,及时提供电话提醒服务。
(2)酒店领班在订餐客人到店用餐时和用餐离店后分别在系统做好记录并保存;能够为客人注册成为会员;可以查询、修改和删除会员信息;可以为客人提供换桌服务。
二、酒店订餐管理系统UML建模简介:基于UML建模的酒店订餐管理系统,通过用例图、类图、序列图、协作图、状态图、活动图、构件图、部署图来进行酒店订餐管理系统建模的。
三、创建系统的用例模型:(一)接待员(Receptionist)用例图:接待员用例能够通过该系统进行如下活动:(1)记录订餐信息。
接待员将客人的订餐要求输入到系统中保存。
(2)订餐定时提醒。
接待员在客人的预定的订餐时间之前给客人一个提醒,同时再次加以确认。
(3)取消订餐记录。
客人因临时原因取消订餐,接待员将系统中原来的订餐信息取消。
用例规约:(二)领班(Captain)用例图:领班用例能够通过该系统进行如下活动:(1)记录订餐客人到店。
领班在有预订的客人前来酒店就餐时,在系统中记录预订客人已到店的信息并保存。
(2)记录订餐客人离店。
领班在预订的客人用餐离店后,在系统中记录预订客人用餐完毕的信息并保存,表示整个订餐过程结束。
UML餐馆系统:业务建模

第4章餐馆系统:业务建模接下来的四章将考虑一个简单的案例,并给出一个从需求获取到实现的完整开发过程。
我们将考虑一次单独的迭代,它通过统一过程标识的主要工作流之中的四个:即需求、分析、设计和实现,用例子说明UML表示法在软件开发中的使用。
由于本案例研究的意图在于强调开发的产品而不是过程,所以不会详细考虑由统一过程定义的这些工作流的结构,而在真正需要的地方将在介绍UML表示法的同时,简略介绍开发中涉及的活动。
4.1 非正式的需求要开发的系统的意图是,通过改进为顾客预定和分配餐台的过程,支持一家餐馆的日常经营。
这家餐馆当前采用一个手工预约系统,使用的是保存在一个大文件夹中的手写预约单。
图4.1是当前的预约单的一个例子,预约单中的每一行对应餐馆中一张特定的餐台。
预约是对特定的一个餐台登记的,每个预约中记录有“餐具”的数目,或者预期进餐者的数目,这样就能够分配一个大小适当的餐台。
这家餐馆在晚间供应三次餐点,称为“简餐”、“正餐”和“夜点”时段。
但如同预约单所表明的,这些时段无须严格遵守,可以预约跨多个时段的时间。
最后,每个预约中要记录联系人的姓名和电话。
图4.1 手工预约单为了记录各种事情,要在预约单上加一个注文。
当一行用餐者到来并在他们的餐台就座时,就划掉相应的预约登记。
如果他们就座的不是他们预约的餐台,就画一个箭头从最初预约的餐台指向新的餐台。
如果顾客打电话取消预约,并不能从表中真正地擦除,而是做一个预约已经取消的注文。
其他的信息,比如到什么时间餐台必须空出来,也可以写在预约单上。
如果有空闲的餐台,用餐者当然也可以不提前预约就进餐馆用餐,这被称为“未预约的顾客(walk-in)”,并在预约单中作为预约登记以表示餐台的占用,但不记录顾客的姓名或电话。
4.1.1 对计算机化系统的需要这家餐馆的管理人员已经确认了很多与手工系统相关的问题。
手工系统速度慢,而且,预约登记单很快就变得难以理解。
这可能导致经营上的问题,例如,实际上有空餐台而由于这个预约单不是很明显,会妨碍顾客进行预约。
一、餐馆系统业务建模

• 观察者模式
– 一个对象的变化需要改变其它对象,并且你不知道 有多少对象需要改变 – 一个对象应该能够通知其它对象,而无需设想那些 对象是谁
应用设计模式
用例:记录预约(三)
• 记录预约—餐桌过小(例外)
– 接待员输入要求预约的日期 – 系统显示该日的预约
– 接待员输入顾客的姓名和电话,预约的时间, 用餐人数和餐桌号
– 预约用餐人数大于餐桌能容纳的人数,系统发 出警告信息询问用户是否预约 – 如果回答否,终止预约 – 如果回答是,确定预约,并附有警告标志。
– 边界类 – 实体类 – 控制类
• 软件架构
– 显示层 – 应用层 – 存储层
2.4 用例顺序图
• 系统消息:面向对象中,用户与系统打交道是 通过发送消息, • 谁接收消息
– 领域模型中的类
– 边界对象(边界对象在系统架构中属于表示层,需 要根据消息分析应用层中对象的行为,不合适)
– 一个用例中可能有许多消息,检查消息的正确性, 协调系统产生的响应——控制对象。 – BookingSystem控制类负责接收系统消息
Restaurant BookingSystem : Staff 1: Display(date) 2: getBooking(date)
3: updateDisplay
Restaurant对象如何识别返回的预约?
2.4.2 显示预约(细节)
Restaurant BookingSystem : Staff 1: Display(date) 2: getBooking(date) 3: getDate 4: updateDisplay : Booking
点餐系统UML设计

点餐系统UML设计点餐系统UML设计是一种用于描述点餐系统的统一建模语言(Unified Modeling Language,UML)图形表示方法。
在点餐系统中,顾客可以通过系统选择想要的食物并下订单,系统会将订单传输给厨房或者餐厅,并进行相应的处理。
以下是一个点餐系统的UML设计示例:1.用例图用例图描述了系统的功能和角色之间的交互。
一个基本的点餐系统用例图包括以下元素:-顾客:顾客可以进行点餐、支付订单和查看订单等操作;-服务员:服务员负责接待顾客、记录订单和传输订单给厨房;-厨房:厨房负责接收订单并进行食物制作;-餐厅管理员:餐厅管理员负责管理菜单和餐厅信息。
2.类图类图描述了系统中的类以及它们之间的关系。
一个基本的点餐系统类图包括以下类:-顾客类:顾客拥有属性(如姓名、手机号)和方法(如点餐、支付订单);-服务员类:服务员拥有属性(如姓名、工号)和方法(如记录订单);-订单类:订单拥有属性(如订单编号、下单时间)和方法(如计算订单总价、传输至厨房);-厨房类:厨房负责接收订单并进行食物制作;-菜单类:菜单拥有属性(如菜名、价格)和方法(如添加菜品、修改菜品);-餐厅类:餐厅拥有属性(如名称、地址)和方法(如添加菜单、派送订单)。
3.活动图活动图描述了系统中各个对象间的动态行为以及对象间的相互作用。
一个基本的点餐系统活动图包括以下活动:-顾客点餐:顾客选择菜品、调整菜品数量并下单;-订单处理:服务员接收订单、记录订单并传输至厨房;-食物制作:厨房接收订单、制作食物并通知完成状态;-订单派送:餐厅接收订单、派送订单并通知顾客。
4.状态图状态图描述了一个对象在不同状态下的转换。
在点餐系统中,可以使用状态图描述订单状态的转换,如订单状态可以是“等待中”、“制作中”和“已完成”。
5.顺序图顺序图描述了系统中各个对象之间的消息传递顺序。
在点餐系统中,可以使用顺序图描述顾客下单时与服务员的交互、服务员传输订单给厨房以及订单派送给顾客的过程。
酒店订餐管理系统UML建模

大学软件学院《UML系统建模基础教程》大作业酒店订餐管理系统UML建模一、需求分析随着科学技术和互联网的迅猛发展,网络已经改变了我们的生活,通过网络交易成为当下的一种时尚,受到越来越多的人青睐,各个行业也将其当成一种重要的营销手段,酒店订餐管理系统也得益于网络的发展,提高了管理水平,扩大了营销围。
酒店订餐管理系统是中小型酒店餐饮企业用来对客人的订餐活动进行管理的信息管理系统。
该信息系统不仅能够为客人提供方便的订餐功能,同时也能够达到提高酒店餐饮企业管理水平的目的。
订餐系统的功能性需求包括以下容:(1)酒店的接待员使用为客人提供订餐服务,根据客人的订餐要求,在指定的时间和桌号安排好客人的就餐事宜;按客人的要求执行修改订单的操作;在客人临时取消预订时删除订餐信息;在客人订餐时间到达前,及时提供提醒服务。
(2)酒店领班在订餐客人到店用餐时和用餐离店后分别在系统做好记录并保存;能够为客人注册成为会员;可以查询、修改和删除会员信息;可以为客人提供换桌服务。
二、酒店订餐管理系统UML建模简介:基于UML建模的酒店订餐管理系统,通过用例图、类图、序列图、协作图、状态图、活动图、构件图、部署图来进行酒店订餐管理系统建模的。
三、创建系统的用例模型:(一)接待员(Receptionist)用例图:接待员用例能够通过该系统进行如下活动:(1)记录订餐信息。
接待员将客人的订餐要求输入到系统中保存。
(2)订餐定时提醒。
接待员在客人的预定的订餐时间之前给客人一个提醒,同时再次加以确认。
(3)取消订餐记录。
客人因临时原因取消订餐,接待员将系统中原来的订餐信息取消。
用例规约:用例名称记录订餐顾客(二)领班(Captain)用例图:领班用例能够通过该系统进行如下活动:(1)记录订餐客人到店。
领班在有预订的客人前来酒店就餐时,在系统中记录预订客人已到店的信息并保存。
(2)记录订餐客人离店。
领班在预订的客人用餐离店后,在系统中记录预订客人用餐完毕的信息并保存,表示整个订餐过程结束。
西南交通大学食堂网上订餐系统UML分析建模

食堂的网上自动订餐系统专业:软件工程班级:软件一班姓名:某某某学号:目录食堂的网上自动订餐系统 0画图工具: (2)一、用例图 (2)1、注册登陆用例图 (2)2、系统管理员用例图 (3)3、订餐系统整体用例图 (4)二、活动图 (5)1、用户注册活动图 (5)2、用户登陆活动图 (6)3、管理员对用户进行增删改操作活动图 (7)4、管理员查询用户活动图 (8)5、订餐系统活动图 (9)三、顺序图 (10)1、系统管理员的顺序图 (10)2、会员的顺序图 (10)四、类图 (11)画图工具:IBM Rational Rose Professional J Edition 200版3 。
用例图1、注册、登陆用例图送餐人员<<include>>会员<<include>>登陆<<include>><<include>>注册<<include>><<include>>顾客系统管理员厨师2、系统管理员用例图<<include>>系统管理员<<include>>统计分析 <<include>> 信誉度统计异常安全退出<<include>>评价分析<<include>><<include>>用户管理删除用户退出用户黑名单积分统计增加用户<<include>>查询信息3、订餐系统整体用例图系统管理员会员<<include>><<include>> 登陆<<include>>增加商品<<include>><<extend>> 搜索浏览<<include>> 结算删除商品<<include>><<include>><<include>><<include>> <<include>><<extend>>退出查询订单打印订单生成订单确认订单用户信息管理<<include>>删除信息<<include>><<include>><<include>> <<include>><<extend>><<include>><<include>>购物车管理异常安全退出<<include>><<include>>修改订单增加信息修改信息<<include>>校园卡支付接口活动图1、用户注册活动图2、用户登陆活动图注:由于其他用户登陆时的活动图类似,我就没有一一列举了。
可视化建模与UML餐饮管理系统建模

《可视化建模与UML》课程结业报告课题名称: 餐饮管理系统建模**: ***学号: 9 0 9 1 4 0 2 6 班级: 09 软件本(2)班学院: 电子与信息工程学院****: ***完毕日期: 2023年5月28日目录第一章引言....................................... 错误!未定义书签。
1.1 系统目的.................................... 错误!未定义书签。
1.2 用户特性.................................... 错误!未定义书签。
1.3 运营环境和资源.............................. 错误!未定义书签。
1.4 软件的体系结构.............................. 错误!未定义书签。
第二章用例模型................................... 错误!未定义书签。
2.1用例图描述................................... 错误!未定义书签。
2.2构建用例图................................... 错误!未定义书签。
2.3结账用例图................................... 错误!未定义书签。
2.4经理用例图................................... 错误!未定义书签。
2.5人事管理和登录管理用例图..................... 错误!未定义书签。
第三章类模型.................................... 错误!未定义书签。
3.1类图的描述................................... 错误!未定义书签。
3.2构建类图..................................... 错误!未定义书签。
餐厅预订系统UML设计

确定预约
以按钮形式确认提交
显示预约模块
全部采用复合单选框的模式选择相应的日期时间,以按钮方式确认查询。
更新预约模块
客户名
非空
修改确认
采用复选框形式更改已有信息,以click按钮方式提交.
取消预约模块
客户名
非空
删除确认
采用复选框形式更改已有信息,以click按钮方式提交.
记录预约模块:输出项对相应的数据库进行操作,显示失败或者成功页面,完成后显示所有预约。
(3)运用RSA软件将构件图映射为相应的代码框架并选择其中的部分加以实现;
(4)利用集成环境、编制一个图形用户界面将上述实现的功能加以演示。
二、实验环境(实验设备)
操作系统:Microsoft Windows NT 2003
Microsoft Windows 2000
Microsoft Windows 98
系统功能描述
功能名称
功能描述
功能约束
处理过程
添加预约
包括早、中、晚三部分可预定时间,可预约当天及以后3天内的所有空闲餐座当桌位被预订后桌位在预定时间前后一小时保留显示为餐座不可用
预约餐座标记为空闲时可用
通过相关记录预约功能模块将信息读入数据库。
删除预约
当客人取消预定,经前台管理人员确定后,系统将已经预订的桌位改为空闲状态。
无
时间特性名称
时间特性要求
说明
响应时间
3秒之内
无
更新处理时间
5秒之内
无
数据的转换和传送时间
2秒之内
无
数据名称
媒体
格式
数值范围
精度
输出控制
说明
数值型
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
面向对象建模技术课程设计课程名称面向对象建模技术题目餐厅订餐管理系统系部管理学院专业信息管理与信息系统班级信管1002班学号学生姓名任课教师2013 年月日《面向对象建模技术》课程设计评审表餐厅订餐管理系统一、项目概述(一)选题背景及意义随着我国市场经济的快速发展,各行业都呈现出生机勃勃的发展景象,其中餐饮业的发展尤为突出。
近年来已呈现出高速发展的态势。
但在快速发展的同时,餐饮业在日常经营管理中仍普遍采用手工管理方式,整体科技含量低。
随着餐饮企业规模和数量的不断增长,手工管理模式无论是在工作效率、人员成本还是提供决策信息方面都已难以适应现代化经营管理的要求,因此制约了整个餐饮业的规模化发展和整体服务水平的提升。
有效的管理成为了一个难题,为能有效的解决这些问题提高企业的经济效益,在这些中小型饭店中采用工作流技术,结合餐厅绿色管理内容,实施计算机管理,将信息系统视为一条有效的解决途径。
本系统使用计算机对餐饮信息进行管理,具有手工管理所无法比拟的优点,例如检索速度快、可靠性高、存储量大、成本低等,进一步提高了管理的效率。
同时人们生活水平的提高,人们对自己的饮食也渐渐的注重起来,很多人在进行紧张工作之余会选择享受没事进行放松。
但是很多时候会出现这样的情况,人们到餐厅就餐,会出现排队或没有座位的现象。
还有就是有的人懒得出去,希望在自己的家就能享受到美味的食物。
所以饭店预订就成了人们的首选,目前比较普遍的是电话订餐,这种预订方式简洁,方便,但是由此引发的问题也比较多,主要是订餐后出现饭店并没有将信息记录在案,这样的预定就变得没有了意义,另外这种订餐方式只是进行电话的预订,很可能会出现订餐但是不履行订单也不进行取消的现象,订餐信息不了解就会进行相关信息的询问,这样就在一定程度上造成了时间的浪费,饭店人员会在同一天反复重复相同的信息,造成了人力资源的浪费。
有效的解决途径。
为了方便餐馆人员能够按照客户需求分配餐桌,并能有条理的记录订菜单,减少因管理无序与客户产生不必要的冲突本系统是一个餐馆订餐系统,主要功能是为餐馆提供订餐记录和维护功能,同时由还扩展了订菜和定时提醒的功能,有利于消费者的需求。
总之,本系统设计的主要意义在于它能够切实有效地指导工作人员规范业务操作流程,更高效、快捷地实现业务的管理,保证信息的存储安全,提高管理水平和工作效率。
(二)国内外研究状况目前国内外关于餐饮管理的系统很多,这种系统的侧重点和采用的技术都不一样,但相同的一点都是与数据库的相关操作,数据的录入有三种方式,一是基于普通电脑,二是基于触摸屏,三是采用无线点菜系统,而无线技术又有基于红外技术和基于无线网络的技术。
从目前国内的发展趋势看,餐饮软件的发展也正处于蓬勃发展的时期,餐饮系统越来越多的采用触摸屏,而无线技术正在逐步成熟起来,利用数据库技术对大量的资料进行管理,摒弃了传统的人工管理阶段。
国外很多设计中采用了先进的餐饮管理方法,融合了现代餐饮行业的特点,通过科学的管理方式、优化的管理流程和现代化的管理工具——计算机网络系统,规范了餐饮行业管理标准,降低了服务成本(节约人力财力资源)、提高服务质量以及工作效率。
餐饮资讯与网站这种现代信息载体结合起来,发挥网络优势,让餐厅在互联网上安个家,通过一系列个性化的服务让餐厅在吸引新客户、留住老客户的方面取的新的突破,此外,通过网上餐饮独家推出的网上订位、订餐功能还可以集中管理餐厅的客户群,方便与固定客户、集团客户之间的联系,使餐饮企业具有更多的宣传渠道来提高效益并且使消费者有了更多的选择,以此让餐饮企业在消费者中间留下一个深刻的印象和美好的形象。
二、系统需求分析(一)系统功能需求分析本系统的基本需求是餐馆在营业时记录预约、更新预约单信息、分配餐桌以及接待未预约的顾客的能力,还添加了会员业务,为会员提供提前点菜的服务。
主要的功能有下订单、修改订单、取消订单以及在顾客未按时到达时及时提醒顾客;同时还能记录未预约的顾客(Walk-In);维护订单和未预约记录,如记录到达、离开,以便及时更新餐桌的状态;附加的功能有管理会员信息,为会员提供提前点菜的服务。
根据需求分析可以划分为三大模块,他们是订餐管理模块、餐馆管理模块和会员管理模块。
如图2-1 所示:1.订餐管理模块本模块供记录订单、修改订单(换桌、换时间等)、取消订单、定时提醒和查询空桌等功能。
2.餐馆管理模块本模块将餐厅的菜品和餐桌信息通过标准化的管理操作加以整合,使得菜品的价格、配料、功效和图片以及餐桌的使用情况可以完全呈现在客户面前,使得客户可以方便地选择。
同时也提供增加、修改、删除的管理功能。
3.会员管理模块为了方便餐馆会员,会员管理模块分别提供增加、修改、删除的管理功能。
以上几个模块之间的耦合性比较小,但其中订餐管理会和其他几个模块所维护的信息相关联,因此系统应该注意提供数据完整性的维护功能。
图2-1 功能需求模块(二)基本数据维护模块基本数据维护模块主要包括以下几个方面:如图2—2所示1.添加、修改、删除订餐信息餐厅人员对消费者订单信息,进行添加;如果消费者对订单另外有所要求或选择其他,将对已经添加的订单信息进行修改或删除;对已经用餐完毕的消费者,要及时清理掉信息。
2.添加、修改、删除餐桌信息餐厅对餐桌的信息也应进行信息化管理,避免造成信息的冗余等,应及时对餐桌信息,进行添加,或对信息进行修改、删除。
3.添加、修改、删除菜品信息对于新出的菜品,要及时的进行添加,避免信息的滞留;对于不太受欢迎的菜品,应及时修改,或者有的菜品已经改良,也要及时的进行修改;对于淘汰掉的菜品,应及时删除,避免造成对消费者的误解。
图2-2基本数据维护模块(三)基本业务模块基本业务模块主要包括以下几个方面:如图2—3所示1.管理员根据订单信息管理员根据消费者订单,对菜品进行添加、修改、删除处理。
管理员根据消费者订单,对餐桌进行添加、修改、删除处理。
2.管理员根据菜单信息管理员根据餐厅的菜单,对菜品进行添加、修改、删除处理。
图2—3 基本业务模块(四)数据库模块数据库模块主要包括以下几个方面:如图2—4所示1.菜单信息管理除了对菜单信息进行添加、修改、删除管理,也包括价格、图片的录入,以及在特殊节日里,菜品的优惠。
2.餐桌信息管理需要对餐桌的空余情况进行记录,以及客户对餐桌的位置也已进行记录。
3.会员信息管理对会员信息的管理包括会员的姓名、性别、联系方式、预约时间等进行记录。
图2—4 数据库模块(五)信息查询模块信息查询模块主要是查询数据库中的信息,如图2—5 所示:1.菜品信息查询主要是查询已经录入的菜品信息以及价格。
2.餐桌信息查询主要查询餐桌的信息(如:位置。
空余情况等)3.会员信息查询主要查询当前所有录入的会员信息(如:姓名、联系方式等个人信息),此项查询只能管理员进行查询。
图2—4信息查询模块三、UML基本模型(一)UML模型框架要建立UML模型框架,可以选择Rational Rose的菜单栏的【File→New】菜单项,打开如图3-1所示的“Create New Model”对话框,选择J2EE模式,然后点击【OK】按钮。
图3-1新建模型此时,Rational Rose会自动加载J2EE本身的一些构架模型。
加载完成之后,就可以开始设计自己的模型,在此之前应保存该模型,并且将模型取名为“餐厅订餐系统”。
(二)用例图及用例图说明用例分析是基于UML的面向对象建模过程的一个显著的特点,在基于UML建模的过程中,用例处在一个核心的位置。
系统分析要求接触用户,同时系统还要控制不同用户角色和权限。
通过对用户进行分类并了解他们的需求,从而了解用户所需功能、安全性及用户界面分组的具体内容的需求。
本系统是一个餐馆订餐系统,主要功能是为餐馆提供订餐记录和维护功能,同时由我们自己扩展了订菜和定时提醒的功能。
下面使用了用例图的方式表现了整个系统的所有功能:图3-2 用例图【系统的用例图说明】1.记录预约用例:接待员执行“显示预约”用例;有一张合适的餐桌可以使用;接待员输入顾客姓名和电话号码、预订时间、用餐人数以及预留的餐桌;系统记录和显示新预约;2.订餐提醒用例:系统显示预约用餐时间超过当前系统时间的预约;接待员执行“显示预约”用例;接待员打电话提醒顾客,询问是否取消预约;如果顾客回答“否”,用例终止;如果顾客回答“是”,接待员执行“取消预约”用例;3.取消订单:接待员选择要求的预约;接待员取消预约;询问接待员确认取消;接待员回答“是”,系统记录取消并更新显示;4.换桌用例:侍者领班选择需要的预约;领班改变该预约的餐桌分配;系统记录改变并更新显示;5.显示餐厅预约信息用例:用户输入一个日期;系统显示当日的预约;6.查找空桌用例:接待员输入日期和时间;系统显示空桌的信息;7.修改会员用例:用户执行“显示会员信息”用例;修改会员信息;系统询问用户确认修改;用户确认修改;用户回答“是”,系统记录更新并显示更新;8.显示会员信息用例:用户输入会员号;系统显示该会员的信息;9.删除会员用例:侍者领班选择要取消的会员;侍者领班取消该会员;系统询问侍者领班确认取消;侍者领班回答“是”,系统记录取消并更新显示;10.会员注册用例:侍者领班输入顾客的姓名和电话号码;系统记录并显示该顾客的信息;11.记录离开用例:接待员输入餐桌号;系统显示使用该餐桌的所有预约和未预约登记;如果存在预约或未预约登记处于用餐状态,接待员确认该预约或未预约登记已经离开;系统对此进行记录并更新显示器,将顾客标记为已离开;12.记录未预约登记用例:侍者领班执行“显示预约”用例;侍者领班输入时间、用餐人数和分配给顾客的餐桌;系统记录并显示新预约;13.记录到达侍者领班执行“显示预约”用例;侍者领班确认一个选定的预约已经到达;系统对此进行记录并更新显示,将顾客标记为已到达;14.退出用例。
(三)时序图及时序图说明时序图表示了对象之间传送消息的时间顺序。
每一个类元角色用一条生命线来表示,即用垂直线代表整个交互过程中对象的生命期。
生命线之间的箭头连线代表消息。
序列图可以用来进行一个场景说明——即一个事务的历史过程。
序列图的一个用途是用来表示用例中的行为顺序。
当执行一个用例行为时,序列图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。
由于涉及的时序图过多,仅用会员信息的各项联系时序图以及订单的部分时序图,如下所示:1.会员注册会员注册功能。
可以增加新的会员。
图3-3会员注册时序图2.显示会员信息显示会员信息功能,显示选定的会员信息,以供管理员查看并作为修改的依据。
图3-4显示会员信息时序图3.修改会员信息修改会员信息提供给管理员以修改会员信息的功能,比如联系方式、用户姓名、信誉度等。