酒店点菜系统需求分析.docx

酒店点菜系统需求分析.docx

《酒店点菜系统需求分析.docx》由会员分享，可在线阅读，更多相关《酒店点菜系统需求分析.docx（10页珍藏版）》请在冰豆网上搜索。

酒店点菜系统需求分析

1设计目的

本课程设计是学生学习完《面向对象分析与设计》课程后，进行的一次全面的综合训练，通过课程设计，让学生更好地掌握UML建模原理及实现方法，加深对UML建模基础理论的理解，加强学生的动手能力。

2设计任务

随着信息时代到来，信息化是餐厅和酒店发展的必然改革之一。

现在越来越多的餐厅和酒店开始关注餐饮点菜系统，餐厅和酒店开始使用餐饮点菜软件代替手工管理。

而在移动互联网时代的推动下，点菜系统电子化将成为餐厅和酒店在移动互联网时代制胜的砝码之一。

3设计内容

3.1设计内容概述

3.1.1概述

本系统适用于中、高档咖啡厅、KTV、快餐厅、酒楼等餐饮行业，是一个为方便顾客点菜更人性化的，贴心的点菜系统。

系统不止可以使顾客自主点餐，同时还为顾客提供了轻松一刻，包含小游戏和小贴士，本软件还为顾客提供了特殊的额可附加的要求选项，可以输入菜品制作附注：

如不放香菜，不吃蒜，对某些配菜过敏或用药忌讳等。

系统的主要功能：

（1）点餐模式：

订餐、点菜（包括浏览、搜索菜单）。

（2）用餐模式：

加菜、换菜、呼叫服务员等。

（3）餐毕模式：

客户满意度、结账等。

3.1.2业务流程（活动图描述）

活动图是阐明了业务用例实现的工作流程。

业务工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。

工作流程通常包括一个基本工作流程和一个或多个备选工作流程。

工作流程的结构使用活动图来进行说明。

餐厅点菜系统的工作流程如图3.1、图3.2和图3.3所示。

图3.1点餐模式的业务流程

图3.2用餐模式的业务流程

图3.3餐毕模式的业务流程

3.2需求分析

在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。

需求分析是软件工程中的一个关键过程。

在这个过程中，系统分析员和软件工程师确定顾客的需要。

只有在确定了这些需要后，他们才能够分析和寻求新系统的解决方法。

需求分析阶段的任务是确定软件系统功能。

3.2.1用例图

用例图是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

本部分需要用6个用例图来对餐饮点菜系统进行描述，分别是餐饮点菜系统用例图、点餐模式用例图、用餐模式用例图、餐毕模式用例图、轻松一刻用例图和特殊附加用例图。

图3.4餐厅点菜系统用例图

图3.5点餐模式用例图

图3.6用餐模式用例图

图3.7餐毕模式用例图

图3.8轻松一刻用例图

图3.9特殊附加用例图

3.2.2领域类图

类图由许多说明性的模型元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）组成。

类图可以组织在包中，仅显示特定包中的相关内容。

类图是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系；它用于描述系统的结构化设计。

餐厅点菜系统的领域类图如图4.10所示。

图3.10餐厅点菜系统领域类图

3.3. 可行性分析 

3.3.1 技术可行性  

a．经费、投资方面的来源和限制：

各种硬件和工作人员工资需至少10万元 

b．硬件、软件、运行环境和开发环境方面的条件和限制：

软件需求：

操作系统WINDOWS 2000 Advance Server以上；数据库服务器端软件ORACLE 9I， JAVA。

硬件需求：

10M以上的LAN接入网络带宽，P4 3.0G Xeon CPU /1G内存/360G（10K） SCSI硬盘的服务器，P3以上微机（带网卡）的客户机，P4 3.0G Xeon CPU /1G内存/36G（10K） RAID硬盘的数据库服务器

3.3.2经济可行性 

餐馆目前由于完全采用纯人工的方式来完成工作的，服务人员要一边登记某些客人的基本信息，一边还要忙着对其它的客人进行点餐服务，工作量大，耗时比较多，所以工作效率低。

根据目前餐馆内部员工的日人工成本为：

x人 * y元/人＝z元。

我们还不能计算出因效率低下而给餐馆带来的无形经济损失，如果这一部分也看作是成本，那将远远超出目前的计算数额。

而如果开发出一个能满足业务要求的餐馆计算机监护管理系统，在采用生命周期的前提下，从问题识别到系统实施、评价、维护，开发周期如果以两年计，共需人工成本m元，各种软硬件成本n元，日常维护费用o元，共计成本费用p元，略高/低于两年的人工费用总和。

同样，我们也无法估计算出由于系统的开发应用使餐馆运营效率提高而带来的无形的巨额经济效益，由于系统能在未来较长的一段时间内稳定地发挥作用，这对于餐馆的提高管理水平有很大的帮助，才能使餐馆早日接入到总行的更高层次的网络体系中，可以更加广泛的吸收各方面的信息资源，可为餐馆业务在将来的扩张打下坚实的基础，其经济效益将更上一层楼

3.3.3法律可行性 

法律可行性是考虑要开发系统是否存在任何侵犯、妨碍和责任问题，用户操作可行性考虑待开发软件的运行方式在用户组织内是否行得通，现行管理制度、人员素质、操作知识是否可行。

由于在本系统中是有合同作为双方合作的基础，所以不会存在任何侵犯、妨碍和责任问题。

即使存在了，也可以根据合同进行分析，一定有人会负责任，所以此系统完全可以进行开发。

由以上经济、技术、操作和法律四方面的分析可以看出，本系统的开发时机成熟，从多种角度考虑，都是可行的.

3.4软件设计

3.4.1用例实化（顺序图和协作图）

交互图是用来描述对象之间以及对象与参与者之间的动态协作关系以及协作过程中行为次序的图形文档。

交互图包括顺序图和协作图。

顺序图是先是对象之间交互的图，这些对象是按照时间顺序排列的。

协作图是用于描述系统行为是如何由系统的成分协作实现的图。

如图4.11与图4.12所示，表示了餐厅点菜系统的顺序图和协作图。

图3.11餐厅点菜系统顺序图

图3.12餐厅点菜系统协作图

3.4.2系统运行状态图

状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。

如图4.13所示，表示了餐厅点菜系统的状态图。

图3.13餐厅点菜系统状态图

3.4.3业务逻辑类图

类图是描述类和类之间的静态关系，类图不仅显示了信息的结构，同时还描述了系统的行为。

如图4.14所示，就是用类图描述餐厅点菜系统。

图3.14餐厅点菜系统类图

4总结与展望

通过本次实验，加深了我对UML建模的理解，加强了解决实际问题的能力。

利用软件，运用已有建模方法，对系统进行建模，进行分析。

利用本学期学习的UML知识，画出用例图，类图等对系统进行分析。

本次设计使我对软件设计有了进一步的认识，这对以后的学习工作是很有帮助的，为以后的发展做了良好的铺垫。

在设计过程中我们会遇到很多大大小小的问题，比如我在画状态图的时候就不知道该怎么分析。

通过向同学请教和上网查找资料，顺利的解决了这个问题。

在进行需求分析和画图的时候，我遇到了很多困难，但是经过老师及同学们的帮助和多次参考网络和课本后，我顺利的完成了课程设计。