三、系统分析
（一）识别参与者
对于平台功能需求的分析，我们定位了四种参与者：普通用户、注册用户、企业级用户、网站维护人员。现对参与者描述如下：
（1）普通用户
描述：可以注册成为注册用户、对信息进行浏览、对行程进行搜索。
示例：有预定行程意向的用户。
（2）注册用户
描述：可以对各种网站信息进行浏览、对行程进行搜索、通过在线预定方式生成订单、使用留言功能、对出行证件信息进行填写或者修改。
示例：要预定行程的用户。
（3）企业级用户
描述：企业级用户除了可以使用普通用户以及注册用户的所有功能外，还可发布行程信息、对订单进行确认、对已付款用户的出行证件信息进行确认。
（4）网站维护人员
描述：对注册用户的管理、对企业级用户申请的审核、所有用户发布行程信息的管理、企业级用户店铺的管理和维护。
示例：平台的工作人员。
（二）识别用例
前面已经识别出了参与者，通过对需求的进一步分析，可以确定网站中存在以下用例：
（1）注册用例：本用例提供了注册用户的功能
（2）登录用例：本用例提供了验证用户及管理员身份的功能。
（3）信息浏览用例：本用例提供了用户浏览企业级用户发布的行程信息功能、查看天气信息功能、查看网站公告信息功能。
（4）行程搜索用例：本用例提供了用户查询行程信息的功能。
（5）订单创建用例：本用例提供了为注册用户创建订单功能。
（6）评价用例：本用例提供了为注册用户、企业级用户相互评价的功能。
（7）店铺申请用例：本用例提供了为企业级用开启自己店铺的功能。
（8）行程信息用例：本用例提供了为企业级用户发布行程信息的功能。
（三）系统用例图及用例描述
经过以上网站参与者与用例的识别，得到普通用户、注册用户用例图，如图3.1、图3.2所示。
图3.1普通用户用例图
图3.2注册用户用例图
其用例描述如表3.1所示。
表3.1 普通用户和注册用户用例描述
|----------|-----------|------------------------------------------------------------|
| 用例名 | 参与者 | 描述 |
| 信息浏览 | 普通用户 注册用户 | 本用例提供给用户用于信息的浏览，是对行程信息浏览、公告信息浏览、天气信息浏览的泛化。 |
| 行程搜索 | 普通用户 注册用户 | 本用例提供给用户用于行程搜索，包括根据行程的级别信息搜索和根据景点信息搜索。 |
| 注册 | 普通用户 | 本用例用于用户进行注册。 |
| 登录 | 注册用户 | 本用例用于验证用户身份。 |
| 留言 | 注册用户 | 本用例提供给用户用于用户对管理员的留言，扩展出添加留言和查看回复以及删除留言，是登录用例的扩展。 |
| 出行证件信息管理 | 注册用户 | 本用例提供给注册用户用于填写出行活动时的证件信息，扩展出提交证件信息操作以及重置证件信息操作，是用户登录信息的扩展。 |
| 提交订单 | 注册用户 | 本用例提供给注册用户用于创建订单，扩展出订单进行付款和确认付款以及用户评价，是登录用例的扩展。 |
企业级用户用例图，如图3.3所示。
图3.3企业级用户用例图
其用例描述如表3.2所示。
表3.2 企业级用户用例描述
|-------|-------------------------------------------------|
| 用例名 | 描述 |
| 店铺管理 | 本用例提供给企业级用户用于店铺的管理，扩展出店铺维护、申请店铺功能。是登录用例的扩展。 |
| 行程管理 | 本用例提供给企业级用户用于行程的管理，扩展出行程发布、行程信息修改、行程下架。是登录用例的扩展 |
| 订单管理 | 本用例提供给企业级用户用于订单的管理，扩展出对用户资料确认以及取消订单的。是登录用例的扩展 |
| 留言/回复 | 本用例提供给企业级用户用于对留言的操作，是用户登录用例的扩展。 |
| 登录 | 本用例提供给企业级用户用于身份验证。 |
网站维护人员用例，如图3.4所示。
图3.4 网站维护人员用例图
其用例描述如表3.3所示。
表3.3 网站维护人员用例描述
|--------|-----------------------------------------------------|
| 用例名 | 描述 |
| 用户管理 | 本用例提供给网站维护人员用于对用户的管理，扩展出对用户停权功能、回复用户功能。是登录用例的扩展。 |
| 行程管理 | 本用例提供给网站维护人员用于对所有行程的管理。扩展出行程上架、行程下架。是登录用例的扩展。 |
| 用户店铺管理 | 本用例提供给网站维护人员用于对企业级用户店铺的管理。扩展出封停店铺、解除店铺封停。是对登录用例的扩展。 |
| 登录 | 本用例提供给网站维护人员用于对身份的验证。 |
四、系统设计
（一）系统设计的体系结构
本网站的建设采用B/S架构，在B/S体系结构系统中，用户通过浏览器向分布在网络上的许多服务器发出请求，服务器对浏览器的请求进行处理，将用户所需信息返回到浏览器[5]。B/S结构简化了客户机的工作，客户机上只需配置少量的客户端软件。服务器将担负更多的工作，对数据库的访问和应用程序的执行将在服务器上完成。浏览器发出请求，而其余如数据请求、加工、结果返回以及动态网页生成等工作全部由Web Server完成。体系结构如图4.1所示。
图4.1 系统结构图
（二）系统功能结构设计
在对YooBar旅游信息平台全面分析调查的基础上，制定出YooBar旅游信息平台的总体规划。
1.系统功能结构的总体设计
在对销售平台的业务进行分析后，将用户定位为四类，每类用户所使用的功能均不相同，规定了以下功能来适应各用户的需求。
2.系统前台功能详细设计
网站的前台功能为普通用户、注册用户、以及企业级用户提供服务，其功能结构图如图4.2所示。
图4.2网站前台功能结构图
普通用户使用的功能包括行程搜索（包括按照景点搜索、按照行程级别搜索）、信息浏览（包括查看天气预报、查看公告信息、查看行程信息等）。
注册用户可使用的功能除了基于普通用户使用的功能外，还包括行程预定、出行证件管理（填写证件信息、重置证件信息）、评价管理（查看用户信誉/评价、给企业级用户评价）、留言回复（包括发表留言、回复留言、删除留言）、订单管理（包括订单付款、确认参与行程、申请退款）。
企业级用户可使用的功能除了基于普通用户与注册用户能使用的功能外，还包括企业级用户申请、重置申请信息、店铺管理（包括店铺创建、店铺信息修改）、行程管理（包括行程发布、行程信息修改、行程下架、行程上架）、订单管理（包括订单取消、用户资料确认、订单退款）。
3.系统后台功能详细设计
网站后台为网站维护人员提供服务，其功能结构图如图4.3所示。
图4.3网站后台功能结构图
网站维护人员使用的功能包括用户登录、用户管理功能（针对所有类型用户的管理，包括用户停权、用户权利恢复）、行程管理（管理平台所有行程信息，可对行程进行终止预定操作、恢复预定行程操作）、店铺管理（包括店铺的封停功能、店铺的解封功能）。
（三）系统数据库设计
网站最注重的是与浏览者的互操作性及对信息资源的操作性，因此数据库是必不可少的。数据库是数据管理的最新技术，是计算机科学的重要分支[6]。数据库是服务于各个栏目的，建立的数据库应该力求结构严谨、关系清晰，不要产生冗余。目前，常用的数据库管理系统有Access、SQL Server、MySql、Oracle等。SQL Server是Microsoft公司开发的大型关系数据库管理系统，具有强大的关系数据库创建、开发、设计和管理功能。由于其功能强大、操作方便，适用于不同层次的用户掌握使用[7]。因此本网站采用SQL Server数据库。
1.概念结构设计
根据功能结构划分的结果，具体分析了本网站具有的实体，实体属性图如图4.4至图4.11所示所示。
图4.4普通用户实体图
图4.5企业级用户实体图
图4.6店铺实体图
图4.7店铺实体图
图4.8网站维护人员实体图
图4.9订单实体图
图4.10留言回复实体图
图4.11行程信息实体图
本网站所涉及的主要实体有用户、行程、订单等，根据等。对这些实体及属性的分析得出网站数据库的概念模型，整体E-R图如图4.12所示。
图4.12 网站E-R图
说明：图中用矩形表示实体，实体之间的关系用菱形表示，用无向边把菱形与有关实体连接，并标明联系的类型。
2.逻辑结构设计
逻辑结构设计是概念结构设计的下一阶段，设计根据概念阶段的E-R图转化成网站支持的数据模型，本网站采用关系模型。关系模型的逻辑结构是一组关系模式（二维表）的集合。E-R图是由实体，实体属性和实体之间的联系三个要素组成的。所以将E-R图转换为关系模型实际上是要将实体，实体的属性和实体之间的联系转换为关系模型。
根据网站中的E-R图转换为关系模型如下：
注册用户（++++用户编号++++，账户名称，真实姓名，用户密码，注册时间，用户电子邮件，身份证号，身份证图片，手机，电话）
企业级用户（++++用户编号++++ ，++++店铺编号++++，用户账号，网店状态，实名认证状态，公司传真，持牌人手机，持牌人电话，用户密码，持牌人姓名，营业执照编号，身份证编号，营业执照图片，公司名称，身份证图片，用户电子邮件，注册时间，公司地址）
店铺（++++店铺编号++++ ，++++用户编号++++，店铺开启时间，店铺公告，店铺名称，店铺标志图片，店铺状态）
评价（++++评价编号++++ ，++++用户编号++++，评价时间，评价内容，评价级别，评价类型）
订单（++++订单编号++++ ，++++行程编号++++ ，++++企业级用户编号++++ ，++++普通用户编号++++，订单状态，生成时间，修改时间，预定人数，订单总价，普通用户评价状态，企业级用户评价状态，普通用户身份证号，普通用户证件图片，普通用户手机，普通用户电话，普通用户真实姓名，订单备注，）
网站维护人员（++++用户编号++++，账户名称，密码，权限）
留言/回复（++++留言编号++++ ，++++回复用户编号++++ ，++++留言用户编号++++，留言内容，是否回复，留言时间，回复内容，回复时间）
行程信息（++++行程编号++++ ，++++企业级用户编号++++，行程名称，景区类型，行程级别，目的地，出发地，是否包含食宿，是否包含往返路费，图片，出行时间，行程描述，人数上限，修改时间，当前参与人数，出行期限，发布时间，单价，预定行程结束时间，是否闲置）
3.数据库表设计
本网站主要的数据表如表4.1至表4.8所示。
表4.1 YB_UserLoginMessage基本表：记录注册用户信息
|----|--------|----------------|---------|-----|------------|
| 序号 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 用户编号 | Users_ID | Int | 10 | 自动编码，是唯一标识 |
| 2 | 真实姓名 | ULM_Name | varchar | 50 | 用户姓名 |
| 3 | 用户密码 | ULM_Password | Varchar | 100 | 用户密码 |
| 4 | 用户电子邮件 | ULM_Email | Varchar | 150 | 用户电子邮件 |
| 5 | 身份证图片 | ULM_IDCardImg | Varchar | 100 | 身份证图片存放路径 |
| 6 | 注册时间 | ULM_RegistTime | Varchar | 8 | 用户注册时间 |
| 7 | 用户身份证号 | ULM_IDCard | Varchar | 20 | 用户身份证号 |
| 8 | 手机 | ULM_MPhone | Varchar | 11 | 用户手机号 |
| 9 | 电话 | ULM_Phone | Varchar | 11 | 用户联系电话 |
| 10 | 账户名称 | ULM_LoginName | Varchar | 25 | 用户登录账号 |
YB_UserLoginMessage表是用来存放用户编号、真实姓名、用户密码、用户电子邮件、身份证图片、注册时间、用户身份证号、手机、电话。Users_ID字段是该表的主键，用来存放用户编号，ULM_Password字段用来存放用户登录密码，ULM_Name字段用来存放用户的真实姓名，ULM_IDCardImg字段用来存放用户上传的身份证图片路径，ULM_RegistTime用来存放用户注册时间。
表4.2 YB_ShopMessage基本表：记录网站的店铺的信息
|----|----|---|--------------|----------|-----|--------------|
| 序列 | 名称 | 编码 || 类型 | 宽度 | 备注 |
| 1 | 店铺编号 || Shop_ID | Int | 10 | 自动编码，店铺的唯一标识 |
| 2 | 店铺图片 || Shop_LogoImg | Varchar | 100 | 店铺标志图片存放路径 |
| 3 | 店铺公告 || Shop_Message | Text | 16 | 店铺公告 |
| 4 | 店铺名称 || Shop_Name | Varchar | 200 | 店铺名称 |
| 5 | 用户编号 || Shop_MID | Int | 10 | 店铺所有者的编号 |
| 6 | 开启时间 || Shop_STime | Datetime | 20 | 店铺开启时间 |
| 7 | 店铺状态 || Shop_Type | Varchar | 100 | 店铺的状态 |
YB_ShopMessage表是用来存放店铺编号、店铺图片存放路径、店铺公告、店铺名称、店铺所有者的用户编号、店铺的开启时间。Shop_MID字段用来存放店铺所有的编号，采用企业级用户信息表的外键，将店铺表与企业级用户表进行关联。
表4.3 YB_CompanyUsersMessage基本表：记录企业级用户信息
|----|---------|--------------------|----------|-----|----------------|
| 序号 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 用户编号 | CUM_UsersID | Int | 10 | 自动编码，是唯一标识 |
| 2 | 用户密码 | CUM_Password | Varchar | 100 | 用户密码 |
| 3 | 用户电子邮件 | CUM_Email | Varchar | 150 | 用户电子邮件 |
| 4 | 用户账号 | CUM_LoginName | Varchar | 25 | 用户登录账号 |
| 5 | 网店状态 | CUM_SType | Varchar | 20 | 用户网络店铺的状态 |
| 6 | 实名认证状态 | CUM_CheckRN | Varchar | 20 | 用户申请实名认证的状态 |
| 7 | 公司传真 | CUM_Fax | Varchar | 20 | 公司的传真号 |
| 8 | 公司地址 | CUM_Add | Varchar | 200 | 公司地址 |
| 9 | 持牌人手机 | CUM_MP | Varchar | 11 | 公司经理手机号 |
| 10 | 持牌人电话 | CUM_P | Varchar | 11 | 公司经理电话号码 |
| 11 | 店铺编号 | CUM_ShopID | Int | 10 | 店铺表的编号 |
| 12 | 持牌人姓名 | CUM_MName | Varchar | 10 | 公司经理名称 |
| 13 | 营业执照编号 | CUM_CompanyNo | Varchar | 30 | 公司营业执照编号 |
| 14 | 身份证图片 | CUM_MIDCardImg | Varchar | 200 | 公司经理身份证图片的存放路径 |
| 15 | 营业执照图片 | CUM_CompanyCardImg | Varchar | 200 | 公司营业执照图片的存放路径 |
| 16 | 公司名称 | CUM_CompanyName | Varchar | 200 | 公司名称 |
| 17 | 持牌人身份证号 | CUM_MIDCard | Varchar | 20 | 公司经理的身份证号 |
| 18 | 注册时间 | CUM_RegistTime | Datetime | 8 | 用户注册时间 |
YB_CompanyUsersMessage表是用来存放企业级用户的用户编号、用户密码、用户电子邮件、用户账号、网店状态、实名认证状态、公司传真、公司地址等信息。CUM_ShopID字段用来存放该网络店铺对应的企业级用户的编号，采用店铺表的外键，将店铺表与企业级用户表进行关联。
表4.4 YB_AppMessage基本表：记录所有的评价信息
|----|------|-------------|----------|-----|--------------|
| 序列 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 评价编号 | App_ID | Int | 10 | 自动编码，评价的唯一标识 |
| 2 | 评价内容 | App_Context | Varchar | 255 | 用户评价的内容 |
| 3 | 评价级别 | App_Level | Varchar | 255 | 用户评价的级别 |
| 4 | 评价类型 | App_Type | Varchar | 200 | 评价的类型（买入、卖出） |
| 5 | 用户编号 | Shop_MID | Int | 10 | 评价对应的用户编号 |
| 6 | 评价时间 | App_STime | Datetime | 8 | 评价时间 |
YB_AppMessage表是用来存放评价信息的评价编号、评价内容、评价级别、评价类型、用户编号、评价时间。Shop_MID字段用来存放该评价对应的用户编号，采用企业级用户信息表或者普通用户信息表的外键，将评价信息表与两种用户表进行关联。
表4.5 YB_AdminUsers基本表：记录网站维护人员的信息
|----|------|-------------|---------|-----|------------------|
| 序列 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 用户编号 | AU_ID | Int | 10 | 自动编码，网站维护人员的唯一标识 |
| 2 | 账户名称 | AU_Name | Varchar | 255 | 网站维护人员登录账户 |
| 3 | 密码 | AU_Password | Varchar | 255 | 登录密码 |
| 4 | 权限 | AU_ Purview | Varchar | 200 | 网站维护人员的权限 |
YB_AdminUsers表是用来存放网站维护人员的用户编号、账户名称、密码、权限字段。其中权限（AU_ Purview编码）代表着管理员都可以对网站后台的那些功能进行操作。
表4.6 YB_TourOrders基本表：记录用户的订单信息
|----|-----------|----------------------|----------|-----|----------------|
| 序号 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 订单编号 | tourOrdersID | Int | 10 | 自动编码，订单的唯一标识 |
| 2 | 订单状态 | tourOrdersType | Varchar | 100 | 订单当前的状态 |
| 3 | 修改时间 | tourModiTime | Datetime | 8 | 订单修改时间 |
| 4 | 生成时间 | Order_CreatTime | Datetime | 8 | 订单生成时间 |
| 5 | 预定人数 | tourPersionNo | Int | 4 | 订单的预定的人数 |
| 6 | 订单总价 | tourTotalValue | Float | 8 | 订单总计金额 |
| 7 | 普通用户评价状态 | consumerAppraiseType | Tinyint | 1 | 普通用户是否已进行了评价 |
| 8 | 企业级用户评价状态 | shoperAppraiseType | Tinyint | 1 | 企业级用户是否已进行了评价 |
| 9 | 普通用户编号 | TO_ConsumerID | Int | 10 | 采用普通用户表的外键 |
| 10 | 行程编号 | TO_TourRoute | Int | 10 | 采用旅游行程表的外键 |
| 11 | 普通用户手机 | TO_ConsumerMP | Varchar | 20 | 普通用户的手机号 |
| 12 | 普通用户电话 | TO_ConsumerP | Varchar | 20 | 普通用户的电话号 |
| 13 | 普通用户证件图片 | TO_ConsumerIDCardImg | Varchar | 100 | 普通用户的身份证图片存放路径 |
| 14 | 普通用户姓名 | TO_ConsumerName | Varchar | 10 | 普通用户的真实姓名 |
| 15 | 订单备注 | TO_Message | Text | 16 | 订单的备注信息 |
| 16 | 企业级用户编号 | TO_SID | Int | 10 | 采用企业级用户表的外键 |
| 17 | 普通用户身份证号 | TO_ConsumerIDCard | Varchar | 20 | 普通用户的身份证号 |
YB_TourOrders基本表主要用来存放普通用户与企业级用户之间进行交易的订单信息。tourOrdersID作为该表的主键，代表订单在数据库中编号。tourOrdersType字段用来存放订单当前的状态（包括"未付款"、"已付款"、"未确认付款"、"申请退款"、"已经退款"、"确认退款"）。consumerAppraiseType字段用来存放该订单的游客评价状态。shoperAppraiseType字段用来存放该订单的商家评价状态。该表与普通用户表进行了关联，关联字段（TO_ConsumerID）采用用户表的外键，用户编号字段，属于多对一单向关联。该表除了与普通用户表进行了关联外，与企业级用户信息表进行了一对一关联，与旅游行程表进行了多对一关联。
表4.7 YB_LeaveWords基本表：记录所有的留言信息
|----|--------|--------------|----------|-----|--------------|
| 序列 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 留言编号 | LW_ID | Int | 10 | 自动编码，评价的唯一标识 |
| 2 | 留言内容 | LW_Context | Text | 16 | 普通用户留言的内容 |
| 3 | 是否回复 | LW_WBType | Varchar | 100 | 留言是否被回复了 |
| 4 | 留言时间 | LW_Time | Datetime | 8 | 普通用户留言时间 |
| 5 | 回复用户编号 | LW_WBUID | Int | 10 | 回复对应的企业级用户编号 |
| 6 | 回复时间 | LW_WBTime | Datetime | 8 | 回复时间 |
| 7 | 留言用户编号 | LW_UID | Int | 10 | 留言对应的普通用户编号 |
| 8 | 回复内容 | LW_WBContext | Text | 16 | 企业级用户回复的内容 |
YB_LeaveWords表是用来存放用户留言信息的留言编号、留言内容、是否回复、留言时间、回复用户编号、回复时间、留言用户编号、回复内容。LW_UID字段用来存放该留言对应的用户编号，采用企业级用户信息表或者普通用户信息表的外键，将留言信息表与两种用户表进行关联，LW_WBUID字段用来存放该回复对应的用户编号，将该表的回复信息与两种用户表进行关联。
表4.8 YB_TourRoute基本表：记录行程信息
|----|--------|------------------------|----------|-----|------------------|
| 序列 | 名称 | 编码 | 类型 | 宽度 | 备注 |
| 1 | 行程编号 | TR_ID | Int | 10 | 自动编码，行程信息的唯一标识 |
| 2 | 行程名称 | TR_Name | Varchar | 100 | 行程名称 |
| 3 | 景区类型 | TR_TourAreaType | varchar | 100 | 行程所在景区类型 |
| 4 | 行程级别 | TR_TourLevel | Varchar | 100 | 行程级别类型 |
| 5 | 包含食宿 | TR_InvolveRoomAndBoard | Tinyint | 1 | 是否包含食宿 |
| 6 | 交通费用 | TR_InvolveTrafficFee | Tinyint | 1 | 是否包含往返的交通费用 |
| 7 | 出发地 | TR_JumpingOffPlace | Varchar | 200 | 行程的出发地 |
| 8 | 目的地 | TR_Destination | Varchar | 200 | 行程的目的地 |
| 9 | 出行时间 | TR_TourStartTime | Datetime | 8 | 行程出行时间 |
| 10 | 行程描述 | TR_TourDescription | Text | 16 | 行程描述 |
| 11 | 人数上限 | TR_TourMaxPopulation | Int | 10 | 行程人数上限 |
| 12 | 当前参与人数 | TR_TourCP | Int | 10 | 当前预定该行程人数 |
| 13 | 出行期限 | TR_TourTimeLimit | Int | 10 | 出行期限 |
| 14 | 发布时间 | TR_TourRegistTime | Datetime | 8 | 行程发布时间 |
| 15 | 单价 | TR_TourPrice | Float | 10 | 行程单价 |
| 16 | 图片 | TR_TourImagePath | Varchar | 255 | 行程对应图片的存放路径 |
| 17 | 预定结束时间 | TR_TREndTime | Datetime | 8 | 接收预定结束时间 |
| 18 | 修改时间 | TR_TRModificationTime | Dateime | 8 | 行程修改时间 |
| 19 | 企业用户编号 | TR_OwnerID | Int | 10 | 与企业级用户信息表的外键进行关联 |
| 20 | 是否闲置 | TR_isNS | Tinyint | 1 | 该行程信息是否被闲置 |
YB_TourRoute基本表主要用来存放企业级用户发布的旅游行程信息。TR_ID作为该表的主键，代表行程的编号TR_TourAreaType字段用来存放行程对应的景区属性（包括"国外"、"国内"），TR_TourLevel字段用来存放行程所对应的旅游级别分类（包括"经济游"、"普通游"、"豪华游"）。TR_TourTimeLimit字段用来存放行程的出行期限，例如："5"代表出行5天。TR_TREndTime字段用来存放行程接收网上预订的最晚时间，TR_OwnerID字段代表了该行程的发布者编号，采用企业级用户信息表的外键进行了关联，达到多对一关联的目的。
（四）系统功能活动图及活动描述
1.行程搜索功能活动图
用户选择搜索类型并输入要搜索的内容，提交搜索信息，服务器端检查搜索类型。如果用户选择的搜索类型为景区分类中的一种，则转入按照行程景区搜索处理单元，该处理单元将用户输入信息转换（分叉）为两个线程来处理，一、根据用户输入的搜索内容进行对数据的搜索，二、按照旅游行程的级别分类进行分组统计，然后将结果转化（连接）为页面信息返回给客户端。如果用户选择的搜索类型为级别分类中的一种，则转入按照旅游行程级别搜索处理单元，处理单元将用户输入信息转化（分叉）两个线程来处理，一、根据用户输入的搜索内容进行对数据的搜索，二、按照旅游行程的景区进行分组统计，然后将结果转化（连接）为页面信息返回给客户端。如果用户没有选择搜索类型，则转入模糊搜索处理单元，该处理单元将信息转化（分叉）为三个线程来处理，一、根据用户输入的搜索内容进行对数据的搜索，二、按照行程的景区分类进行分组统计，三、按照行程的级别分类进行分组统计，最后合并将结果返回客户端。功能活动图见图片4.13。
图4.13行程搜索功能活动图
2.用户行程预定功能活动图
用户挑选中意的行程信息，点击该行程信息的链接，填写预定人数提交信息，服务器端对用户提交的信息进行检验，如果数据不合法返回用户填写预定人数信息页面，如果合法，则转入检查用户是否登录，如果没有登录，调用登录处理单元，待用户登录成功后，返回填写预定人数信息页面，如果用户已经登录，将订单写入数据库，返回提示用户付款信息，活动结束。如图4.14所示。
图4.14用户行程预定功能活动图
3.企业级用户店铺创建功能活动图
用户点击"我的信息"，服务器端开始检查用户是否已经登录，如果没有登录则调用用户登录处理单元，如果已经登录，返回用户信息列表。用户点击"我要开店"链接，服务器端开始检查该用户是否已经通过企业级用户认证，如果没有用过，调用企业级用户认证处理单元，如果已经通过检查该用户发布行程信息的数量，则服务器端返回用户填写店铺信息页面，用户填写店铺信息页面提交后，服务器端对用户填写的信息进行检查，如果合法则写入数据库，否则返回提示创建失败信息，活动结束。如图4.15所示。
图4.15企业级用户创建店铺功能活动图
4.企业级用户行程发布功能活动图
用户点击"我要发布行程"链接，服务器端开始检查用户是否通过企业级用户认证，如果没有通过，调用企业级用户认证申请处理单元，待完成企业级用户申请后返回填写行程信息页面，否则，直接返回填写行程信息页面。用户填写要发布的行程信息提交，然后由服务器端开始检查用户填写信息合法性，不合法，返回重新填写行程信息，合法则将行程信息写入数据库，最后返回提示信息，活动结束。如图4.16所示
图4.16用户向购物车中添加商品功能活动图
（五）在线行程预定时序图
时序图显示了交互的参与者以及参与者之间的消息顺序。下面以在线行程预定为例分析其时序图。
图4.17行程预定功能时序图
（六）系统运行环境与开发工具
1.系统运行环境
为了保证网站运行的效率和可靠性，网站服务器端应具有较高的软硬件配置，客户端的要求不是很高。此网站可广泛运行于国际互联网即Internet，其运行要求如下：
（1）数据库：SQL server 2000
（2）应用服务器：Tomcat 6.0
（3）JDK(Java Development Kit)版本：1.5.0
2.开发工具
本网站采页面用Dreamweaver CS3作为开发工具。Dreamweaver CS3是一个可视化的建立Web站点和应用程序的专业工具，不仅提供了强大的网页编辑功能，而且提供了完善的站点管理机制，是一集网页创作和站点管理两大利器于一身的超重量的创作工具[8]。利用它的可视化编辑功能，可以快速地创建页面而无需编写任何代码。
Java代码部分采用Eclipse开发工具的MyEclipse插件进行开发实现。MyEclipse企业级工作平台是对Eclipse IDE的扩展，利用它可以在数据库和J2EE的开发、发布，以及应用程序服务器的整合方面极大的提高工作效率[9]。它是功能丰富的 JavaEE集成开发环境，包括了完备的编码、调试、测试和发布功能，完事支持HTML,Struts,CSS,JavaScript是一款功能强大的JavaEE集成开发环境，支持代码编写、配置、测试以及除错。
五、系统实现
（一）系统前台功能实现
1.基本功能的实现
基本功能包括首页的行程展示功能，该功能主要展示了旅游行程信息，主要包括天气预报，景点推荐，用户登录注册链接等。页面如图5.1所示。
图5.1 首页行程展示页面
（1）行程预定
在本网站中，行程预定功能是YooBar旅游信息平台十分重要的功能之一，该功能是消费者与旅游公司进行在线交易的入口。首先用户（普通用户、注册用户）对网站提供的行程信息进行挑选，通过点击用户中意行程的超链接对该行程的详细信息进行查看。详细信息查看页面如图5.2所示。在该页面中，用户填写参与人数后，点击"立刻加入"按钮（需要用户登录），完成行程预定操作。
图5.2行程详细信息页面
（2）行程搜索
在本网站中，行程搜索功能是一个十分重要的功能，该功能包括按照旅游级别分类进行搜索、按照旅游线路分类进行搜索、以及模糊搜索。用户在使用模糊搜索后，返回给用户的是按照不同旅游级别、不同旅游线路进行分类并统计后的结果，将结果加入了超链接，方便用户对行程进行更进一步的搜索。让用户使用起来感觉更直观，更方便。如图5.3所示。
图5.3 行程搜索页面
其他的定制服务 下方联系卡片↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 或者私信作者