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

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

《宾馆客房管理系统《软件架构说明书》.docx》由会员分享，可在线阅读，更多相关《宾馆客房管理系统《软件架构说明书》.docx（15页珍藏版）》请在冰豆网上搜索。

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

软件架构说明书

系统名称:

宾馆客房管理系统

班级：

XXXXXXXXX

学号：

XXXXXXXXX

姓名：

XXXXXXXXXX

文件建立/修改记录

序号

版本

建立或修改

崖立/修改人

日期

审核人

日期

批准人

日期

1

1.0

建立

2011

年6月28日

2

1.1

修改

2011

年6月29日

3

1.2

修改

2011

年6月30日

1简介1

1.1文档编写目的1

1.2文档范围1

1.3术语和省略语1

1.4参考资料1

2架构表示方式1

3架构设计目标与约束2

3」关键功能需求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部署方案112

7.3部署方案212

8实施视图12

8.1槪述12

8.2实施模型总体架构13

9数据视图13

9.1槪述13

9.2数据域模型设计13

1简介

1.1文档编写目的

本文档全面与系统地表述LI标软件系统的构架，并通过使用多种视图来从不同角度描述系统的各个主要方面，以满足相关涉众（客户、设计人员等）对口标系统的不同关注焦点。

本文档记录并表述了架构师对系统构架方面做出的重要决策；项口经理将根据构架定义的构件结构制定项LI的开发il•划；设计员将据此进行各构件的详细设计；测试设计员按照构架设讣系统的总体测试框架：

另外构架文档还用于指导各构件的实施、集成及测试。

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

1.3术语和省略语

本系统没有较专业的术语。

1-4参考资料

《UML系统建模基础教程》胡荷芬，张帆，高斐编著/2010年05月清华大学出版社

2架构表示方式

本文档以一系列的视图（View）来表示系统的软件构架，主要包括用例视图、逻辑视图、进程视图、部署视图、实施视图（即RUP推荐的4+1视图）等；每个视图拥有一个或名个模型（Model）（例如逻辑视图包含分析模型、设讣模型和数据模型等）；并圉绕相关视图来描述系统的基本结构、组成机制与工作原理等。

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

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

3架构设计目标与约束

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

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

3.1关键功能需求

跨地域的系统外部用户通过Internet网来使用系统的功能。

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

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

具体功能呢模块如下：

3.2.1有效性

系统平均可用时间大于99.999%o

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关键用例

421关键的系统参与者

4.2.2关键的系统用例

vvinclude»

身份验证

注册会员信息

身份验证

宜询已住房间信息工、-宀辛白「厂白.宜询空置房间信息

；<

宜询维修房间信息

«extend»

宜询房态喰

登陆

«include»

<>_V____丿

直询消费明细

身份验证

言询客史资料

班次结账

设羞客房信息

财务核宜

经理

<

宜询收银明细

修改用户密码

4.3关键系统用例简述

如图1所示，接待员能够通过该系统进行如下活动。

■登陆管理系统。

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

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

■处理房间预订信息。

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

■登记房间信息。

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

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

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

■查询客户信息。

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

■登陆管理系统。

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

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

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

■处理退房信息。

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

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

■财务核查。

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

■班次结账。

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

■设置客房信息。

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

■查询客史资料。

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

■查询房态。

经理可以查询房间状态。

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

■登陆管理系统。

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

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

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

■设置系统信息。

■管理用户权限。

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

■管理用户信息。

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

5逻辑视图

5.1概述

逻辑视图从系统内在逻辑结构的角度描述系统的基本结构与动态行为，通常包括分析模型（AnalysisModel设计模型（DesignModel）以及数据模型（DataModel）等。

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

本节将分别在系统层次结构模型中描述系统的层次组织结构；在主要的包和子系统中说明系统的具体组成；并在架构机制中详述系统中的各种构架机制：

最后在关键用例实现中通过描述最重要的用例实现，来说明构架的典型协作（动态行为）。

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

5.2系统层次模型

本系统主要分为三层：

用户界面层、业务逻辑层、数据访问层。

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

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

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

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

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

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

5.3主要的设计包和子系统、

6进程视图

6.1概述

进程视图从系统运行时刻的角度，描述系统划分为进程、线程的结构，及其动态关系。

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

6.2总体进程架构

房间信息状态图:

1经理添加新房间信息

新建状态

收银员状态图:

收银员未登陆系统

接待员状态图:

J接待员未登陆系统未登陆状

态

>

接待员登陆系统

操作状态

经理状态图:

7部署视图

7.1概述

部署视图从系统软硬件物理配置的角度，描述系统的网络逻辑拓扑结构。

模

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

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

7.2部署方案1

7.3部署方案2

8实施视图

8.1概述

实施视图从软件编译与构建的角度，描述系统实施构件的组织结构与依赖关系（主要是编译依赖）。

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

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

8.2实施模型总体架构

系统维护二^人员类

II

9数据视图

9.1概述

视图是原始数据库数据的一种变换，是查看表中数据的另外一种方式。

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

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

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

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

9.2数据域模型设计

核心数据流图:

维修信息

部分数据流图数据流名称：

客人信息

来源：

客人

去向：

入住登记「

包含的数据项：

姓名、身份证号、性别、入住房间、房间类型、房间价格、入住状态等

（宾馆客房管理系统的数据流一一客人信息）

数据流名称：

入住登记

来源：

客人产生入住登记-

去向：

入住

包含的数据项：

订单编号、姓名、性别、身份证号、客户编号、客房类型、抵房时间、入住人数、预定人、电话、住儿天等信息

（宾馆客房管理系统的数据流一一入住登记）

数据流名称：

客房信息

来源：

客人产生入住登记

去向：

入住

包含的数据项：

客房编号、客房类型、客房价格、客房状态

（宾馆客房管理系统的数据流一一客房信息）数据流名称：

房间状态

来源：

退房「

去向：

房间

包含的数据项：

客房号码、房间状态

（宾馆客房管理系统的数据流一一房间状态）

数据流名称：

帐务信息

来源：

退房

去向：

财务

包含的数据项：

帐单编号、姓名、消费金额、入住时间、退房时间、押金

（宾馆客房管理系统的数据流一一帐务信息）