酒店娱乐部门.docx

酒店娱乐部门.docx

《酒店娱乐部门.docx》由会员分享，可在线阅读，更多相关《酒店娱乐部门.docx（40页珍藏版）》请在冰豆网上搜索。

酒店娱乐部门

数学与计算机学院

实训报告

课程名称:

软件开发设计实训

课程代码:

6014409

题目:

酒店管理之娱乐部门

年级/专业/班:

2011软件设计1班

组员姓名:

何伟

组员学号:

312011080611130

开始时间:

2013年09月16日

完成时间:

2013年12月06日

课程设计成绩：

技术水平与实际能力（50）

说明书撰写质量（50）

总分（100）

指导教师签名：

年月

目录

1需求分析模型重构（所有标题格式已调好，正文五号宋体单倍行距）4

1.1业务需求分析4

1.2非功能性需求分析6

2业务分析模型（本章图形编号从图2.1、2.2依次往下编号）6

2.1业务主角6

2.2业务用例分析7

2.3业务用例场景分析7

2.4业务用例实现8

2.5业务用例完整的包图8

3概念分析模型（本章图形编号从图3.1、3.2依次往下编号）8

3.1核心业务活动图8

3.2关键业务概念用例图8

3.3概念用例分析（活动图）9

3.4概念用例实现分析9

3.5概念用例完整的包图9

4系统分析模型（本章图形编号从图4.1、4.2依次往下编号）10

4.1系统用户分析10

4.2系统用例分析10

4.3系统用例实现分析10

4.4分析类10

4.5组件模型分析11

4.6系统分析完整的包图12

5系统设计模型（本章图形编号从图5.1、5.2依次往下编号）12

5.1软件架构/框架选择12

5.2基于架构的设计类12

6设计类优化（本章图形编号从图6.1、6.2依次往下编号）13

6.1设计类优化结果13

6.2采用的设计模式说明13

7面向对象数据库分析设计（本章图形编号从图7.1、7.2依次往下编号）13

7.1概念数据模型13

7.2概念数据模型优化/调整13

7.3物理数据模型13

总结14

附录A部分生成的SQL语句14

附录B部分生成的程序结构性代码14

1需求分析模型重构

1.1业务需求分析

1.1.1.背景、业务概况

酒店娱乐部门为住客提供娱乐、康乐、会议、宴会等活动场所数的场所数的部门，是酒店借以吸引顾客，招徕生意、提高酒店酒店声誉和营业额的部门。

该部门由两部分组成：

歌舞剧院和娱乐中心组成。

娱乐中心包括健身房、健美操、桌球、乒乓球乒乓球、棋牌、休息厅、网球场、室内游泳池等。

1.1.2业务目标

通过对业务概况的了解和整理（业务目标既可以由客户提出也可以由开发方整理得出）得出该系统的业务目标如下：

●为顾客提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务。

●规范酒店的内部管理，提高工作效率和管理效能。

●能有效的管理酒店。

●规范财务管理，收费要有监控，减少人为差错。

●建立供应商自动管理机制，对产品目录进行自动比较和筛选。

●采集数据，进行商业分析，既能帮助酒店决策，也能给顾客提供更好的服务。

1.1.3涉众分析

1.1.3.1涉众

涉众（stakehoder）是指与要建设系统相关的一切人和事情。

（注意：

涉众不等于用户，用户是系统的使用者，只是涉众的一部分）。

涉众的信息可以通过客户的岗位手册，业务手册等相关的文件中获取，也可以经过访谈而获取。

通过需求陈述分析，得出酒店娱乐部门利益相关者（涉众）如图1.1以及涉众的信息

图1.1涉众分析

图1.1

图1.2

SH001非会员顾客

没有办理会员业务的顾客。

非会员顾客又可分为：

购买产品顾客和租赁产品的顾客。

商店对这类顾客一般不会有优惠或折扣。

对于非会员的租赁顾客而言需要一定的押金。

1、可以申请办理会员

2、可以通过终端服务机快速查找相关产品信息。

3、租赁产品时，可以方便建立临时档案，押金情况。

SH002会员顾客

办理会员业务的顾客。

会员顾客又可分为：

购买产品会员顾客和租赁产品的会员顾客。

商店对这类顾客有一定的优惠或折扣。

对于会员的租赁顾客而言一般不需要押金。

1、可以方便的进行续费。

查询费用使用情况。

2、可以终端服务机快速查找相关产品信息。

3、可以通过电话查询产品并预约。

4、购买或租赁产品时可以查看折扣信息。

