开源项目：酒店客房管理系统——2、系统建模

[chenszhs]

——————————————————————————————
实践出真知
只有通过实际项目才能提高水平

为了广大初学者及想共同提高的同仁们，请各路英雄豪杰不吝赐教。

我将用visio（UML）进行建模，C#为编码工具,结合测试先行方法

整个开发过程我将发布在csdn上

——————————————————————————————

第一次迭代之实现用例：
用例一、员工的管理
维护员工信息，增加、删除、修改员工信息，权限管理

用例二、订房
1、电话订房
2、网上订房
了解客户信息（名称、身份证号码、联系方式）
可预定房间类型（如单人间、标间、套房）
了解入住时间、预定住房时间
24小时内进行订房确认

用例三、开房
1、如果客户是“订房”客户，确认“订房”生效
并从“订房”用例中了解信息
2、非“订房”客户
了解客户信息（名称、身份证号码、联系方式）
确定定房间类型（如单人间、标间、套房）
登记入住时间、预定住房时间
是否会员或其他打折客户，预交押金
标记房间为“已入住”
给房卡（磁卡可以设置失效时间）

用例三、结房
确认总住房金额及签单金额
结帐
收回房卡
设置房间号为空房

用例四、叫醒服务
如果客户需要叫醒，或其它提醒服务
了解叫醒时间，内容
并设置自动提醒或人工提醒

用例五、房间整理
房间每天定时消毒、清理，并作记录

用例六、住房情况分析
营业额统计（即，报表）
房间入住情况统计
楼层入住情况统计

用例七：客户满意度调查
在大堂的触摸屏设房间号对应之满意度“非常满意、满意、一般、不满意”四个等级

[jackie615]

呵呵 已经有现成的酒店客房管理系统了

[ansiboy]

挺好的写得。

[libi]

