火车订票系统.docx
《火车订票系统.docx》由会员分享，可在线阅读，更多相关《火车订票系统.docx（44页珍藏版）》请在冰豆网上搜索。
火车订票系统
8.总结
8.1收获体会（一人一份）
8.2小组总结
8.3待改进之处
1．引言
1.1编写目的
车票代理窗口购买车票是最传统的方式。
但随着人们工作生活节奏的加快和互联网的普及以及信息化时代的到来，提前到代理点购买车票就显得有些耗费时间了。
于是，越来越多的人开始采用网络购票的方式。
其中12306网络订票系统在铁路客运系统中扮演着越来越重要的角色，成为了越来越多人的订票方式。
该系统的稳定运行也是人们能够方便出行的保障。
对12306系统的分析和研究，有助于我们吸取其经验教训，总结成功经验。
对网络订票系统进行优化，构建一个可靠的、稳定的网上购票系统，满足市场的需求，为广大人民群众提供一个方便可靠的订票平台。
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
本文档供项目经理、设计人员、开发人员参考。
1.2项目背景
软件名称：
12306购票网站
委托单位：
中国铁路局
开发单位：
哈尔滨理工大学
主管部门：
软件学院
用户：
广大人民群众
本项目采用客户机-服务器原理，客户端的程序是建立在Windows10系统上，以MicrosoftVusualC++为开发软件的应用程序，是采用SQLserver为开发软件的数据库服务程序。
1.3参考资料
参考资料：
[1] 张海藩，软件工程导论（第四版）[M].北京：
清华大学出版社，2003
[2] 王珊，萨师煊.数据库系统概论[M].北京：
高等教育出版社，2006
[3] 中国铁道部网站。
[4] 闪四清， SQL Server 实用简明教程[M].北京：
清华大学出版社，2003
[5]郑人杰，实用软件工程（第二版）[M].北京：
清华大学出版社，1997
2．系统概述
2.1现状描述
2.1.1优点
1、建立售端票源数据库，将纸质火车票全部电子化数据化，相当于建立了电子车票仓库。
2、实现全域共享，构建了分布式异地售票网络，在任一某地均可实现购买全国各地的火车票，方便不少。
3、售票全部实现了电脑化操作，出错率低。
菜单式录入，售票、退票、、查询很方便。
4、提高用户购票的便捷性，不需要到火车站或者指定代售点购票，也避免了排队抢票的现象。
5、旅客使用二代居民身份证在网站购票且不晚于列车开车前36小时的，可以选择车票快递服务，节省取票时间。
6、自主选择式购票，可以选择火车类型、座位类型、时间、票价等。
2.1.2缺点
1、由于网页浏览人数过多，网络拥挤，经常提示“您的操作过于频繁”，用户体验差。
2、选座位系统不完善，另外一个账号同时购买多张票时，很有可能座位不在一起，给出行带来不便。
3、12306需要用身份证信息注册，但是存在同名并且身份证相似或者信息泄露情况，部分用户身份信息被抢注，需要本人前往车站处理。
各节假日车票紧张，导致抢票软件的猖獗，难以保证用户购票公正性。
虽然购票需要实名认证，但是不法分子依然可以冒用他人信息进行刷票，哄抬票价，而真正需要的人买不到票。
2.2系统开发方法
本12306系统开发模型采用瀑布模型
瀑布模型是一个特别经典，甚至有点老套的周期模型，一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。
瀑布模型把软件开发过程划分成若干阶段，每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。
与我们小组合作开发的步骤不谋而合。
本12306系统开发模型采用的瀑布模型是因为软件需求在开发阶段已经被完全确定，并将生命周期的各项活动依顺序固定，强调开发的阶段性； 采用瀑布模型核心思想是将12306系统按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
利用瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
这就意味着开发流程简单，为项目提供了按阶段划分的检查点，当前一阶段完成后，只需要去关注后续阶段。
同时采用瀑布模型也存在很多弊端：
在项目各个阶段之间极少有反馈，只有在项目生命周期的后期才能看到结果，通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
开发后期要改正早期存在的问题需要付出很高的代价，用户需要等待较长时间才能够看到软件产品，增加了风险系数。
2.3开发计划
2.3.1目的
1、杜绝无限账号注册、杜绝身份冒用
1）12306注册时，强制预留电话号码，且进行验证，重复电话号码不予注册。
2）取票时，取票机应该确认该身份证是否有12306账号，有且不是该身份证本人注册的假账号，直接注销。
3）重复3次退订的先去取票机刷身份证，之后才让再次订票。
且将此身份证列入黑名单，只准买单线票（例如为期10天）。
2、完善选座系统，实现“同行者邻座”或“老年人优先下铺”等期望。
3、可以生成旅客行程流向信息，便于铁路运力调度，车次调整。
4、解决公平分配票源问题，加大购票的门槛，采用复杂的验证码等手段，杜绝任何利用技术、时间和操作优势下的抢票，把票留给真正需要的人。
5、提高技术，减少用户在线操作时间，不用盲抢、死拼、不停刷在线存在感，所有票务和车务、路务均可使用离线查询或从公示信息得知。
解决系统经常不能访问、繁忙、崩溃的现象。
2.3.2步骤
1、规划：
根据项目背景、现状，定义产品的目标市场、商业目标等。
2、软件工程过程模型：
根据项目开发特点选择瀑布模型，使用c++语言开发。
3、项目测算：
分析项目经济可行性和技术可行性，根据计划阶段法和功能点发估算项目规模，并求得大致代码行数。
根据cocomo模型估算所需人数和时间进度，完成工作计划创建。
4、需求定义和收集：
根据项目类别给出功能性和非功能性定义，本项目需求收集技术采用问卷法。
5、需求分析和系统初步设计：
选择合适需求分析技术，整理用例，绘制数据流图。
系统设计：
对项目进行数据结构设计，建立实体-关系图。
简单进行代码设计，设计用户界面。
6、测试与维护：
对系统进行测试以及出错维护处理。
2.4经济可行性
基建投资
SQL Server:
20 万
Windows NT:
10 万
操作员培训费：
5 00万
终端PC机2000台：
8000*20 = 1600 万
网络设备：
1000 万
辅助配置：
1000 万
经常性支出
系统维护人员支出：
250元/（人天）X 10（人）=2500元/天
机器磨损费用 ：
20000元/天
机器（硬件）维护费用：
100元/（人天）X 200=20000元/天
经常性收益
（按银行利率：
1%）；
减少员工20人（1000元/人）五年收益:
1000*（1.1+（1.1）2+（1.1）3+（1.1）4+（1.1）5）*20*12*5=120万
工作效率提高收益（工作效率提高30%）:
30*（1.1+（1.1）2+（1.1）3+（1.1）4+（1.1）5）*（30%）*5 = 45万
经常性收益共计:
160万
不可定量收益
因服务质量提高增加顾客量10%:
1000万*10%*（90%+（90%）2+（90%）3+（90%）4+（90%）5）=540万
收益共计:
700万
收益/投资比
700/453.5=154.4%
投资回收周期
3.2年
2.5技术可行性
目前，公司的管理工作和服务工作存在盲目性、随意性、和无效消耗，不能保证营销部门的工作质量，影响商品的销售，给公司带来实际的和潜在的经济损失。
虽然系统开发初期投资较大，但是，若开发成功本系统，将有助于公司更好地预测市场，更好的开发客户及时调整经营销售策略，在激烈的市场竞争中把握主动。
因此，从长远利益考虑，本项目若能开发成功，它所带来的效益将远高于系统投入。
（1）风险分析
根据客户对项目的要求及我们对以往的开发经验，该项目开发的主要风险是系统的可维护性。
为了提高该系统的可维护性，可以从两方面来解决这个问题。
一是，采用面向对象的方法对该系统进行设计和实现，将系统可能产生的维护问题分散到系统分析、设计、实现等各个阶段，尽可能采用可复用构件的设计实现，从设计方法和设计理念上根本解决这个问题。
虽然开发成本会提高一些，但今后如果需要更新升级，只需要更新相应的构件就可以了，这样可以大大减少系统维护的成果。
二是，吸收员工参与到项目的开发过程中来，使其了解该系统的体系结构和设计思想，在开发过程中培养自己的软件应用技术人员。
当系统交付使用时，他们能够承担系统的日常维护和小的改进工作。
（2）资源分析
该项目投入经费相对充裕，基本能够满足系统开发所必须的一些软件、硬件、工作环境的要求。
开发该形态需要掌握浏览器技术等多项技术。
多年的专业学习，
在团队精神和敬业精神上都具备了有力的保证条件。
（3）技术分析
该项目的开发，要具有类似项目的经验。
当前计算机技术的发展水平以及开发人员以及熟练掌握的各种开发先进技术，完全能够满足该系统开发的需要。
该系统应该没有太多的难点，不过需要开发过程中更多的努力和耐心。
2.6估算项目规模
项目规模进行估算是为了将项目的范围进行量化，项目规模的估算是整个软件估算中最核心、最基础的环节，也是整个估算的第一步。
1、 项目工作量
每日可以实现订票量200万张左右，注册人数超过1000万，日点击数过亿的操作
2、 项目所需资源
铁道部系统对接，票池对接
3、 项目各阶段工作量
前端设计占七成，后端设计占三成
4、 项目成本
预算需要花费2亿元，最后花费5亿元
甘特图：
2.7业务流程图
总流程图：
客运服务流程图
货运服务：
行李服务：
成功预订之后：
3．系统分析
3.1性能需求
数据精确度 ：
1.对列车的各种数据有精确的记录，例如：
各个列车的属性，如：
列车的型号、车次号；各个列车的车厢数、床位数、座位数。
2.查询时应保证查全率，所有在相应域中包含查询车次的记录都应能查到，同时保证查准率。
3.对列车的每天需更新的数据有详细的记录，例如：
每天列车的出发时间、进站时间、出站时间、到达时间等。
4.对列车的每时需更新的数据有详细的记录，例如：
因为突发事件导致列车时间上的变更要及时地将数据进行更新。
5.对用户自身的数据需有精确的记录，特别是时间、金额、密码等重要敏感数据，依照铁道部的要求制定出相应的精度方面的要求。
6.本子系统位广大人民群众进行订票服务，应支持最大并发用户50000000个以上，每秒事务处理数应大于100000笔以上
时间特性：
1.程序响应时间：
在人的感觉和视觉事物范围内；
2.在硬件和网络条件满足的前提下，所有日常性操作购票事务的平均响应时间小于1秒，最长响应时间小于2秒；
3.对于查询性事务的平均响应时间应小于1秒，最长响应时间应小于3秒
4.2信息交换时间：
要求在程序调用前调用后都与数据库保持同步更新，网络信息交换施加应该小于程序调用时间
适应性：
1.要求数据库局用很好的更新能力，由于本产品为成品软件，所以对磁盘和内存容量有很大要求，数据库应该能够对并发事件。
2.磁盘容量：
由于要存贮大量的数据和信息，所以要求要有足够的磁盘容量。
3.主存容量：
为了满足购票用户的的要求，系统必须要有高的运作速度，购票用户填写的数据输入到系统，系统必须能快速及时作出响应，迅速处理各项数据、信息，显示出所有必需信息并生成票务信息，所以要求很高的信息量速度和大的主存容量。
4.为了方便广大人民群众使用此订票软件，适应性要强，能够方便的使用在大部分人的不同类型手机及系统的电脑上。
3.2功能需求
主营业务需求：
此处包含了如下几个大块的基本需求。
1、客运服务需求：
此需求是本系统的需求核心，是构建一个以用户为中心，围绕用户在铁路旅行方面的服务需求来进行展开的各项服务，其基础服务包含如下几块：
1．出行接行服务：
a.用户注册：
用户可以在电脑或手机等电子设备上注册成为本站的会员，只有成为会员后才能进行涉及经济方面的操作，如：
车票预订等。
b.车票预订：
用户可以在成为会员之后根据自己的行程进行车票的购买或预订。
c.退票服务：
如果会员发现自己的行程有变动，可以选择退票服务将已经购买或预订并且没有到发车时间的车票进行退票。
d.改签服务：
如果会员发现自己的行程有变动，打算改天或者改车次但是始发地和目的地不改变的话可以选择改签服务。
e.变更到站服务：
如果会员发现自己的行程有变动，始发地不动但是要换个站下车可以选择变更到站服务。
f.余票查询：
用户可以对两个站点间的剩余票数进行查询，以方便自己行程的预订。
余票张数为全部席别的总数，30分钟更新一次。
g.旅客列车时刻表查询：
用户可以对于每个列车计划规定的发车、到达、停靠等时间进行查询。
h.旅客列车正晚点查询：
用户可以对过去1小时和未来3小时内列车正晚点信息进行查询。
i.车票查询：
用户可以选择出发日期、时期、出发点、目的地来进行查询选择自己想要的车票。
j.票价查询：
用户可以对各个时间的、不同车次的票价进行查询、
k.中转查询：
用户可以查询各个列车中转站点以及时间。
l.车次查询：
用户可以查询各个车次。
m.起售时间查询：
用户可以查询所需要的票的起售时间。
n.客票代售点：
用户可以查询各个地点的客票代售点。
2．行李服务：
a.提供货物交运：
用户可以提前选择自己想要进行托运的物品进行托运，这里提供托运的时间、路线。
b.状态监控：
用户可以在这里查看自己说托运的行李到了什么地方。
c.到站提取：
已经到站的物品会在这里显示出来，用户可以进行查看。
3．用户支付服务：
a.便捷支付：
会员可以在这里对已经预订的票进行字符购买。
本网站仅支持主流银行以及网银支付。
b.支付账单：
会员可以在这里对还没有支付的账单进行支付以及对已经支付的账单进行查看。
c.退款：
如果会员进行了退票服务的选择，则在这里可以进行退款服务的进行与查看。
d.支付投诉：
如果会员在支付的金额方面有疑问可以在这里进行投诉，客服人员会在后台进行处理。
2、货运服务需求，此处系统需求的核心是构建一个以服务于货运主的货运需求为核心的各项服务，其基础服务包含如下几块：
1．货运服务：
a.运输业务办理：
在这里可以对包含整车、散货、小件物品的运输业务进行办理。
b.理赔业务办理：
如果运输途中产生了偏差可以进行赔偿业务的办理。
2．货运信息服务：
a.货运路线：
可以在这里查询货运路线以便进行选择。
b.车辆信息查询：
可以查看车辆运输参数、运输能力、运价、保价、运输时刻信息、货物安全保障信息、运输方案等各种车辆运输信息服务，其目的是帮助货主寻求合适的运输方案，提供便捷的货运服务。
3．支付服务：
a.企业支付服务：
可以以企业为单位进行运输选择并支付，支持线上与线下支付服务。
b.个人支付服务：
可以以个人为单位进行运输选择并支付，支持线上与线下支付服务。
c.支付账单：
会员可以在这里对还没有支付的账单进行支付以及对已经支付的账单进行查看。
d.支付投诉：
如果会员在支付的金额方面有疑问可以在这里进行投诉，客服人员会在后台进行处理。
三、后台管理需求，包含如下几部分：
1．客运管理后台：
提供各类客运相关的基础数据譬如列车班次信息、时刻表信息、票价信息、车票分配策略调控、列车运行时刻信息、各种起售时刻信息等；
2．货运管理后台：
提供各类货运相关的基础数据譬如列车的车辆运输参数、线路信息、运力、运能、时刻、运价等各类跟货运相关的信息；
3．信息发布管理后台：
提供跟铁路运输相关的各种法规、规程、信息集装、新闻、公告信息等的录入、维护等。
3.3非功能需求
1、可用性需求：
要求用户操作简便，人机界面简单明了，用户能一目了然的清楚需要做什么，该如何操作。
对于常用的数据项等，设置自动提供，减少用户录入工作量。
本系统应能让任何用户，都不必借助任何操作手册或相关的系统帮助就能顺利地进行各种操作，要求系统应该尽量使用用户熟悉的术语和中文信息界面，从而保证可用性。
2、可靠性需求
系统建成后，预计将有大量的用户在此查询车票信息，并进行大量的预订操作，因此对系统的稳定性也有较高的要求。
要求在系统正常情况下长时间不间断进行，使系统所有功能满足设计需求，正常完成系统业务，对于用户输入的一些异常数据，能有判断的采取解决措施。
3、安全需求
网上订票系统中涉及的数据，是客运公司重要的信息，不同的用户具有不同的使用权限，具有最高权限的系统管理员可以对系统进行修改、注销数据库中信息，具有一般权限的使用者只能读取自己相关信息，不能浏览其他用户信息。
系统还要提供方便的手段供系统维护人员进行数据备份、日产安全管理、以及系统意外崩溃时数据的恢复等工作。
系统还要保持实时更新的状态，以便用户查询信息。
设置验证码，防止机器刷票。
3.4收集需求技术
此系统采用问卷法来收集需求。
因为问卷法可以节省时间，人力和经费。
更重要的是调查结果容易量化，方便实施分析也方便数据发掘。
问卷如下：
关于火车购票系统（12306）需求问卷调查
1.你的年龄是（）
A.未成年
B.18-22
C.22-45
D.45以上
2.您的每月收入（）
A.没有收入能力
B.五百以下
C.500-2000
D.2000以上
3.您的职业是（）
A.学生
B.教师
C.医生
D.军人
E.个体户
F.公务员
G.公司及企业职工
H.农民
I.其他
4.常用的出行手段（）
A.铁路
B.航空
C.长途巴士
D.自驾车
E.轮船
5.是否使用过网上订票（）
A.用过
B.没有
6.对订票网站的使用结果满意么（）
A.很满意
B.满意
C.还凑合
D.不怎么样
7.是否期待更方便的购票方式（）
A.期待
B.无所谓
8.平时在什么网站下载火车购票软件（）
A.软件管家
B.软件站
C.软件官网
D.搜索引擎
9.对于火车票务系统的期待（）
A.图形界面
B.高效
C.方便快捷
D.安全性能
10.常用购票方式（）
A.售票点
B.电话订票
C.网上购票
D.委托购票
11首次网上订票时，您对于注册这一步有什么想法?
（）
A.很好，信息更全面
B.没感觉
C.太繁琐，费时间
D.其他
12.您在购票登陆时，遇到提示网站用户过多情况的频率?
（）
A.经常
B.偶尔
C.从来没有
13.您对网上购票的顾虑是什么？
（可多选）（ ）
A.网络安全问题（银行卡信息、个人信息等）
B.取票需再排队，费时间
C.余票信息更新慢
D.退票返款速度慢，且退票次数有限
E.网页设计繁琐，买票过程复杂
F.付款时间段有限，系统反应慢
G.容易被犯罪分子利用进入“高仿网站”而陷入网络诈骗
H.随机派号，不能保证和友人坐在一起
I.其他
14.您对网络订票界面设计的满意度（ ）
A.很满意
B.满意
C.还凑合
D.不怎么样
15.您对网络订票付款方式的满意度 （ ）
A.很满意
B.满意
C.还凑合
D.不怎么样
16.您对网络订票退票流程的满意度（ ）
A.很满意
B.满意
C.还凑合
D.不怎么样
17.您认为网上订票和传统排队购票相比具有哪些优势？
（可多选）（ ）
A.缓解了火车站和代售点的售票压力
B.方便了乘客买票，节省了乘客的购票时间
C.可以避免黄牛党倒票的现象
D.可以方便的看到相应车次的余票情况，有利调整出行时间
E.其他
18.您对火车购票系统（12306）有什么意见：
3.5用例分析（用例图）
3.6数据分析
3.6.1数据库设计
数据库是一个单位或是一个应用领域的通用数据处理系统，它存储的是属于企业和事业部门、团体和个人的有关数据的集合。
数据库中的数据是从全局观点出发建立的，按一定的数据模型进行组织、描述和存储。
其结构基于数据间的自然联系，从而可提供一切必要的存取路径，且数据不再针对某一应用，而是面向全组织，具有整体的结构化特征。
数据库中的数据是为众多用户所共享其信息而建立的，已经摆脱了具体程序的限制和制约。
不同的用户可以按各自的用法使用数据库中的数据；多个用户可以同时共享数据库中的数据资源，即不同的用户可以同时存取数据库中的同一个数据。
数据共享性不仅满足了各用户对信息内容的要求，同时也满足了各用户之间信息通信的要求。
1、关系模式
用户信息（身份证号、用户名、密码、真实姓名、地址、邮箱、联系方式）
登录信息（用户名、密码）
订单信息（身份证号、订单编号、列车车次、发车时间、支付方式、取票方式、购票日期、上车站、下车站、购票数量）
车票信息（列车车次、出发时间、到达时间、发车日期、始发站、终止站、停靠站、座位类型、车型、剩余票数、票价、订票时间）
查询（用户名、身份证号、车号、发车日期、发车时间）
改签（订单编号、手续费）
退票（订单编号、手续费）
变更到站（订单编号、差价）
2、表设计
（1）用户信息表结构
列名
数据类型
是否为空
身份证号
int（20）
主键
密码
char（10）
NOTNULL
真实姓名
char（10）
NOTNULL
用户名
char（10）
NOTNULL
地址
char（10）
NOTNULL
邮箱
char（10）
NULL
联系方式
int（20）
NOTNULL
（2）登录信息表结构
列名
数据类型
是否为空
用户名
char（10）
主键
密码
char（10）
NOTNULL
（3）订单信息表结构
列名
数据类型
是否为空
身份证号
int（20）
主键
订单编号
char（10）
NOTNULL
列车车次
char（10）
NOTNULL
发车时间
char（10）
NOTNULL
支付方式
char（10）
NOTNULL
取票方式
char（10）
NOTNULL
购票日期
char（10）
NOTNULL
上车站
char（10）
NOTNULL
下车站
char（10）
NOTNULL
购票数量
int（3）
NOTNULL
（4）车票信息表结构
列名
数据类型
是否为空
列车车次
char（10）
主键
出发时间
char（10）
NOTNULL
到达时间
char（10）
NOTNULL
发车日期
char（10）
NOTNULL
始发站
char（10）
NOTNULL
终止站
char（10）
NOTNULL
停靠站
char（10）
NOTNULL
座位类型
char（10）
NOTNULL
车型
char（10）
NOTNULL
剩余票数
char（10）
NOTNULL
票价
char（10）
NOTNULL
订票时间
char（10）
NOTNULL
（5）查询表结构
列名
数据类型
是否为空
用户名
c
升级会员 