宾馆客房管理系统《软件架构说明书》

软件架构说明书系统名称：___宾馆客房管理系统________________ 班级：___XXXXXXXXX____________学号：___XXXXXXXXX___________姓名：___XXXXXXXXXX __________完成时间：_____2011年7月1号______________文件建立/修改记录目录1 简介 (1)1.1 文档编写目的 (1)1.2 文档范围 (1)1.3 术语和省略语 (1)1.4 参考资料 (1)2 架构表示方式 (1)3 架构设计目标与约束 (2)3.1 关键功能需求 (2)3.2 关键质量需求 (2)3.2.1 有效性 (2)3.2.2 性能 (3)3.2.3 性能可扩展 (3)3.2.4 功能可扩展 (3)3.3 系统设计原则 (3)3.4 开发策略 (3)3.4.1 软件复用策略 (3)3.4.2 使用开源架构 (3)3.4.3 使用商业构件 (4)3.5 其它设计约束 (4)4 用例视图 (4)4.1 概述 (4)4.2 关键用例 (4)4.2.1 关键的系统参与者 (4)4.2.2 关键的系统用例 (5)4.3 关键系统用例简述 (7)5 逻辑视图 (8)5.1 概述 (8)5.2 系统层次模型 (8)5.3 主要的设计包和子系统、 (9)6 进程视图 (9)6.1 概述 (9)6.2 总体进程架构 (9)7 部署视图 (11)7.1 概述 (11)7.2 部署方案1 (12)7.3 部署方案2 (12)8 实施视图 (12)8.1 概述 (12)8.2 实施模型总体架构 (13)9 数据视图 (13)9.1 概述 (13)9.2 数据域模型设计 (13)1简介1.1 文档编写目的本文档全面与系统地表述目标软件系统的构架，并通过使用多种视图来从不同角度描述系统的各个主要方面，以满足相关涉众（客户、设计人员等）对目标系统的不同关注焦点。

本文档记录并表述了架构师对系统构架方面做出的重要决策；项目经理将根据构架定义的构件结构制定项目的开发计划；设计员将据此进行各构件的详细设计；测试设计员按照构架设计系统的总体测试框架；另外构架文档还用于指导各构件的实施、集成及测试。

1.2 文档范围本文档适合宾馆客房管理系统项目的总体应用架构。

1.3 术语和省略语本系统没有较专业的术语。

1.4 参考资料《UML系统建模基础教程》胡荷芬，张帆，高斐编著/2010年05月清华大学出版社2架构表示方式本文档以一系列的视图（View）来表示系统的软件构架，主要包括用例视图、逻辑视图、进程视图、部署视图、实施视图（即RUP推荐的4+1视图）等；每个视图拥有一个或多个模型（Model）（例如逻辑视图包含分析模型、设计模型和数据模型等）；并围绕相关视图来描述系统的基本结构、组成机制与工作原理等。

本文档还将系统的构架机制描述也放在了逻辑视图之下。

本文档主要使用统一建模语言（UML）来充当相关模型的表达语言；主要图表（Diagram）引用自目标系统的Rose Model。

3架构设计目标与约束描述构架设计必须满足的关键系统功能需求和质量约束，这些功能需求和质量要求对软件构架有重大的影响，并决定了构架的设计。

本节同时还列明影响构架的其他相关因素，如软件的复用策略、使用商业构件、设计与实施的策略等。

3.1 关键功能需求跨地域的系统外部用户通过Internet网来使用系统的功能。

内部用户、系统管理员在安全性较高的内网中使用系统的功能。

消息通知系统是目标系统为了实现相关功能而需要进行协作的一个外部系统，它能够向用户发送email，或者发送短消息。

具体功能呢模块如下：3.2 关键质量需求3.2.1有效性系统平均可用时间大于99.999%。

3.2.2性能系统并发用户在线数大于30。

普通数据录入、查找等操作，每单步操作最大延迟时间应小于2秒。

一般查询统计，结果集在100条记录以内情况下，最大延迟时间不超过20秒。

所有统计，其最大延迟时间不超过2分钟。

3.2.3性能可扩展支持硬件系统性能升级与数量扩充。

3.2.4功能可扩展系统应支持新的功能模块的增加以及旧功能模块的修改或删除操作。

3.3 系统设计原则本系统设计遵循以下几个原则：1.可适用性。

本系统在开发的功能需求和非功能需求上能满足当下宾馆客房管理行业的要求。

2.结构稳定性。

本系统在体系结构上较稳定。

3.可扩展性。

本系统适应时代的发展要求，具有较强的可扩张性。

3.4 开发策略3.4.1软件复用策略系统中重要基础构件应当具备较高的设计与构建质量，可以在产品中复用。

3.4.2使用开源架构系统基础框架主要采用业界的一些主流开源框架，包括：struts、spring、hibernate、log4j等。

单元测试使用junit框架。

3.4.3使用商业构件不适用。

3.5 其它设计约束目标构架总体上应采用分层结构，并全面应用面向对象设计、编程技术使系统具有较好的扩展性与重用性。

本系统支持与其他系统进行集成，所以要提取出良好的集成接口。

4用例视图4.1 概述用例视图从用户使用的角度描述系统构架的基本外部行为特性，通常包含业务用例模型与系统用例模型。

业务用例模型不适用于本系统，这里只关注系统用例。

这里选取了用例模型中对系统构架的内容产生重大影响的应用场景与用例集合，这些用例代表了系统主要的核心功能，往往决定了系统构架的基本组成元素。

有些用例强调或决定了构架的某些具体然而重要的细节，通常也可以列在本节内，总之所列的用例集合应基本覆盖系统构架的主要方面。