抛块砖头，等大家拿玉砸我，^_^。
首先让我们从业务领域开始分析问题，领域模型的目的是让我们了解问题域，找到一些基础的对象及其关系，另外还有建立词汇表。
从哪里开始下手呢，还是先从用例吧，而找用例的一个最好的方法就是先找ACTOR。酒店里有哪些ACTOR呢，这就要看酒店的组织结构了，像服务员、大堂经理、客房部、餐饮部、总经理、电工、保安等都有可能成为这个系统的ACTOR，假设这里我们只考虑住店管理问题（系统边界），那么前面列出那些组织和人员就有些不是我们所要关心的对象了。酒店的服务对象－－客人也是这个系统的重要ACTOR，另外还有一些外协单位如旅游公司、交通局以及超市等也有可能是系统的ACTOR，由于前面所提的系统边界，这些就不予考虑了。最后我们得到如下ACTOR：客人、前台服务员、服务员、客房部。
与客人相关的用例有：住店。与前台服务员相关的用例有：入住登记、离店登记、寄存物品。与服务员相关的用例有：提供服务。与客房部相关的用例有：管理房间、管理服务员、接受投诉。这里面，住店这个用例是最主要的，它是系统的架构用例，让我们仔细地分析这个用例吧。
客人进到酒店里，先到前台向前台服务员提出住店的意愿，前台服务员再询问其具体的需求，然后查询房间当前状态表，看是否有满足客人需求的房间，如果没有就建议客人更改需求，实在不行只有让客人到别的酒店去了。如果有满足客人需求的房间，则给客人一张入住登记表，客人填完后交给前台服务员，办理入住手续，交纳押金，获得房卡和钥匙，然后就到房间住下。不再住时，客人到前台交回房卡和钥匙，然后结帐就可以离开了。这中间有两个扩展点，一是办完入住手续后客人可以选择寄存物品，一是在住店期间可以向酒店要求一些服务，例如订早餐、订票、要求送水、唤醒服务，还可以咨询和投诉。上面描述比较粗略，要想描述得细点则需要相当的领域知识，不过在这里还不需要描述得太细。从上面的描述中我们可以找到一些名词，如客人、酒店、前台服务员、住店意愿、住店需求、房间、房间状态表等等，对它们进行筛选，可以得到如下我们所关心的对象：客人、酒店、前台服务员、服务员、入住登记表、押金、房卡、钥匙、服务、房间、房间状态表、咨询、投诉。然后我们可以分析得到客人的基本属性，前台服务员和服务员继承自员工，入住登记表是客人与房间的关联类，房间的基本属性，投诉和咨询则要看其记录表格式等等。
客人住店还有两种情况，一种是通过预定，一种是换房。预定的流程类似，不过在前台服务员那里要记录这个预定信息，而客人不是马上住店，要几天后才住店，这里有个新对象，即预定记录表。换房可以不产生新记录，但要改变房间状态标识，并对结帐有影响。服务则需要针对具体的服务去分析。
再来看前台服务员，前面没有详细描述入住手续，是因为这里会描述。当客人填好入住登记表后，服务员会检查其身份证明，看是否相符，然后确定所需开通的服务，确定押金数目，然后由客户交纳押金，并给出凭据，然后再给客户房卡和钥匙。这里新的对象有：身份证明、押金凭据、房卡和钥匙。离店登记则由客人交出房卡和钥匙开始，先让服务员检查房间，是否有损坏和缺失的设施，然后根据客人住店期间的服务及住店天数计算费用，客人交出押金凭据，然后结帐开发票。这里的新对象有：房间设施、住店费用、发票。寄存物品则在办完入住手续后开始，客人交出物品，前台服务员收下物品，然后开出收据，交与客人，到时客人凭此收据领物品。（嗯，寄存物品的价值主体是客人，它的ACTOR应该是客人，而前台服务员则有两个用例与此相关，一个是存，一个是领。）这里的新对象是收据，另外这个用例应该与离店登记有关联。
服务员则需要和服务一起来分析。这里我们只考虑以下几种服务：寄存物品、订票、订餐、开通外线电话、唤醒服务、送水和打扫。服务要由服务员来执行，服务还可能和房间有关系，例如某些房间可能是赠送早餐的，直接开通外线电话的，这是服务与房间的绑定关系，这一关系不应由服务自己来管理，所以对象－－服务就不需要有到房间的链接。其实在设定服务时，我们可以规定此服务只能适用于某些房间，例如不可能给没电话或空调设施的房间开通电话或空调，服务就成了元类型的概念，但真要把它做元类型来处理会比较麻烦，不过这里就不管了，具体怎样解决就留给设计去做吧，我们只如实分析。对于服务，我们最关心的是它的费用，而服务费用是根据费用使用记录来计算的，所以要有服务使用记录，这是一个服务与客户的关联类。
客房部则做一些管理工作，查询统计分析呀，服务员排班呀，这些对系统的主体架构影响不大，这里就不细说了。前面那些对象，要是细细分析，也有很多东西的，但这里主要对问题域有个了解，并发现对象，获取词汇表，就不详细讨论了，可以留到后面逐渐补充完善。如果对业务非常熟悉，不做领域建模，直接建立分析模型也是可以的。

[smallfish2001]

不错

[101monster]

呵呵，UP！

[cpluser]

gz

[asen51]

study!!!^_^^_^_^_^

[hewittlee]

study!

[WorkJava]

study!

[LiuYongNing]

good,支持

[hhfxlzs]

studying!

[prosadn]

楼上强呀!!!

[emicamel]

不错啊.
强啊.
牛啊.
顶啊.
关注!!!1

[chenszhs]

一个多星期没来，现在重新开始
多谢libi(风自吟) 提供的业务流程

现做主要时序图如下：

客户 网站 前台服务员 客房
| | | |
|----订房---->} | |
| } | |
|<--确认------| | |
|-----------订房----------->} |
| | | |
|-----------开房----------->} |
| | }-----确认----->}
| | } }
| | }<---房号-------|
| | } |
|<----房号、房卡------------| |
| |
|-----------换房----------->} |
| }-----确认----->}
| | } }
| | }<---房号-------|
| | } |
|<----房号、房卡------------} |
| | }----胀房------>}
| | | |
|-------退房、房卡、金额--->} |
| | } |
| | }----胀房------>}

