餐厅订餐管理系统建模作业Word文档格式.docx
《餐厅订餐管理系统建模作业Word文档格式.docx》由会员分享，可在线阅读，更多相关《餐厅订餐管理系统建模作业Word文档格式.docx（27页珍藏版）》请在冰豆网上搜索。
数据库模块（3分）
信息查询模块（3分）
系统的UML基本模型（55分）
UML模型框架（5分）
系统的用例图（10分）
系统的时序图（10分）
系统的协作图（10分）
系统的状态图（10分）
系统的活动图（10分）
系统中的类
（10分）
类图的生成（5分）
各个类之间的关系（5分）
系统的配置与实现（10分）
系统的组件图（5分）
系统的配置图（5分）
开发心得（5分）
总评（100分）
指导教师签名
评审时间：
年月日
一、项目概述
（一）选题背景及意义
随着我国市场经济的快速发展，各行业都呈现出生机勃勃的发展景象，其中餐饮业的发展尤为突出。
近年来已呈现出高速发展的态势。
但在快速发展的同时，餐饮业在日常经营管理中仍普遍采用手工管理方式，整体科技含量低。
随着餐饮企业规模和数量的不断增长，手工管理模式无论是在工作效率、人员成本还是提供决策信息方面都已难以适应现代化经营管理的要求，因此制约了整个餐饮业的规模化发展和整体服务水平的提升。
有效的管理成为了一个难题，为能有效的解决这些问题提高企业的经济效益，在这些中小型饭店中采用工作流技术，结合餐厅绿色管理内容，实施计算机管理，将信息系统视为一条有效的解决途径。
本系统使用计算机对餐饮信息进行管理，具有手工管理所无法比拟的优点，例如检索速度快、可靠性高、存储量大、成本低等，进一步提高了管理的效率。
同时人们生活水平的提高，人们对自己的饮食也渐渐的注重起来，很多人在进行紧张工作之余会选择享受没事进行放松。
但是很多时候会出现这样的情况，人们到餐厅就餐，会出现排队或没有座位的现象。
还有就是有的人懒得出去，希望在自己的家就能享受到美味的食物。
所以饭店预订就成了人们的首选，目前比较普遍的是电话订餐，这种预订方式简洁，方便，但是由此引发的问题也比较多，主要是订餐后出现饭店并没有将信息记录在案，这样的预定就变得没有了意义，另外这种订餐方式只是进行电话的预订，很可能会出现订餐但是不履行订单也不进行取消的现象，订餐信息不了解就会进行相关信息的询问，这样就在一定程度上造成了时间的浪费，饭店人员会在同一天反复重复相同的信息，造成了人力资源的浪费。
有效的解决途径。
为了方便餐馆人员能够按照客户需求分配餐桌，并能有条理的记录订菜单，减少因管理无序与客户产生不必要的冲突本系统是一个餐馆订餐系统，主要功能是为餐馆提供订餐记录和维护功能，同时由还扩展了订菜和定时提醒的功能，有利于消费者的需求。
总之，本系统设计的主要意义在于它能够切实有效地指导工作人员规范业务操作流程，更高效、快捷地实现业务的管理，保证信息的存储安全，提高管理水平和工作效率。
（二）国内外研究状况
目前国内外关于餐饮管理的系统很多，这种系统的侧重点和采用的技术都不一样，但相同的一点都是与数据库的相关操作，数据的录入有三种方式，一是基于普通电脑，二是基于触摸屏，三是采用无线点菜系统，而无线技术又有基于红外技术和基于无线网络的技术。
从目前国内的发展趋势看，餐饮软件的发展也正处于蓬勃发展的时期，餐饮系统越来越多的采用触摸屏，而无线技术正在逐步成熟起来，利用数据库技术对大量的资料进行管理，摒弃了传统的人工管理阶段。
国外很多设计中采用了先进的餐饮管理方法，融合了现代餐饮行业的特点，通过科学的管理方式、优化的管理流程和现代化的管理工具——计算机网络系统，规范了餐饮行业管理标准，降低了服务成本（节约人力财力资源）、提高服务质量以及工作效率。
餐饮资讯与网站这种现代信息载体结合起来，发挥网络优势，让餐厅在互联网上安个家，通过一系列个性化的服务让餐厅在吸引新客户、留住老客户的方面取的新的突破，此外，通过网上餐饮独家推出的网上订位、订餐功能还可以集中管理餐厅的客户群，方便与固定客户、集团客户之间的联系，使餐饮企业具有更多的宣传渠道来提高效益并且使消费者有了更多的选择，以此让餐饮企业在消费者中间留下一个深刻的印象和美好的形象。
二、系统需求分析
（一）系统功能需求分析
本系统的基本需求是餐馆在营业时记录预约、更新预约单信息、分配餐桌以及接待未预约的顾客的能力，还添加了会员业务，为会员提供提前点菜的服务。
主要的功能有下订单、修改订单、取消订单以及在顾客未按时到达时及时提醒顾客；
同时还能记录未预约的顾客（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模型框架，可以选择RationalRose的菜单栏的【File→New】菜单项，打开如图3-1所示的“CreateNewModel”对话框，选择J2EE模式，然后点击【OK】按钮。
图3-1新建模型
此时，RationalRose会自动加载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.修改会员信息
修改会员信息提供给管理员以修改会员信息的功能，比如联系方式、用户姓名、信誉度等。
图3-4修改会员信息时序图
4.删除会员
删除会员功能，使餐厅可以注销某些用户。
图3-5删除会员时序图
5.显示订单
显示订单功能，根据用户设定的时间显示的餐桌的信息。
图3-6显示订单时序图
6.记录订单
记录订单为接待员提供记录订单的功能，但接待员接到客户的电话预约时，会使用此功能来记录客户的预约，包括吃饭时间、吃饭桌号和预约人数等。
图3-7记录订单时序图
7．定时提醒
定时提醒功能。
但订单时间已到但用餐者还没有到达时就会体现本功能的作用。
系统开辟一个线程单独来完成本功能，每隔一秒检查一下系统时间，如果到达用户设置的提醒时间，就从数据库中读取应当到达却未到达的订单信息显示给接待员，使其可以通过提供的联系方式提醒客户。
图3-8定时提醒时序图
（四）协作图及协作图说明
协作图和序列图都可以表示各对象间的交互关系，但它们的侧重点不同。
序列图用消息的几何排列关系来表达消息的时间顺序，各角色之间的相关关系是隐含的。
协作图用各个角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系。
在实际中可以根据需要选用这两种图。
一个协作图描述了系统中为实现某些服务所涉及的对象扮演的角色及其相互之间的交互。
协作图着重于有协作关系的对象之间的交互和链接（指对象实例之间的物理或概念上的链接，一个链接是某关联的一个实例）。
它可用于图示系统中的操作执行、用例执行或一个简单的交互场景。
协作图描述了对象及其之间的链接，还描述了链接的对象之间如何发送消息。
图4-1会员注册协作图
图4-2显示会员信息协作图
图4-3修改会员信息协作图
图4-4删除会员协作图
5.记录订单
图4-5记录订单协作图
6.定时提醒
图4-7定时提醒协作图
（五）状态图及状态图说明
餐厅订餐系统的状态图如下面5-1,5-2,5-3图所示
图5-1【状态图说明】
1.进行预约
2.查询数据库，看是否存在预约
3.确认到达
4.记录预约情况
图5-1记录达到状态图
图5-2【状态图说明】
显示会员信息；
修改用户信息；
显示修改信息；
更新数据库
图5-2修改会员信息状态图
图5-3【状态图说明】
1.输入餐桌号
2.查询餐桌情况，看是否存在预约
3.更新数据库
图5-3记录离开状态图
（六）活动图及活动图说明
UML中的活动图用于描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动和工作流程情况。
活动图实际上就是用来为用例的事件流建模的工具。
活动图反映一个连续的活动流。
活动图更常用于描述某个操作执行时的活动状况。
活动图有各种动作状态构成，当某个动作执行完毕，该动作的状态就会随着改变。
这样，动作状态的控制就从一个状态流向另一个与之相连的状态。
餐厅订餐系统的活动图如下面6-1、6-2、6-3图所示。
图6-1【活动图说明】
1.显示预约情况，查看是否有合适的餐桌；
2.记录顾客的个人信息，及预约情况，用餐情况
3.查看是否已经预约
4.进行记录
5.退出活动
图6-2【活动图说明】
1.显示预约情况，查询数据库；
2.是否存在预约；
3.确认到达情况；
4.创建一个预约活动；
图6-3【活动图说明】
1.显示会员信息，修改用户信息；
2.在数据库修改信息
图6-1记录预约活动图
图6-2记录到达活动图
图6-3修改会员信息活动图
四、系统中的类
（一）类图的生成
在类图中类用矩形框来表示，它的属性和操作分别列在分格中。
如不需要表达详细信息时，分格可以省略。
一个类可能出现在好几个图中。
同一个类的属性和操作可只在一种图中列出，在其他图中可省略。
关系用类框之间的连线来表示，不同的关系用连线上和连线端头处的修饰符来区别。
【类图说明】
1.数据库类包含的方法都是用来获取这些属性值并且添加数据库信息、修改数据库信息、浏览数据库信息以及查询和退出。
2.菜单类包含了2个属性：
菜名，价格。
它包含的方法都是用来选择菜品、价格。
3.餐馆类三个属性：
预订，吃饭，离开。
它包含的方法有搜索空餐桌、取消预约等
还有其他的一些的类：
（二）各个类之间的关系
各类之间的关系如图所示：
五、系统的配置与实现
（一）组件图及组件图说明
在UML中对一个系统的构件和组件图建模就是在物理结构上建模。
每一个组件图只是系统静态视图的某一个图形表示，描述系统的某一个侧面。
也就是说，任何一个组件图都不必面面俱到，试图全面地描述系统的整个面貌，系统中所有的组件图合起来才能描述系统的完整静态视图。
图5-1餐厅订餐系统组件图
（二）配置图及配置图说明
部署视图表示运行时的计算资源（如计算机及它们之间的连接）的物理布置。
这些运行资源被称作节点。
在运行时，节点包含构件和对象。
构件和对象的分配可以是静态的，它们也可以在节点间迁移。
如果含有依赖关系的构件实例放置在不同节点上，部署视图可以展示出执行过程中的瓶颈。
节点是某些计算资源的物理对象，包括计算机、外部设备等。
节点可被看作类型，也可看作实例。
节点与节点之间是通过物理连接发生关联，以便从硬件方面保证系统各节点之间的协同运行。
餐厅订餐系统的部署图描述如下：
节点：
普通PC机和移动PC机作为终端设备，1台应用程序服务器，和多台Web服务器。
节点属性
该系统各节点计算机的性能指标
节点之间联系
客户机节点是简单通信联系，采用TCP/IP通信协议；
客户通过Internet网与Web服务器相连接，利用浏览器进行查询。
图5-2餐厅订餐系统部署图
六、开发心得
订餐系统颠覆了传统餐饮业的经营模式，为用户节约了时间，缩短了距离，带来了方便，提高了效率，具有较高的实用价值。
经过本次设计，进一步加深了我们对UML语言的认识，这对以后的就业工作是很有帮助的。
在此也非常感谢我的同学们，在我的设计中，他们给予了我极大的帮助。
使我对整个设计的思路有了总体的把握，并耐心的帮我解决了许多实际问题，使我有了很大收获。
在整个过程中提出了许多宝贵意见，并给我解决了一些专业性问题。
在课程设计过程中经常给我提出许多关键性的问题，使我受益匪浅。
通过这次课程设计我最深刻的体会有两点：
一、技术方面如编码设计，可以有很多实现的方法，在系统开发中应该力求编码的简洁和可读性的统一，为此，必须有针对性地练习，以提高自己编写代码的能力；
二、无论技术如何纯熟，没有扎实的理论知识作为基础，想要开发出合理、合格的系统也是十分困难的，同时在设计的过程中发现了自己的不足之处，对以前所学过的知识理解得不够深刻，掌握得不够牢固，通过这次课程设计之后，一定把以前所学过的知识本次课程设计结束了，对于我的影响很大。
我通过这次实践学到了许多知识。
学到了设计一个简单的系统。
要注意哪些方面。
也使我知道自己哪些方面做得还不够。
在课程设计过程中，非常感谢王老师在理论和实践方面的指导，同时还要感谢热心与我讨论技术实现方法，给我提供帮助的同学。
在这里,对所有这些人都表示衷心的感激,谢谢！
课程设计报告要求：
1．字迹清楚，图表美观，文理通顺；
2．能够参考软件开发的国家标准文档，指导自己编写课程设计报告；
3．能够应用RationalRose建模工具进行相关的图表制作。
4．文中所建模型的图都要有文字说明。
5．课程设计应包含的内容：
（1）项目概述（问题陈述；
该项目目前国内外研究情况，开发本项目的意义）。
（2）系统需求分析（系统功能需求；
基本数据维护模块；
基本业务模块；
数据库模块；
信息查询模块）。
（3）系统的UML基本模型（UML模型框架；
用例图及用例图说明；
时序图及时序图说明；
协作图及协作图说明；
状态图及状态图说明；
活动图及活动图说明）。
（4）系统中的类（类图的生成；
各个类之间的关系）。
（5）系统的配置与实现（组件图及组件图说明；
配置图及配置图说明）。
（6）开发心得。
课程设计报告格式要求：
1．每一章题目：
黑体、小三号、居中；
2．正文：
标题黑体、五号，其余宋体、五号；
3．标题：
一、
（一）1．①
4．文中的图和表统一编号：
例如：
图1-1、表1-1
升级会员 