SH003店内终端服务机

在商店销售区域有3台触摸终端机。

主要供客户进行查询信息用

1、可以查询客户的信息。

（非会员根据临时编号查询租赁信息）

2、可以查询店内产品信息。

3、可以推荐客户热门产品信息。

SH004收银员

负责顾客的租赁记录，购买或顾客还回产品时的收费。

1、方便快捷的收费。

2、收银员交接时的快捷管理。

3、记录租赁人员的租赁信息。

4、帮助会员查询信息，并预约。

SH005服务员

负责顾客的接待工作。

帮助会员管理其信息。

1、能快捷的帮助非会员开通会员，并对会员信息进行管理

2、能方便的为会员提供续费服务

3、能接听会员电话并快捷的帮助其查询信息、预订产品

4、能够通过系统生成会员统计报表上报管理者

5、能方便找到产品位置为顾客提供服务

SH006采购人员

负责接受供应商提供的产品目录清单。

并导入到系统中进行管理。

通过供应商采购产品。

1、能方便快捷的查看库存信息。

2、能简捷的导入供应商的目录清单信息，进行比较。

3、采购回的产品能方便快捷的进行录入管理。

SH007管理人员

负责整个商店的运作管理。

1、可以查看销售报表了解销售情况

2、可以管理员工的信息。

3、设定一些会员的折扣规则。

1.1.4分析业务目标，得到系统边界。

比如业务目标一：

为顾客提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务，就是一个可能的边界。

为此，能够为顾客服务的就应该是服务部门、收银部门和店内终端服务机，而系统管理人员和采购和维护都与顾客服务无关，所以应该划分到边界之外。

系统边界的划分如图1.2所示。

图1.2边界定义

图1.3

图1.4

图1.5

图1.6

1.2非功能性需求分析

1.2.1性能（PEformance）需求

PE-1:

系统需要保证在工作期间的工作效率，尤其是会员电话预约查询时，系统响应时间应该在5秒左右。

1.2.2安全性（SEcurity）需求

SE-1:

每条充值记录都需要有日志文件能够查询。

SE-2:

保证充值或扣款事务的完整进行，不受特殊情况（如断电，误操作等）而影响数据的完整性、一致性。

2业务分析模型

2.1业务主角

首先根据涉众概要，可以得到涉众列表，其次根据所定义的边界也可以从中寻找那些站在边界外的涉众。

而这些涉众可能就是我们需要分析出来的主角（actor）。

2.1.1顾客服务业务主角

在顾客服务边界之外，顾客，管理人员、采购部门和系统维护部门是在边界外的涉众。

对所有顾客来说，假设顾客不会直接使用系统，而是由店内的服务人员代为填写电子表单并提交，另外顾客也是通过终端机对系统进行查询交互，那么服务员和终端机将代表顾客行使其系统利益，也就是说对顾客服务边界而言，虽然利益来自于顾客，但由于顾客不直接与边界说代表的系统交互，而委托店内服务人员或者终端机来代表其与系统交互，因此顾客不能构成为业务主角，服务人员和终端机则代表涉众利益的业务主角。

而管理人员、采购部门和系统维护部门都是和用户没有直接联系的，所以通过分析，可以得到顾客服务的主角。

如图2.1所示

图2.1顾客服务主角

图2.2内部服务主角

2.1.2娱乐项目管理业务主角

图2.3

2.1.3财务管理业务主角

图2.4

2.2业务用例分析

从岗位手册、业务流程指南和职务说明等一些文件以及与客户的访谈结果可以得出业务用例图。

2.2.1内部管理业务用例

根据内部管理业务分析，得到其用例如图2.5所示：

图2.5内部管理业务用例

2.2.2项目业务用例

图2.6

2.2.3财务业务用例

图2.7

2.2.4采购业务用例

图2.8

2.2.5顾客服务业务用例

图2.9

2.3业务用例场景分析

2.3.1办理会员业务用例场景分析

图2.10

2.3.2租赁交易并收取押金业务用例场景分析

图2.12

2.4业务用例实现

2.4.1会员业务用例实现

图2.13

2.4.2办理会员业务用例实现

图2.14

2.5业务用例完整的包图

图2.15

3概念分析模型

3.1核心业务活动图

图3.1

3.2关键业务概念用例图

图3.2

3.4概念用例实现分析

3.4.1付费概念用例实现分析

图3.3

3.4.1.2登入概念用例场景分析对象（类图）

图3.4

4系统分析模型

4.1系统用户分析

图4.1

4.2系统用例分析

