酒店管理之娱乐部门.doc

酒店管理之娱乐部门-作者：-日期：数学与计算机学院实训报告课 程 名 称: 软件开发设计实训 课 程 代 码: 6014409 题 目: 酒店管理之娱乐部门 年级/专业/班: 2011 软件设计1班 组 员 姓 名: 何伟 组 员 学 号: 312011080611130 开 始 时 间: 2013 年 09 月 16 日完 成 时 间: 2013 年 12 月 06 日课程设计成绩：技术水平与实际能力（50）说明书撰写质量（50）总 分（100）指导教师签名： 年 月 目 录1 需求分析模型重构 （所有标题格式已调好，正文 五号宋体单倍行距）41.1 业务需求分析41.2 非功能性需求分析62 业务分析模型（本章图形编号从图2.1、2.2依次往下编号）62.1 业务主角62.2 业务用例分析72.3 业务用例场景分析72.4业务用例实现82.5 业务用例完整的包图83概念分析模型（本章图形编号从图3.1、3.2依次往下编号）83.1核心业务活动图83.2关键业务概念用例图83.3概念用例分析（活动图）93.4概念用例实现分析93.5 概念用例完整的包图94 系统分析模型（本章图形编号从图4.1、4.2依次往下编号）104.1 系统用户分析104.2 系统用例分析104.3 系统用例实现分析104.4 分析类104.5 组件模型分析114.6 系统分析完整的包图125系统设计模型（本章图形编号从图5.1、5.2依次往下编号）125.1软件架构/框架选择125.2基于架构的设计类126设计类优化（本章图形编号从图6.1、6.2依次往下编号）136.1设计类优化结果136.2采用的设计模式说明137面向对象数据库分析设计 （本章图形编号从图7.1、7.2依次往下编号）137.1概念数据模型137.2概念数据模型优化/调整137.3物理数据模型13总结14附录A 部分生成的SQL语句14附录B 部分生成的程序结构性代码141 需求分析模型重构 1.1 业务需求分析1.1.1.背景、业务概况酒店娱乐部门为住客提供娱乐、康乐、会议、宴会等活动场所数的场所数的部门，是酒店借以吸引 顾客，招徕生意、提高酒店酒店声誉和营业额的部门。该部门由两部分组成：歌舞剧院和娱乐中心组成。娱乐中心包括健身房、健美操、桌球、乒乓球乒乓球、棋牌、休息厅、网球场、室内游泳池等。1.1.2业务目标通过对业务概况的了解和整理（业务目标既可以由客户提出也可以由开发方整理得出）得出该系统的业务目标如下：l为顾客提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务。l规范酒店的内部管理，提高工作效率和管理效能。l能有效的管理酒店。l规范财务管理，收费要有监控，减少人为差错。l建立供应商自动管理机制，对产品目录进行自动比较和筛选。l采集数据，进行商业分析，既能帮助酒店决策，也能给顾客提供更好的服务。1.1.3涉众分析1.1.3.1 涉众涉众（stakehoder）是指与要建设系统相关的一切人和事情。（注意：涉众不等于用户，用户是系统的使用者，只是涉众的一部分）。涉众的信息可以通过客户的岗位手册，业务手册等相关的文件中获取，也可以经过访谈而获取。通过需求陈述分析，得出酒店娱乐部门利益相关者（涉众）如图1.1以及涉众的信息 图1.1涉众分析 图 1.1图1.2SH001非会员顾客没有办理会员业务的顾客。非会员顾客又可分为：购买产品顾客和租赁产品的顾客。商店对这类顾客一般不会有优惠或折扣。对于非会员的租赁顾客而言需要一定的押金。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.61.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.32.1.3 财务管理业务主角图2.42.2 业务用例分析从岗位手册、业务流程指南和职务说明等一些文件以及与客户的访谈结果可以得出业务用例图。2.2.1 内部管理业务用例根据内部管理业务分析，得到其用例如图2.5所示：图2.5 内部管理业务用例2.2.2项目业务用例图2.62.2.3财务业务用例图2.72.2.4采购业务用例图2.82.2.5 顾客服务业务用例图2.92.3 业务用例场景分析2.3.1办理会员业务用例场景分析图2.102.3.2租赁交易并收取押金业务用例场景分析图2.122.4业务用例实现2.4.1 会员 业务用例实现图2.132.4.2办理会员 业务用例实现图2.142.5 业务用例完整的包图图2.153概念分析模型3.1核心业务活动图图3.13.2关键业务概念用例图图3.23.4概念用例实现分析3.4.1 付费概念用例实现分析图3.33.4.1.2 登入概念用例场景分析对象（类图）图3.44 系统分析模型4.1 系统用户分析图4.14.2 系统用例分析4.2.1 系统用例图图4.24.2.2 系统用例图场景分析（活动图）图4.34.3 系统用例实现分析4.3.1 系统用例实现用例图图4.44.3.2 用例实现场景分析（活动图）图4.54.4 分析类4.4.1 实体类 图4.64.4.2 控制类图4.74.4.3 边界类图4.84.4.4各系统分析模型4.4.4.1 娱乐部门分析类图图4.94.4.5.2人员分析类图图4.104.4.6 总分析类图图4.115系统设计模型图5.15.1软件架构/框架选择图5.25.1基于架构的设计类图5.37面向对象数据库分析设计 7.1概念数据模型图7.17.2概念数据模型优化/调整图7.27.3物理数据模型图7.4总结本次软件开发实训的整个过程中，指导教师陈红红老师对我们细心的指导和关怀帮助我们克服了很多困难，同时也给予了我很大的帮助。在此表示忠心的感谢！我这次能顺利完成软件开发实训任务，离不开老师们的关怀和指导。他们丰富的经验和知识不仅帮助我完成了课程，还教会了我很多处理问题的方法和做事的道理。同时也感谢我的搭档，是他们在我遇到问题的时候，停下自己的工作，帮我分析问题的原因，帮我找到解决的办法。是他们在我想不明某些过程的时候，给我提示。是他们在交流的时候，指出我的系统的不足之处，让我对系统不断的完善。加深了对软件设计有关知识的理解。之前对于软件设计各阶段的理解不透彻，很多概念都很模糊。通过本次课程设计，我进一步了解了书本上的知识，并且亲身体验了软件设计的各个环节。了解了软件设计的流程。感触最深的是需求分析阶段和概念模型设计阶段。需求分析阶段是整个数据库设计的基础，这个阶段直接影响到后面各个阶段的设计。由于对业务不是十分精通，在这个阶段返工了好几次，起先以部门为基础画业务流程图，可是发现错了，然后以业务为基础画业务流程图。反反复复的修改。如果这个阶段做的不好，后面就无法继续进行下去。概念模型设计阶段，最重要的是从数据流图中抽象出实体，并且要考虑冲突的发生。更深入的了解并掌握了PowerDesigner的功能。由于在有知识掌握的不是太好，实习的时候也只是按实习指导书上的代码进行编写，并不了PowerDesigner的真正原理，但是在此次课程设计中，大量的用到PowerDesigner了解了它们的功能和原理。这次课程设计采取5人一组的方式，锻炼了我们相互的合作精神，让我们亲身体验到合作的重要性。在做系统时，每个人的不同的想法组合起来，可以减少系统的漏洞。同时，学习同伴在编程序中的好的习惯。这次软件开发实训，在正式开始前我们就着手进行了，但是因为对业务的不了解性，虽然利用三天做需求分析，可是在真正的开始课程设计的时候，发现需求分析做的很不好，存在很多的问题。所以重新修改需求分析，延误了进度。软件开发实训作是一个不断学习新鲜事物的过程，从设计初的不懂到最后能够顺利完成，我体会到在实践中学习的重要性，这对于将来我走上工作岗位具有重要意义、由于前期工作的不彻底，对系统的需求分析的要求认识不够清楚，使得后续的工作不得不经常返回去修改。使我体会到在设计中的每一步的重要性，如果上一个步骤不能很好的完成，在后续的设计将会付出几倍的代价。附录A 部分生成的SQL语句）顾客娱乐消费信息表的建立：create table Consumelist ( Gno char(20), Atno char(20), Amount float, Wtime datetime not null, primary key(Gno,Atno), foreign key (Gno)references guest(Gno), foreign key (Atno)references Atariff(Atno) ) 附录B 部分生成的程序结构性代码当插入新的娱乐消费信息时，触发guest表，从新计算顾客积分和余额CREATE TRIGGER tri_grade1 ON Consumelist FOR insert As beg