软件工程课程设计文档.docx
《软件工程课程设计文档.docx》由会员分享，可在线阅读，更多相关《软件工程课程设计文档.docx（42页珍藏版）》请在冰豆网上搜索。
软件工程课程设计文档
课程设计任务书
题目：
列车售票系统
组员
组员
专业计算机科学与技术
课程实用软件工程
指导教师职称讲师
完成时间：
2011年06月----2011年06月
《立项建议书》
1.引言（Introduction）
1.1目的（Purpose）
本文档是软件立项书，目的是代替可行性分析。
1.2范围（Scope）
本文档只适应于软件立项。
1.3术语定义（TermsGlossary）
[1]车票预订系统：
由售票员及售票管理员根据顾客要求进行车票预订操作；
[2]售票系统：
由售票员及管理员根据顾客要求进行售票操作；
[3]退票系统：
由售票员及管理员根据客户要求进行退票操作；
[4]车次查询：
由售票员及管理员根据顾客要求进行查询操作；
1.4参考资料（References）
[1]实用软件工程（第2版）赵池龙杨林孙伟电子工业出版社
[2]数据库系统概论王珊，萨师煊高等教育出版社
[3]数据库原理及应用钱学忠北京邮电大学出版社
[4]数据库应用程序设计教程周山芙，黄京莲清华大学出版社
1.5相关文档（RelatedDocuments）
[1]火车售票系统文档
1.6版本更新记录（VersionUpdatedRecord）
版本号
创建者
创建日期
维护者
维护日期
维护记录
V1.0
杨聪聪
2010/11/02
—
—
—
V1.0.1
杨聪聪
2011/4/21
杨聪聪
2.项目概述及架构（ProjectSummaryandFramework）
2.1项目概述（ProjectSummary）
该项目目的在于设计一个具有订票、售票、以及退票的火车售票系统。
本火车售票系统根据SQL数据库设计，Delphi程序设计原理创建能是售票员以及管理员根据顾客需求进行车票预订、车票查询、以及退票功能，管理员可以根据情况进行售票员进行管理，进行售票员添加、删除、修改，对车票信息进行添加、删除、修改以及对列车的添加、删除、修改等功能。
该系统能够对操作员的操作做出快速反应，具有较强的健壮性，不会因为操作员的错误操作而使系统以及数据库产生错误。
2.2项目架构（ProjectFramework）
该项目属于C/S结构运行于Windows2000及以上版本
3.客户群分析（ClientAnalysis）
3.1客户群定位（ClientOrientation）
该系统可以应用于各城市大中小型火车站、汽车站、地铁站等售票点，使用本系统的主要为车站售票员以及管理员是素质比较高的技术人员，目前全国经济高速发展带动全国交通行业迅猛发展，从而给本系统有很大的发展空间。
3.2当前客户群分析（CurrentClientAnalysis）
该系统的当前用户主要作为为中小城市车站的售票系统，用户主要为站内售票员和站内管理员，用户大多有较强多的专业素质能容易的熟悉系统操作过程。
用户对系统有较好的反应表明本系统有较大的发展空间，我们也在不懈的为开发更高效更优秀的产品努力。
3.3潜在客户群分析（LatencyClientAnalysis）
由于本产品有良好的市场反应以及我们一直努力引进技术加强自我文化修养使我们的产品有良好的市场前景。
本系统的潜在用户主要为不断发展起来的中小型城市新建的车站和大型城市售票系统的更新。
4.项目功能（ProjectFunction）
由于售票系统的特性本系统主要使用网络功能版。
编号
功能名称
功能描述
输入内容
输出内容
1
车票预订
根据客户要求预订车票
始发站和终点站或者车次和票数
车票数，金额
2
售票系统
根据客户要求出售车票
始发站和终点站或者车次和票数
金额
3
退票系统
根据客户要求退票
车票号，车票数
应退金额
4
车票查询系统
根据客户要求查询车票
始发站和终点站或者车次和票数
车票数，票价
5
车票修改系统
由管理员输入修改信息进行修改
车次，票数
操作成功与否
6
售票员修改
根据管理员输入修改售票员信息或添加或删除售票员
售票员工作号（修改/删除）售票员工作号，姓名（添加）
操作成功与否
5.项目性能（ProjectPerformance）
5.1响应时间（ResponseTime）
5.2处理速度（DisposalSpeed）
5.3最大终端负载（TheHighestTerminalLoad）
6.项目接口（ProjectInterface）
6.1金融接口（FinanceInterface）
金融接口如下表所示
金融接口列表
编号
接口名称
接口规范
接口标准
入口参数
出口参数
传输频率
1
2
6.2政府接口（GovernmentInterface）
政府接口列表如下表所示
政府接口列表
编号
接口名称
接口规范
接口标准
入口参数
出口参数
传输频率
6.3互联网接口（InternetInterface）
互联网接口列表如下图所示
互联网接口列表
编号
接口名称
接口规范
接口标准
入口参数
出口参数
传输频率
7.投入产品分析（AnalysisOftheDevotionandtheOutput）
7.1人力资源投入（FacilityDevotion）
人力资源投入如下表所示
人力资源投入
阶段名称
需求岗位
需求人数
工作量（人/月）
到岗日期
需求分析
分析师
概要设计
设计师
详细设计
设计师/高级程序员
编码
程序员
测试
测试员
包装与发布
包装师
总人数：
总工作量（人/月）：
7.2设备资源投入（FacilityDevotion）
设备资源投入如下表所示
设备资源投入
设备名称
规格型号
数量
单价（元）
金额（元）
到位日期
7.3其他经费资源投入（OtherOutlayDevotion）
其他经费资源投入如下表所示
其他经费资源投入
开支项目
开支金额（元）
支付日期
支付金额（现金/支票）
备注
项目总投入（人力费用+设备费用+其他经费资源投入）经费（元）：
7.4产出分析（OutputAnalysis）
产出分析如下表
产出分析
单机版
单机版数量
C/S版单价（元）
C/S版数量
B/S版单价（元）
B/S版数量
年产出合计金额（元）
第1年
第2年
第3年
8.开发计划（DevelopmentScheme）
8.1进度计划（PlanScheme）
开发进度计划表如下所示
开发进度计划表
阶段名称
需求分析
概要设计
详细设计
编码
测试
包装与发布
第1周进度
-----------
第2周进度
------------
第3周进度
-----------
第4周进度
------------
第5周进度
--------
……
8.2评审计划（ReviewScheme）
各里程碑的评审计划如下表
评审计划
阶段名称
评审日期
评审地点
主持人
参加人
应交文档
需求分析
概要设计
详细设计
测试报告
包装
9案例分析（CasesAnalysis）
根据用户需求设计售票系统。
10.风险分析（RiskAnalysis）
10.1需求风险（RiskofRequirement）
对于售票系统要随着交通运输部门的变化而随时进行更新因此需要开发人员经常与客户进行交互随时对产品进行更新。
基于交通运输部门的特性开发人员应随时主动与用户联系对产品进行更新保持系统的性能最优性。
10.2政策风险（RiskofPolicy）
由于国家经济迅猛发展国家运输部门也在迅速发展，国家以及行业内部发展现状可以预见近几年我国运输行业的发展前景。
我们要设计的系统为能够跟的上时代发展潮流的能够易于升级易于更新的系统。
10.3资源风险（RiskofResource）
售票系统是针对各城市列车及汽车等的售票系统，相对来说比较复杂，会花费较大的人力以及物力资源。
开发组会花较多的人力以及财力于市场研发，数据收集，软件开发，软件维护及管理。
在资金投入方面会存在困难，对此我们会努力克服以及希望客户会给予我们支持以使软件的开发能够顺利的进行。
10.4技术风险（RiskofTechnology）
该系统采用delphi程序设计语言，使用sqlserver设计数据库以及采用世界上经典的软件设计流程。
系统出现技术风险的可能性较小，对于可能出现的风险我们的团队以设计好相应的解决办法，可使用户安全使用本系统。
10.5技能风险（RiskofSkill）
我们的团队都是有较好的知识储备，丰富的实践经验的专业人才，并且我们的队员会定期学习世界领先技术并能够熟练掌握。
根据以往的经验我们能够顺利的完成一个符合客户要求的系统。
在系统设计期间我们任然会投入大量精力于学习先进知识和技术争取设计出最优的最能使客户满足的并且有最高安全性的系统。
随着经济的迅速发展和旅游业务量的提高，以上的业务操作越来越不适应市场的发展，随之会引出一系列的问题：
1）票额采用以往记录和凭经验来进行分配，缺少科学性，增大各售票点票务调度的复杂性，导致后果是：
某些售票点没有票，而一些售票点却有大量的剩余票。
这样，严重影响公司的业务。
2）各销售点由于采用传统的通讯方式，时效性很难保证，容易导致有些乘客买到票却没车坐，而不得不等下一班车次，这样，大大降低了乘客对的满意度，造成客源的流失。
3）由于没有实行信息化，公司领导无法对历史数据进行统计和分析，造成公司发展决策的失误，阻碍着公司的进一步发展和腾飞。
因此，的票务管理制度、信息联络和沟通方式必须进行信息化改造，以适应日益激烈的市场竞争。
2《软件项目投标书》
前言
感谢汽车服务系统有限公司给予XXX有限公司一个提供解决方案的机会。
XXX有限公司参加一系列的车站电子售票系统的建设，对客运业务和客票系统的建设有一定的了解，深知“汽车服务有限公司客票票务管理系统”（以下简称“客票票务管理系统”）对汽车服务有限公司客运业务的开展、业务安全性的提高（防欺诈）、服务质量的改善，将起到积极的作用，同时也认识到系统建设中会遇到的复杂情况、主机平台不一致带来的系统建设的难度大的问题。
作为一个软件开发商，XXX有限公司一直把为用户提供用户应用的解决方案作为自己的任务，成功地位烟草、寻呼、燃气、村管、电力行业的多种应用提供一揽子解决方案（TotalSolution）。
“客票票务管理系统”中解决方案的重要性要超过简单的售票活动的重要性。
希望XXX有限公司本次提出的解决方案的初步想法能够对建设有所帮助。
最后，相信咋领导的关心和业务骨干的帮助下，“客票票务管理系统”一定会取得圆满成功！
预祝“客票票务管理系统”圆满成功。
1.项目概况
该项目是为各城市设计火车及汽车售票系统，要求系统的功能包括售票、车票查询、退票、车票管理、列车管理、以及人员管理等。
要求系统有较高的数据处理速度，较高的安全性，以及能够对根据需要可以对系统进行更新升级
目前，票务销售的主要业务操作是：
1、在多处设置销售点，各销售点之间的票额分配采用固定分配原则：
根据以往的销售情况对销售量大的多点分配票数。
2、各售票点的票务情况通过电话和传真进行联络和沟通。
2.总体设计方案
2.1主机平台的选型原则
主机是Browser/Server技术实现中的核心设备，服务器本身的性能直接影响整个系统的整体表现。
应站在整个性能要求的角度对服务器进行客观的技术比较和评测，在相同投资的情况下，选择性能最优，开放性最好，技术可靠的产品，总的来说，在选择机器时，应考虑如下几点：
先进性
开放性（是否符合国际标准）
性能价格比
就一般而言，从具体的技术层面考虑，我们选择机器时要考虑以下几方面的因素：
CPU的处理速度
cache（高速缓存）
系统总线
内存的容量
I/O能力等因素
2.2主机系统配置方案说明
“列车售票系统”的建设目的是：
以先进成熟的计算机WEB技术为主要手段，建成一个票务管理中心。
本方案以公司的现状及长远规划为主，并在设计中留有余地。
下面，就系统的配置部分给予综合评述。
系统主机的选择
考虑到目前情况和未来的发展，我们建议使用itelPⅢ650型号。
主机外存的确定
“列车售票系统”要求按照行业系统的规范来建设，不仅要求提供基础资料数据，而且要保存历史资料和相关统计数据，根据初步估算，系统要求数据数据存储量应不是很大，因此在本方案中，建议硬盘的容量为30GB。
主机内存的确定
根据以往的经验，列车售票中心系统主机内存需求：
NT操作系统、MicrosoftSQLServer7.0数据库系统，中心服务器将面对全系统的用户请求，而且中心数据库还要进行复杂的统计查询工作，因此系统对内存的要求将会很高，我们建议主机内存采用至少128MB，考虑到公司以后的发展和系统的扩充，最好是256MB。
总体框架
在该方案中网站系统应用平台由Windows系统构成。
前段托管于邮电部门，主要任务是向internet发布网站信息，并提供智能化的信息查询/检索/搜集、实时组织网站结构、保护数据和向后通信等功能：
后端使用基于windowsNT的内部局域网管理模式，搭建与办公地点，主要负责页面的生成与网站页面模块的管理、网站智能调节和控制、数据统计分析、电子信箱管理以及向前通信与控制等功能。
两个系统平台之间可由租用的DDN连接，开发程序使用TCP/IP协议或专用协议进行网络通信。
网站的总体框架如图所示
操作系统
网站可在小型机上采用WindowsNTServer操作系统，负责网站前端网页和数据库的组织和发布工作。
Windows2000则担当局域网服务器，可系统管理LAN、WAN等网络，具有群集、对象代理、交易处理、信息排序及强化的处理器。
数据库平台
考虑到网站后台编辑系统的灵活性和前台发布的实时性、可靠性的要求，数据库平台运用WindowsNT的网络通信功能和同步镜像能力。
采用MicrosoftSQLServer管理网站数据库和管理内部局域网数据库。
系统功能
功能结构图见下图：
需求分析
31需求设计
进行数据库设计首先必须准确了解与分析用户需求（包括数据与处理）。
需求分析是整个设计过程的基础。
31.1需求分析阶段的目标
充分了解客户的需求，以及整个预定业务的流程，仔细分析各个子系统，做好各个子系统之间数据如何传送等问题。
3.1.2任务
主要从处理对象、功能分析和安全性以及完整性三个方面去开展研究。
3.1.2.1处理对象分析
车票预定系统主要是针对售票员而言的。
总的来讲，售票系统要处理的对象就是客户信息和系统信息。
细分后就是订票信息、退票信息、查询信息以及有关部门的通缉信息。
对每个信息都有相应的数据，个信息之间数据都存在一定的关系。
就售票信息涉及数据说明如下：
列车号、售票员姓名、售票员工作证号（PassengerID）、售票数等等。
3.1.2.2具体功能分析
列车售票系统有三个子系统组成：
售票系统、查询系统和退票系统，分别对应了售票功能、退票功能和查询功能以及管理员对车票数目的修改。
售票功能中要有对所售出车票数量的修改并打印车票；退票功能实现比较简单，只要修改列车的车票数量并退还乘客票面金额的80%；查票功能设计起来比较简单，但它的功能十分强大，以后对不同的查询需求都要有相应的处理结果，对此阶段没有更进一步的研究，具体功能实现还有待完善。
3.1.2.2安全性和完整性要求分析
为了售票信息不会出现重大差错，对售票员以及车票信息的修改只能由管理员完成，因此售票员有管理员与普通员工两个权限。
整个列车售票系统的数据是共享的。
然而，从系统开发的角度上看，共享会给设计和调试带来困难。
因此，应该提供灵活的配置，使各个分系统能够独立运行，而通过人工干预的手段进行系统数据的交换。
这样，也能提供系统的强壮性，对安全性也有一定的帮助。
由于系统的数据是共享的，在不同的售票地点，车票是共享数据，所以如何保证这些数据的一致性，是系统必须解决的问题。
要解决这一问题，要有一定的人员维护数据的一致性，在数据录入处控制数据的去向，并且要求对数据库的数据完整性进行严格的约束。
对于输入的数据，要为其定义完整性规则，如果不能符合完整性约束，系统应该拒绝该数据。
3.1.3需求分析阶段阶段成果
3.1.3.1业务流程图
业务流程图：
3.1.3.2数据字典
（1）数据项：
列车：
数据项
数据类型
宽度
与其他想的逻辑关系
可否为空值
是否为主（P）/外（F）码
列车号
Char
10
no
P
始发站
Char
10
no
F
终点站
Char
10
no
F
发时
Char
6
no
到时
Char
6
no
票数
Int
no
车票：
数据项
数据类型
宽度
与其他想的逻辑关系
可否为空值
是否为主（P）/外（F）码
车票号
Char
10
no
P
发站
Char
10
no
F
到站
Char
10
no
F
发时
Char
6
no
到时
Char
6
no
票价
Money
no
列车号
Char
10
no
F
售票员
数据项
数据类型
宽度
与其他想的逻辑关系
可否为空值
是否为主（P）/外（F）码
工作证号
Char
10
no
P
姓名
Char
10
no
密码
Char
10
no
车站名
Char
10
no
F
权限
Char
10
no
车站：
数据项
数据类型
宽度
与其他想的逻辑关系
可否为空值
是否为主（P）/外（F）码
车站名
Char
10
no
P
售票：
数据项
数据类型
宽度
与其他想的逻辑关系
可否为空值
是否为主（P）/外（F）码
工作证号
Char
10
no
P、F
车票号
Char
10
no
P、F
经过：
数据项
数据类型
宽度
与其他想的逻辑关系
可否为空值
是否为主（P）/外（F）码
列车号
Char
10
no
P、F
车站名
Char
10
no
P、F
到时
Char
6
no
开时
Char
6
no
3.1.3.4处理过程和处理逻辑
（1）查询处理
名称：
车票查询
输入：
发站、到站
输出：
查询结果
处理：
在所涉及的表中查询所需记录
（2）退票处理
名称：
退票
输入：
车票号
输出：
应退金额
处理：
如果退票成功，相应的数据进行更改
（3）售票处理
名称：
售票
输入：
车票号、票数
输出：
所需金额
处理：
如果退票成功，相应的数据进行更改
（4）管理处理
名称：
管理
输入：
工作证号、姓名、密码、所属车站名
处理：
如果退票成功，相应的数据进行更改
3.2概念设计
在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一DBMS实现这些需求。
因此，概念设计也是数据库设计的一个关键点。
这一阶段的目的在于将需求分析阶段得到的信息转化为概念信息，通常用E-R图来实现，此阶段实现起来有点难度，对问题的分析比较抽象。
3.2.1系统E-R图
（1）车票—售票员
（2）列车—车票
（3）列车—车站
（4）售票员—车站
（5）合并后的E——R图
3.2.2实体属性及联系属性
实体与联系的属性如下：
说明：
“列车号”表示主码，“车站名”表示外码，“姓名”表示一般属性
列车（列车号，始发站，终点站，发时，到时，票数）
车票（车票号，发站，到站，发时，到时，票价，列车号）
售票员（工作证号，姓名，密码，车站名）
车站（车站名）
售票（车票号，售票员工作证号）
经过（列车号，车站名，到时，开时）
3.3逻辑设计
概念设计完成后，获得的是各个实体之间的抽象联系，要将它与具体的DBMS向结合，则必须要将E-R图转化为具体的数据模型，这就是逻辑设计的目标。
其任务就是转化为什么样的数据模型，以及如何转化的完善些，对转化结果进行更进一步的优化。
3.3.1E-R图转化为关系模型
售票系统设计涉及“列车”、“车票”、“售票员”、“车站”四个实体。
实体列车有列车号、始发站、终点站、发时、到时、票数属性。
实体车票有车票号、发站，到站、发时、到时、票价属性。
售票员有工作证号、姓名、密码、属性。
车站有车站名属性。
其中一辆列车可以对应多张车票，一张车票只能对应一辆列车即列车与车票属于一对多关系。
一辆列车可以经过多个车站，一个车站也有多辆列车经过即列车与车站属于多对多关系。
一种车票可以由多名售票员售出，一名售票员也可以售出多种车票，即售票员与车票之间是多对多关系。
根据实体之间的连系得出Ｅ——Ｒ图。
根据设计的逻辑关系建立数据库的关系模式：
一个实体对应一个关系模式，一对多的连系将一方的码加入到多方的关系模式中作为外码，多对多的连系把连系独立建立关系两端实体码的组合作为关系的码实体的码作为外码。
则可得关系模式：
列车（列车号，始发站，终点站，发时，到时，票数）；
车票（车票号，发站，到站，发时，到时，票价，列车号）；
售票员（工作证号，姓名，密码，车站名）；
车站（车站名）；
售票（车票号，售票员工作号）；
经过（列车号，车站名，到时，开时）；
3.3.2数据库模式定义
（1）列车关系表
列名
数据类型
允许空
列车号
Char（10）
否
始发站
Char（10）
否
终点站
Char（10）
否
发时
C
升级会员 