4.2 关键用例4.2.1关键的系统参与者系统维护人员4.2.2 关键的系统用例身份验证登陆查询客户信息1身份验证2设置客房信息3设置系统信息修改用户密码44.3 关键系统用例简述如图1所示，接待员能够通过该系统进行如下活动。

⏹登陆管理系统。

接待员可以根据自己的用户名和密码登陆管理系统，如果身份验证失败，不得进行下一步操作。

通过身份验证才能进入下一个操作界面。

⏹处理房间预订信息。

接待员可以处理客户提前预订的信息。

⏹登记房间信息。

接待员可以登记客户的开房信息，包括所开房间信息和客户基本信息。

⏹处理客户更改房间信息。

接待员可以根据客户的要求更改换房信息以及客户续住房间信息。

⏹查询客户信息。

接待员可以查询当日在点客户的开房信息和基本信息。

⏹登陆管理系统。

收银员可以根据自己的用户名和密码登陆管理系统，如果身份验证失败，不得进行下一步操作。

通过身份验证才能进入下一个操作界面。

如图2所示，收银员能够通过该系统进行如下活动。

⏹处理退房信息。

收银员可以处理客户的退房信息，包括注销客户退房的信息，退房的房间费用结算以及消费的其他商品的结账。

如图3所示，经理能够通过该系统进行如下活动。

⏹财务核查。

经理可以查询当日的消费明细和收银明细。

⏹班次结账。

经理可以核对当日收银员的收银金额与消费名额是否一致，如果核对无误，清空当日收银员操作的相关信息，进入下一班次。

⏹设置客房信息。

经理可以设置客房的相关信息。

⏹查询客史资料。

经理可以查询光顾本店的客户资料。

⏹查询房态。

经理可以查询房间状态。

包括客户已住房间信息，空置房间信息和维修房间信息。

⏹登陆管理系统。

收银员可以根据自己的用户名和密码登陆管理系统，如果身份验证失败，不得进行下一步操作。

通过身份验证才能进入下一个操作界面。

如图4所示，系统维护人员能够通过该系统进行如下活动。

⏹设置系统信息。

⏹管理用户权限。

维护人员可以管理当前系统其他用户的使用权限。

⏹管理用户信息。

维护人员可以管理当前用户的使用信息，包括修改用户名和密码。

5逻辑视图5.1 概述逻辑视图从系统内在逻辑结构的角度描述系统的基本结构与动态行为，通常包括分析模型（Analysis Model）、设计模型（Design Model）以及数据模型（Data Model）等。

设计模型说明了系统的组成元素、组织架构和关系，并描述了各组成元素的协作以及状态转换关系等（通过用例实现Use Case Realization予以表达）。

本节将分别在系统层次结构模型中描述系统的层次组织结构；在主要的包和子系统中说明系统的具体组成；并在架构机制中详述系统中的各种构架机制；最后在关键用例实现中通过描述最重要的用例实现，来说明构架的典型协作（动态行为）。

分析模型对等于设计模型，是在更高的抽象层次上定义系统的结构，作为可选项，本文档将不予说明。

5.2 系统层次模型本系统主要分为三层：用户界面层、业务逻辑层、数据访问层。

用户界面层代表与用户进行交换的界面，既可以是form窗口，也可以是web的界面形式。

随着应用的复杂性和规模性，界面的处理也变得具有挑战性。

一个应用可能有很多不同的界面表现形式，通过对界面中数据的采集和处理和响应用户的请求与业务逻辑层进行交换。

业务逻辑层用来处理系统的业务流程，他可以接受用户界面请求的数据，并根据系统的业务规则返回处理结果。

他将系统的业务规则抽象出来，按照一定的规则形成在一个应用层上。

数据访问层是程序中和数据库进行交互的层。

5.3 主要的设计包和子系统、6进程视图6.1 概述进程视图从系统运行时刻的角度，描述系统划分为进程、线程的结构，及其动态关系。

模型主要说明进程、线程的分类，系统构架敏感的主要边界类、控制类对象等在进程、线程中的分布，以及它们之间的创建、交互与消息通讯关系等。

6.2 总体进程架构房间信息状态图：收银员状态图：接待员状态图：经理状态图：7部署视图7.1 概述部署视图从系统软硬件物理配置的角度，描述系统的网络逻辑拓扑结构。

模型包括各个物理节点的硬件与软件配置，网络的逻辑拓扑结构，节点间的交互与通讯关系等。

同时还表达了进程视图中的各个进程具体分配到物理节点的映射关系。

7.2 部署方案1客户机终端主系统SQL7.3 部署方案28实施视图8.1 概述实施视图从软件编译与构建的角度，描述系统实施构件的组织结构与依赖关系（主要是编译依赖）。

模型包括实施子系统和构件结构，及其依赖关系。

同时还表达了逻辑视图中各个包和类分配到实施视图中的子系统和构件的映射关系。

8.2 实施模型总体架构主系统9数据视图9.1 概述视图是原始数据库数据的一种变换，是查看表中数据的另外一种方式。

可以将视图看成是一个移动的窗口，通过它可以看到感兴趣的数据。

视图是从一个或多个实际表中获得的，这些表的数据存放在数据库中。

那些用于产生视图的表叫做该视图的基表。

一个视图也可以从另一个视图中产生。

9.2 数据域模型设计核心数据流图：部分数据流图（宾馆客房管理系统的数据流——客人信息）（宾馆客房管理系统的数据流——入住登记）（宾馆客房管理系统的数据流——房间状态）（宾馆客房管理系统的数据流——帐务信息）。