[Mybeautiful]

up

[along603]

哦哦哦，来个用例描述吧

[libi]

接下来做分析模型吧，还是从用例入手，但这时的系统边界就与领域模型不一样了，我们主要是考虑计算机能为酒店做哪些事，而不是从酒店的角度去考虑。很显然，入住登记和离店登记仍然是系统最核心的用例，也是架构用例，就让我们从入住登记开始吧。
从客户发出入住申请开始，前台管理员在电脑上点击一个命令，接下来显示入住登记信息窗，让前台管理员录入入住信息，然后系统计算所需的押金，显示给前台看，当客户交钱后，向系统发出一个确认信息，然后系统就记录下这个入住关系（打印押金凭据是个扩展用例，这里就不提了）。序列图如下

前台 主界面 入住信息窗 入住关系管理
| | | |
|----点击---->} | |
| }----创建---->} |
| | | |
|<----------显示------------} |
| | | |
|-----------输入----------->} |
| | }-----信息----->}
| | } }------- 计算
| | } | | 押金
| | | |<------
|<----------------显示----------------------|
| | } }
|--------------------确认------------------>}
| | } |
| | } }------- 建立
| | } | | 关系
| | | |<------
| | | |

序列图反映了一个用例的流程，同时也体现对象之间的交互。从上面可以看到，我们需要一个入住信息窗对象，它负责从操作者那里获得入住的信息，然后传给入住关系管理对象。入住关系管理需要根据信息计算押金，还要建立入住关系，这是它的两个职责，它需要提供这两个接口（随着分析的进一步深入，它有可能被赋予更多的职责）。图中还有入住关系管理到用户的显示和确认，这需要一个界面，本来入住关系管理应该是一个后台对象，这个界面由它负责不太合理，但因为后续操作要它处理，由它负责实现起来简单，就交给它吧。实际上，上面这个图还是有不少问题的，这里就不一一指出，大家自己考虑吧。
入住信息窗的职责是从操作者那里获得入住信息，这里我们就得来分析一下入住关系（其实这也可以算领域模型的范畴）。入住关系是用来记录一位客人与酒店发生一次住店行为的关系，很显然它是客人、房间、服务的三元关系（时间就不算了），同时对于酒店来说，它也是一笔业务的记录，而且在客人住店的期间，它也会变化，例如房间和服务会随换房和订服务变化。再仔细考虑一下，其实它不是三元关系，而是两个二元关系（客人－房间、客人－服务），所以它是一个复杂的动态的对象，要管好这个对象不容易。不过在这个用例中，我们只是初始化这个关系，只要有客人、房间和服务的对象ID就可以了，至于它今后如何维护以后在别的用例再考虑吧。
这样也就是说从入住信息窗对象传来的“信息”应该包括客人、房间和服务的ID，入住信息窗对象就负责从操作者那里获得这些信息。房间和服务应该是由系统初始化好了的，在界面上进行选择就可以了，客人则通常是即时添加的，是否要判重和保留以往客人记录就要看酒店的需求了。在这里关键的是要做一些业务逻辑的判断，例如已经住人的房间不能再入住，没有装电话的房间不能开通电话服务等。像这种情况，我们通常会在界面上处理掉，例如选择了房间后，服务的选框里就只有该房间可用的服务，这样一来，这个逻辑判断由服务对象来负责最合理，也就是服务管理对象应该提供一个接口，以给定的房间ID为参数调用这个接口，应该能返回适用于该房间的服务。至于服务管理对象如何实现这职责，那就是它的事了，一个简单的方法就是建立一个房间与服务的二维关系矩阵，用时一查就可以了，但这只能适应静态关系，能不能用还要看服务到底会有多复杂。

[wangyusen]

学习
本人正在准备开发人事考勤系统

[Javcs]

support and study!

[luoxiaohu19802000]

多多支持，一定学，呵呵