4.2.1系统用例图

图4.2

4.2.2系统用例图场景分析（活动图）

图4.3

4.3系统用例实现分析

4.3.1系统用例实现用例图

图4.4

4.3.2用例实现场景分析（活动图）

图4.5

4.4分析类

4.4.1实体类

图4.6

4.4.2控制类

图4.7

4.4.3边界类

图4.8

4.4.4各系统分析模型

4.4.4.1娱乐部门分析类图

图4.9

4.4.5.2人员分析类图

图4.10

4.4.6总分析类图

图4.11

5系统设计模型

图5.1

5.1软件架构/框架选择

图5.2

5.1基于架构的设计类

图5.3

7面向对象数据库分析设计

7.1概念数据模型

图7.1

7.2概念数据模型优化/调整

图7.2

7.3物理数据模型

图7.4

总结

本次软件开发实训的整个过程中，指导教师陈红红老师对我们细心的指导和关怀帮助我们克服了很多困难，同时也给予了我很大的帮助。

在此表示忠心的感谢！

我这次能顺利完成软件开发实训任务，离不开老师们的关怀和指导。

他们丰富的经验和知识不仅帮助我完成了课程，还教会了我很多处理问题的方法和做事的道理。

同时也感谢我的搭档，是他们在我遇到问题的时候，停下自己的工作，帮我分析问题的原因，帮我找到解决的办法。

是他们在我想不明某些过程的时候，给我提示。

是他们在交流的时候，指出我的系统的不足之处，让我对系统不断的完善。

加深了对软件设计有关知识的理解。

之前对于软件设计各阶段的理解不透彻，很多概念都很模糊。

通过本次课程设计，我进一步了解了书本上的知识，并且亲身体验了软件设计的各个环节。

了解了软件设计的流程。

感触最深的是需求分析阶段和概念模型设计阶段。

需求分析阶段是整个数据库设计的基础，这个阶段直接影响到后面各个阶段的设计。

由于对业务不是十分精通，在这个阶段返工了好几次，起先以部门为基础画业务流程图，可是发现错了，然后以业务为基础画业务流程图。

反反复复的修改。

如果这个阶段做的不好，后面就无法继续进行下去。

概念模型设计阶段，最重要的是从数据流图中抽象出实体，并且要考虑冲突的发生。

更深入的了解并掌握了PowerDesigner的功能。

由于在有知识掌握的不是太好，实习的时候也只是按实习指导书上的代码进行编写，并不了PowerDesigner的真正原理，但是在此次课程设计中，大量的用到PowerDesigner了解了它们的功能和原理。

这次课程设计采取5人一组的方式，锻炼了我们相互的合作精神，让我们亲身体验到合作的重要性。

在做系统时，每个人的不同的想法组合起来，可以减少系统的漏洞。

同时，学习同伴在编程序中的好的习惯。

这次软件开发实训，在正式开始前我们就着手进行了，但是因为对业务的不了解性，虽然利用三天做需求分析，可是在真正的开始课程设计的时候，发现需求分析做的很不好，存在很多的问题。

所以重新修改需求分析，延误了进度。

软件开发实训作是一个不断学习新鲜事物的过程，从设计初的不懂到最后能够顺利完成，我体会到在实践中学习的重要性，这对于将来我走上工作岗位具有重要意义、由于前期工作的不彻底，对系统的需求分析的要求认识不够清楚，使得后续的工作不得不经常返回去修改。

使我体会到在设计中的每一步的重要性，如果上一个步骤不能很好的完成，在后续的设计将会付出几倍的代价。

附录A部分生成的SQL语句

）顾客娱乐消费信息表的建立：

createtableConsumelist

（Gnochar（20）,

Atnochar（20）,

Amountfloat,

Wtimedatetimenotnull,

primarykey（Gno,Atno）,foreignkey（Gno）referencesguest（Gno）,

foreignkey（Atno）referencesAtariff（Atno））

附录B部分生成的程序结构性代码

当插入新的娱乐消费信息时，触发

guest表，从新计算顾客积分和余额

CREATETRIGGERtri_grade1ONConsumelist

FORinsert

As

begin

declare@Gnochar（20）,@Atnochar（20）,@Amountint,@Atpricefloat

select@Gno=Gno,@Atno=Atno,@Amount=Amountfrominserted

select@Atprice=AtpricefromAtariffwhereAtno=@Atno

updateguest

SETgrade=grade+@Atprice*@Amount/10,balance=balance-@Atprice*@Amount

whereGno=@GnoEND