铁路旅客旅程全程规划系统设计说明书.docx
《铁路旅客旅程全程规划系统设计说明书.docx》由会员分享，可在线阅读，更多相关《铁路旅客旅程全程规划系统设计说明书.docx（48页珍藏版）》请在冰豆网上搜索。
铁路旅客旅程全程规划系统设计说明书
项目名称：
铁路旅客旅行全程规划系统
作者：
周梦瑶，康艳萍，马千依，徐美燕，赵琴
版本：
V2.0
文档编号：
XXSJ1.0
铁路旅客旅行全程规划系统设计说明书
组长：
周梦瑶11254025
组员：
康艳萍11254007
马千依11254012
徐美燕11254020
赵琴11254024
2014/6/23
修改建议表
序号
修改建议
负责人
1
文档名称：
由于本文档的内容不仅包含总体设计的部分，也包括详细设计的部分，名称为设计说明书更为合理。
2
功能模块的详细设计：
原型、功能描述以及业务流程属于需求分析而非详细设计。
详细设计应包括输入输出、系统重要事件的内部处理的设计等。
3
系统总体架构图里的内容放置不够恰当，应明确图的含义，可以参考《电子商务系统的分析与设计》第5章。
序号
版本
变更内容概要
变更人/日期
审核人/日期
批准人/日期
1
1.0
初版
2
2.0
修改文档名称；单独制作原型；将原总体设计文档中的功能描述及业务流程整合到需求分析里；设计系统主要业务模块的处理。
变更记录
1.引言
1.1标识
本文档适用的系统名称为“铁路旅客旅行全程规划系统”。
系统简称为旅程规划系统，标识号为V1.0。
1.2编写目的
本文档通过设计系统的框架和概貌，指出路线规划、车站内及周边服务两大业务模块基本的功能部署和架构，并对各功能模块的输入输出及处理等做了详细设计，旨在为铁路旅客旅行全程规划系统的开发提供规划和设计的依据，为开发人员的平台开发工作提供参考和指导。
1.3定义
1）个人中心：
主要是用户个人信息的管理，记录用户偏好，以提供个性化服务。
3）输入数据：
各模块需要模块外的实体（或数据库、或系统、或其他模块、或用户）提供的数据。
4）输出数据：
该模块给模块外的实体（或数据库、或其他模块、或用户界面）提供的数据。
5）系统中转方案：
系统中转方案指系统在用户没有指定中转站的情况下为用户设计的中转方案。
在本系统中，为用户自动设计中转方案时，优先考虑中转站为与用户目的地属同一行政区划的较大型车站。
1.4参考资料
[1]刘军，马敏书.电子商务系统的分析与设计（第二版）[M].北京：
高等教育出版社，2008年3月.
[2]SteveMcConnell.代码大全（第二版）[M].北京：
电子工业出版社，2006年3月.
[3]董建全，丁保康.数据库使用教程（第三版）[M].北京：
清华大学出版社，2007年11月.
2.系统概述
本旅程规划系统旨在为选择铁路出行的、有不同旅行需求的用户，提供路线规划及个性化服务。
系统主要包括四大功能模块：
出行前的路线规划、旅途中的车站内服务、周边服务以及个人中心。
其中车站内及周边服务与GIS系统相结合，包括中转城市酒店预订、餐饮服务、导航等子功能模块；个人中心为用户提供个人信息的维护及偏好设置以满足用户的个性化服务需求，为用户提供一站式贴心的旅程规划解决方案。
2.1系统建设目标
2.1.1总目标
以旅客为中心，提供一站式旅程规划方案以及符合用户偏好的个性化服务。
根据不同类型的用户，按照用户定义提供多套出行方案及各项附加服务，最大程度满足旅客出行需求。
2.1.2分目标
1）信息高度完善——只要铁路可以提供的路线，用户都可以快速查到：
为旅客提供全面的信息查询，做到每一个车站（火车客运站）都可实现中转方案查询，即旅客没有到不了的地方。
2）服务伴左右：
为旅客提供服务指南、铁路咨询等信息，以及酒店预订、餐饮服务等网上自助功能。
3）功能更贴心：
可以依据每个旅客不同的偏好，在系统的各项功能中为用户挑选出可能更加满足用户需求的服务，满足用户个性化的要求。
2.2系统建设内容
按照需求分析中对12306网站的现状分析和系统目标的设计，系统建设内容主要分成四个部分：
用户进行路线搜索时的方案查询、系统提供方案后的方案比选、用户旅途中的车站内及周边服务、用于记录用户偏好的信息管理。
（1）路线规划
路线规划部分主要包括两个方面，路线规划的方案查询和方案比选。
方案查询指按照用户自定义的条件（出发地、中转站、是否需要中转、中转时间、目的地等）为用户提供路线规划方案。
方案比选指能够按照行程时间最短、价格最低等为用户筛选方案和提供优选方案。
（2）旅途中的车站内服务
提供车站地图导航、餐饮休闲服务、行包寄存、候车厅查询等功能，为用户提供站内全方位、便捷式的服务。
（3）周边服务
提供中转城市酒店预订、餐饮服务、休闲娱乐查询、旅游门票团购等功能，为用户提供一站式的旅程规划解决方案。
（4）个人中心
提供用户对个人信息维护、偏好设定的平台，以便系统为不同用户提供贴心的个性化服务。
3.系统架构设计
3.1系统总体架构
铁路旅客旅程全程规划系统包括路线规划、站内服务、周边服务、个人中心四大功能模块。
系统采用B/S架构、java开发语言、JSP技术、SqlServer2008数据库以及Tomcat服务器。
图3-1系统总体架构图
3.2系统模块结构
铁路旅客旅程全程规划系统包括旅程规划、车站服务、周边服务、个人中心四大子系统。
图3-2系统功能模块图
3.3系统的功能结构
铁路旅客旅程全程规划系统通过与12306的接口辅助线路查询、车票预定；与XX地图接口提供车站站内地图以及周边地图；与大众点评网接口提供酒店预订、餐饮服务、休闲娱乐等服务。
图3-3系统的功能结构图
4.路线规划业务详细设计
4.1路线规划业务需求描述
依据需求分析相关内容，系统用户对象按照中转类型划分主要有两类：
未指定中转旅客和指定中转旅客。
这两类用户的需求有一定差异，下文将分别描述这两类用户的需求。
4.1.1未指定中转旅客需求描述
（1）车次查询
用户选择始发站、终点站和出发日期（这三项为必选），以及其他可选项如车次类型、出发时段、到达时段、车票类型这四项，点击查询，可以得到符合用户条件的车次结果序列。
车次结果序列中的每一条记录都包括该车次的车次编号，始发站，终点站，开车时间，到达时间，铁路乘车用时，硬座、软座、硬卧、软卧等不同座位席别的价格情况。
（2）方案更改
用户在确定一个初始方案后，希望更新方案，可以更新始发站、终点站、出发日期中的任一项或多项，重新点击查询，可以得到一个新的车次结果序列。
（3）结果筛选
在已经得到的车次结果序列的基础上，用户希望筛选出更符合他们心意的方案，此时可以选择筛选条件，如车次类型、出发时段、到达时段这四个条件，用户选择每一个筛选条件，车次结果序列都会进行一次筛选。
（4）结果排序
在已经得到的车次结果序列的基础上，可以根据价格最优、时间最优、最快出发三种方式对车次结果序列进行排序，从而方便用户以最快的速度找到最想要的方案。
（5）方案条件收藏
对于一些用户会经常使用到的路线方案，如一个用户经常会在北京和武汉两地出差，而且一般只愿意乘坐高铁，因此选择路线时他会经常性的输入出发地为北京、目的地为武汉，或出发地为武汉，目的地为北京，车次类型选择高铁。
在这种情况下，用户可以将他做出的这些选择一起收藏在收藏夹中，当下一次他要做出同样或类似的选择时，可以直接从收藏夹中获取该选择。
同时，用户也可以修改、删除收藏夹中已有的方案条件。
（6）拼票
对于从某出发地到目的地的整票已卖完的情况，系统可以提供拼票的功能。
假如用户要从北京到武汉，但是用户所希望的某趟车次已经没有从北京到武汉的整票。
而系统检测到该车次从北京到石家庄有票，从石家庄到武汉有票，因此系统可以为用户提供同车次从北京到石家庄和从石家庄到武汉的两张票，帮用户即使在整票卖完的情况下，也可以乘坐该车次列车出行。
另外指出，拼票功能只对同一坐席有效，例如软座和硬座不能拼票，卧铺和坐票不能拼票。
4.1.2指定中转旅客需求描述
指定中转的旅客往往对于其需要中转的中转站、中转时间、中转目的有明确的掌握。
这类旅客除对中转方案有额外需求，其他需求与未指定中转旅客的需求基本一致，因此下文将仅针对该类旅客在中转方案方面进行需求描述：
（1）中转项增加
旅客可以随时限定数量的增加中转方案，每一个中转方案中用户可以选择中转城市、中转站、中转站停留时长这三项。
用户最多可以有三个中转站。
中转站之间有顺序关系。
（2）中转项修改
针对中转方案序列中的每一个方案，用户都可以进行更改，点击查询，获得新的中转车次信息。
（3）中转项删除
旅客也可以删除中转站序列中的某一个站，点击查询。
4.2类图设计
4.2.1发现类
通过以上需求描述，可以发现以下关键类。
实体类：
用户信息，指定中转用户信息，未指定中转用户信息，方案条件，中转条件，中转条件序列，车次结果，车次结果序列，某车次座别及价格序列，某车次座别及价格项，收藏夹类。
处理类：
方案查询类，方案筛选类，收藏夹增删改查类。
4.2.2类的职责分析
根据需求描述可知，实体类和处理类分别有如下职责。
4.2.2.1实体类职责
方案条件类：
方案条件类有出发站，目的站，出发日期，车次类型，出发时段，到达时段，车票类型，中转条件序列这八个属性。
其中中转条件序列属性依赖于中转条件序列类。
中转条件序列类：
由于用户可以选择多个中转站，因而中转条件序列类是由多个中转条件类聚集起来的，可能有0项、1项或多项。
中转条件类：
是指定中转方案的用户会做出的条件指定。
包括中转地、中转时间、中转车站等属性。
车次结果序列类：
值用户点击查询后系统返回的服务用户条件的结果集，该车次结果序列由车次结果类聚合而成。
车次结果类：
根据需求描述，每一条车次结果都有车次编号、始发站、终到站、开车时间、到达时间、铁路乘车总时长、座别及价格序列这7个属性。
其中座别及价格序列由座别项类聚合而成。
座别-价格类：
根据需求描述，座别项类包含坐席类型和该坐席对应的价格这两个属性。
收藏类：
收藏类指用户收藏的每一项，根据需求描述，该类有两个属性：
收藏名称和方案条件类。
从而确定出用户收藏的方案条件。
收藏夹类：
收藏夹类是用户所有收藏的方案条件的集合。
在收藏夹类中，可以对各个收藏项进行增删改查操作。
4.2.2.2处理类职责
结果筛选类：
根据用户添加或删除或修改的方案条件，实时返回重新筛选后的车次结果序列给用户。
该类中主要提供两种方法：
1）修改方案条件。
2）获取结果序列。
结果排序类：
用不同的排序方式，对车次结果序列进行排序，按照需求描述，排序主要价格最优、时间最优、最快出发这三种方式。
因此结果排序类主要提供三种方法：
价格最优排序、时间最优排序、最快出发排序。
方案查询类：
在用户提交方案条件后，对方案条件进行处理，为用户返回车次结果序列。
主要提供一种方法：
获取结果序列。
4.2.3类图设计
根据以上对类的职责的分析和类之间关系的分析，得到以下类图，如图3-1所示。
图3-1路线规划业务类图
4.3用例设计
4.3.1记录需求
根据上文需求描述，对需求的进行了简要记录，如表3-1所示
编号
说明
1
不指定中转的路线查询
2
指定中转方案后的路线查询
3
结果筛选
4
结果排序
5
方案条件收藏
6
收藏夹中的方案条件删除
7
收藏夹中的方案条件修改
8
中转方案添加
9
中转方案修改
10
中转方案删除
表3-1路线规划业务需求记录表
4.3.2需求分类获得用例
将上文记录的需求归类，获得用例，如表3-2所示。
特性
用例
1.不指定中转的车次查询
2.指定中转方案后的车次查询
UC01.路线查询
3.结果筛选
4.结果排序
UC02.查询结果优化
5.方案条件收藏
UC03.方案条件收藏
6.收藏夹中的方案条件删除
7.收藏夹中的方案条件修改
UC04.方案条件收藏夹管理
8.中转方案添加
9.中转方案修改
10.中转方案删除
UC05.中转方案指定
11.使用收藏的方案条件
UC06.使用收藏的方案条件
表3-2需求归类获得用例
4.3.3用例图
根据上文获得的用例以及对用例之间的关系的分析，绘制如下用例图，如图3-2所示
图3-2路线规划业务用例图
4.3.4细化用例描述
接下来，本文对以上归纳出的四个主要用例——路线查询、查询结果优化、方案条件收藏、使用收藏的方案条件——的描述进行细化。
4.3.4.1路线查询用例描述
用例名称
路线查询
简要说明
根据用户提交的方案条件，查询并返回可行的结果序列
事件流
基本事件流：
1）用户设置好方案条件，点击“查询”按钮提交。
2）系统检验用户提交的方案条件。
若条件不合格，返回让用户重新填写；若条件合格，判断该方案条件是用户指定中转还是用户未指定中转。
3）若用户未指定中转，则查询该方案条件下的直达结果；若始发站和目的站可以直达，则返回整票和拼票信息；若始发站和目的站无法直达，则查询中转结果。
4）若用户指定中转，则系统按照用户提供的中转项的顺序，依次查询从始发站到中转站1，从中转站1到中转站2……，从中转站3（中转项最多不超过3）到目的站的结果序列，每次查询的步骤依照步骤3）所示。
5）将最终查询结果返回给用户。
拓展事件流：
4a）若用户指定的中转项=3并在继续添加中转项，提醒用户无法添加。
非功能需求
无特殊需求
前置条件
用户登陆成功
后置条件
系统返回查询结果序列
4.3.4.2查询结果优化用例描述
用例名称
查询结果优化
简要说明
根据用户更新的方案条件，更新结果序列
事件流
基本事件流：
1）用户添加、删除或更改结果筛选项，或单击排序方式按钮。
2）系统获取用户更改的某项方案条件。
3）根据该项更改条件对已有的结果序列进行更新。
4）返回新的结果序列给用户。
拓展事件流：
无拓展事件流
非功能需求
无特殊需求
前置条件
系统返回查询结果序列
后置条件
系统返回更新后的查询结果序列
4.3.4.3方案条件收藏用例描述
用例名称
方案条件收藏
简要说明
用户收藏某方案的系列条件
事件流
基本事件流：
1）用户设置好某方案的系列条件，点击收藏按钮
2）系统检查用户的方案条件是否合格。
若不合格，收藏不成功，提醒用户修改方案条件；若合格，系统将该方案条件添加到该用户的收藏夹中。
拓展事件流：
无拓展事件流
非功能需求
无特殊需求
前置条件
用户设置好某方案的系列条件
后置条件
收藏夹添加用户方案条件完成
4.3.4.4使用收藏的方案条件用例描述
用例名称
使用收藏的方案条件
简要说明
用户使用收藏过的方案条件，简化查询过程
事件流
基本事件流：
1）用户打开他的个人收藏夹，选择其需要的方案。
2）系统将该方案的各项条件自动填充到网站页面的各项表单框中。
拓展事件流：
2a）若用户收藏的方案条件过于久远，某些条件与系统出现不匹配现象，系统自动将用户收藏的各项方案条件中与系统匹配的条件填充到表单框中，并提示用户有哪些条件与系统不匹配，需要修改。
非功能需求
无特殊需求
前置条件
用户收藏夹不为空
后置条件
将用户选择的方案条件成功添加到相应表单框中。
4.4交互图设计
在用例细化的基础上，本文接下来绘制出如下交互图。
4.4.1路线查询交互图
图3-3路线查询交互图
4.4.2结果优化交互图
图3-4结果优化交互图
4.4.3方案收藏交互图
图3-5方案收藏交互图
4.5基本算法
4.5.1直达基本算法
1）获得用户输入的始发地和目的地
2）从时刻表中找到有余票、途径始发地的所有记录，记为table1；同时从时刻表中找到有余票、途径目的地的所有记录，记为table2.
3）从table1和table2按照车次相同进行自然连接得到table3，从table3中选出始发站的顺序序号<到达站的顺序序号的记录。
4.5.2系统中转基本算法
以从北京到云梦为例（北京到云梦没有直达车）
1）找到所有可以与北京直达的车站，记为table1；找到所有可以和云梦直达的车站，记为table2；找到table1和table2的交集的车站table3.
2）根据table3的记录数量来判断是否需要做优化，若table3记录数量>10，则在所有记录中选择离云梦最近的10条记录。
若table3记录数量<=10，则保留table3不变。
3）对table3中的记录依次遍历，分别找出从北京到table3某记录的直达车T1以及该记录到云梦的直达车T2，同时保证T`1的到站时间与T2的发站时间之间的时长在2-5个小时之间。
4）返回符合以上三个条件的中转方案。
4.5.3拼票算法
以北京到武汉的T15车次为例。
1）找到T15车次北京站和武汉站之间的所有车站，得到table1
2）遍历table1，找到北京站table1某记录的某席别的余票数量，同时找到table1某记录到武汉站的某坐席的余票数量，若两者的余票数量总和都>0，则该车次的该席别可以拼票。
4.5.3用户指定中转基本算法
以北京到武汉，用户指定中转站为石家庄为例。
1）找到北京到石家庄的直达车，若没有，参照系统默认中转算法。
将所有可行的北京到石家庄的出行方式存为table1。
2）找到石家庄到武汉的直达车，若没有，参照系统默认中转算法。
将所有可行的石家庄到武汉的出行方式存为table2。
3）选出table1中到站时间与table2中发站时间之间的时长为2—5小时的出行方案。
将该方案序列返回给用户。
5.数据库设计
5.1数据库设计思想
遵循数据库3NF的设计要求，在特殊情况下，允许有少量的数据冗余。
5.2系统数据整合
系统数据主要包括以下内容。
5.2.1基础类数据
设计此类数据是为了方便及规范用户的输入，以及提高速度
基础类数据主要指字典类数据，包括对各实体的属性和编号的数据。
主要包括车站属性数据，车站、城市编号数据。
5.2.2业务类数据
系统业务主要分为路线规划和车站内及周边服务两大业务。
路线规划中为了实现为用户进行直达规划和自动中转规划的功能。
包括的数据主要有时刻表数据、票价数据、城市-车站映射数据以及城市级别数据。
车站内及周边服务业务中为用户提供车站的周边服务，包括一张全国的车站地图以及存在于车站地图内的地理位置信息表。
5.2.3日志类数据
为了数据的有据可查以及错误的查找，同时辅助数据分析，跟踪用户行为，设计了日志类的数据。
在跟踪用户行为方面，日志类数据记录了用户登陆信息，请求旅程规划的始发点信息。
在记录系统数据方面，日志类数据记录了系统中以往数据的所有错误记录。
5.2.4用户类数据
用户类数据主要包括基础的用户数据和为了满足用户个性化需求所设计的用户个性化数据表。
5.3数据逻辑结构设计
5.3.1基础数据表
车站
编号
表5-1车站编码表
5.3.2业务数据表
5.3.2.1路线规划业务
路线规划业务中，系统需要提供的业务主要有直达路线规划和自动中转路线规划。
在直达路线规划中，系统根据用户提供的出发站和目的站的信息，加上其他一些限制条件，通过数据库中的各类表的操作选出最终满足用户需求的路线规划方案。
在这种情况下，使用到的表主要有以下三个：
时刻表、票价表和城市-车站表。
具体操作过程如下：
首先，由于用户输入的出发地、目的地都是城市信息，因此需要将城市信息经过城市-车站表映射到具体的车站；接下来通过车站表找到车站和和车站的直达车次，找到车次后根据用户的条件（例如用户选择高铁这一车次类型）筛选出符合的车次。
最后，根据车次信息和用户提供的始发、终到信息，通过票价表计算出用户需要支付的票价。
车次
车站
到达时刻
出发时刻
车次类型
K371
北京
08:
25
08:
55
k-快速
K371
石家庄
09:
50
09:
50
k-快速
表5-2时刻表
车次
出发地
到达地
成人票价
学生票价
表5-3票价表
城市
车站
北京
北京西站
北京
北京南站
表5-4城市-车站表
在中转路线规划中，系统需要在用户的出发地和目的地无法直达的情况下为用户自动挑选出合适的中转方案，即称为系统中转方案。
为了使中转站与用户的目的地更近或让两个在同一行政区划内，系统设计了一张城市级别表。
在这张城市级别表中，城市分为一级、二级、三级、四级，因此城市级别的信息是一种树形结构，为了更好的在数据库中表现树形结构，需要设计一种特殊的编号方式。
编号方式如下：
1）编号采用6为，前两位表示省编号，3、5位表示市编号，5、6位表示县、乡、镇、村编号。
2）如某个省的编号为55，则该省的省会城市会550100。
若该省的某市级的编号为5506，则该市的编号为550601。
按照该编号方式，设计的城市级别表如下表所示。
ID
名称
编号
级别
表5-5城市级别表
5.3.2.2车站内及周边服务业务
车站内及周边服务业务主要需要存储的是地理信息，地理信息中包括很多图层，每个图层都有各自的名称、地理位置和建筑用途的数据。
基于此设计如下3种表格：
图层表，图层-实体映射表，实体表
图层ID
图层名称
数据类型
空间实体
属性字段
说明
表5-6图层表
图层ID
实体ID
X
Y
表5-7图层-实体表
实体ID
名称
应用类型
备注
表5-8实体表
5.3.3用户数据表
用户数据表中主要包括用户基本信息表和个性化用户信息表。
ID
用户名
密码
手机号
邮箱
表5-9用户注册信息表
ID
身份证号
订阅路线
收藏路线
喜好车次类型
表5-10用户个性化信息表
6.系统安全设计
6.1系统安全总体框架
结合系统对网络与信息安全的需求，将整个安全体系划分为六个层次：
实体级安全、网络级安全、系统级安全、数据级安全、应用级安全和管理级安全，其中在应用级的最上层是平台的服务安全，如图所示。
图6-1安全体系框架图
●实体级安全
包括系统的物理安全及链路通信的安全。
通过机房出入管理、防水防火、电磁屏蔽、身份识别与认证、访问控制、I/O通道控制等措施保障物理安全；通过设备防护、冗余设置、配备UPS等方式保护通信安全。
●网络级安全
是指网络互联时在网络通信层的安全问题。
具体措施包括使用虚拟专网技术构建子网，根据网络地址控制网络接入设备的能力；通过节点身份识别、应用网关及防火墙等在网络边界建立防护体系；通过网闸等物理隔离方式严格控制与外网的连接，并做好网络监控、管理及安全审计等工作；在服务器控制台上执行操作权限控制，按用户权限控制入网时间、终端使用，以及对文件或目标的使用权限控制等。
●系统级安全
升级会员 