课程设计报告软件工程完稿.docx
《课程设计报告软件工程完稿.docx》由会员分享，可在线阅读，更多相关《课程设计报告软件工程完稿.docx（39页珍藏版）》请在冰豆网上搜索。
课程设计报告软件工程完稿
课程设计报告
（2010--2011年度第二学期）
名称：
软件工程课程设计
题目:
火车票订购管理系统
院系：
计算机系
班级：
学号：
学生姓名：
指导教师：
宋雨，陈晴，王艳
设计周数：
2周
成绩：
日期：
2011年6月27日
《软件工程》课程设计
任务书
一、目的、要求
通过该课程设计要使学生树立起强烈的工程化意识，用工程化思想和方法开发软件。
切实体会出用软件工程的方法开发系统与一般程序设计方法的不同之处，学生在对所开发的系统进行软件计划、需求分析、设计的基础上，实现并测试实际开发的系统。
通过一系列规范化软件文档的编写和系统实现，使学生具备实际软件项目分析、设计、实现和测试的基本能力。
二、主要内容
要求学生掌握软件工程的基本概念、基本方法和基本原理，为将来从事软件的研发和管理奠定基础。
每个学生选择一个小型软件项目（内容参照《计算机综合实践指导》，宋雨等编著，清华大学出版社出版），按照软件工程的生命周期，完成软件计划、需求分析、软件设计、编码实现、软件测试及软件维护等软件工程工作，并按要求编写出相应的文档。
具体的方法可以选用传统的软件工程方法或者面向对象的方法，开发环境和工具不限。
三、进度计划
序号
设计（实验）内容
完成时间
备注
1
软件计划、软件需求分析、软件设计，制定出软件测试计划，软件测试用例
第1周
要求上机前做好充分的文档准备
2
各模块录入、编码、编译及单元测试
第2周的第1、2天
3
联调及整体测试，
第2周的第3、4天
4
验收，学生讲解、演示、回答问题
第2周的第5天
四、设计成果要求
1．至少提交4个文档,包括软件计划、软件需求规格说明书、软件设计说明书、软件测试计划，要求文档格式规范、逻辑性强（可参考《计算机综合实践指导》中给出的要求及格式）、图表规范；
2．独自实现了系统的某些功能，基本达到了要求的性能，经过了测试，基本能运行。
五、考核方式
（1）提交的文档规范，工作量大，文档逻辑性强、正确，按《计算机综合实践指导》标准考核（附《软件工程课程设计》实验报告评分表）占60%
（2）系统验收、讲解、答辩占25%
（3）考勤占15%
学生姓名：
指导教师：
2011年6月27日
《软件工程课程设计》实验报告评分表
姓名
李强
专业班级
软件0802
学号
2
题目
火车票订购管理系统
标准
分数
得分（√）
标准
分数
得分（√）
标准
分数
得分（√）
报告规范，符合要求
20
报告较规范，基本符合要求
17
报告不规范，不符合要求
11
10
16
9
8
19
15
7
6
14
5
4
18
13
3
2
12
1
0
工作量大，报告完整
20
工作量适中，报告较完整
17
工作量较小，报告不完整
14
19
16
13
18
15
12
文档逻辑性强、正确，语言流畅
20
文档逻辑性较强，无明显错误，文字表述较流畅
16
文档有逻辑性，有明显错误，语言表述不顺畅
12
11
19
15
10
9
18
14
8
7
17
13
6
5
实验报告成绩
评分教师签字
一、课程设计的目的与要求
1.课程设计目的
软件工程课程设计是学习软件工程课程后所进行的实践环节，目的是培养学生用工程化的思想和标准文档化的思想进行软件开发。
本次课程设计通过开发一个小型实用的软件系统，亲身体验软件生命周期中的各个环节，以加深对软件工程课程的深入理解、锻炼独立分析、解决问题的能力。
2.课程设计要求
2.1课程设计准备
1）复习软件工程课程的主要内容，熟练掌握软件生命周期的理论以及各阶段的基本概念。
2）明确可行性分析、需求分析、设计、测试等阶段的基本任务和基本方法。
3）熟练运用规范化的描述方法和文档，描述软件开发的各个阶段。
4）熟悉开发环境和开发工具。
2.2内容要求
1）对所设计和实现的系统进行可行性分析，提交可行性分析报告；
2）对系统进行需求分析，可以选择传统的分析方法或者面向对象的分析方法，提交软件需求规格说明书（SRS）；
3）在SRS的基础上进行软件的概要设计和详细设计，提交软件设计文档；
4）遵循上述文档的要求，实现软件；
5）对所实现系统进行软件测试，完成软件测试报告。
二、设计正文
1.可行性分析报告
1.1项目简介
1.1.1项目目标
火车订票管理系统最终可完成订票、退票、打印以及查询车次、发站和到站时间、票价、票源情况等功能。
游客可以进行查询车票，而订票只能登陆才能进行，游客可以进行登陆，注册账户，登陆的用户可以进行查询，预定票，退票。
根据日常生活的实际情况和生活经历，这里规定了票的种类包括软卧、硬卧、软席、硬席、站票等，而且根据乘车人群的不同将车票分成学生票、儿童票、现役军人票、铁路职工票等，依据不同乘客种类，对相应的票价进行调整，具体方案为半价票、1/3票和免费票，并且根据节假日对某些车次票价进行上调和淡季下调等功能操作。
1.1.2系统的简要描述，主要功能
在用用户登陆情况下，可在本火车订票管理系统完成订票、退票、打印以及查询车次、发站和到站时间、票价、票源情况等功能。
用户登陆界面需要用户输入用户名和密码，点击确定进入操作界面，但用户名和密码必须是数据库中存在的信息。
游客可以进行注册用户。
在本操作页面，用户可以根据目的地、乘车时间等信息查看相关的车票信息，包括发车时间、到站时间、车票种类等，也可以在本页面完成订制火车票的操作，包括可以选择所有的车票关键字，确认车票信息后点击订票后，如果所填信息正确无误且车票在数据库中（未卖完）便显示“订票成功”对话框，如果输入有误或是车票已经售完则提示相应的对话框。
同样，也可以在本环节进行退票业务，点击左下角的退票按钮后便进入了该功能操作页面，这里必须正确填写所退车票的所有信息，点击确认按钮后显示当前依然存在的订单。
完成用户功能后点击“关闭”退出本系统。
1.2对现有系统的分析
1.2.1处理流程和数据流程
游客
时间
查询
地点
失败
选择
查询
车次
登录
车次
地点
时间
成功
订票
选择
订票
显示提示
乘客种类
确定
座位类型
退票
显示票价
选择订单
退出系统
1.2.2对现有系统的其他说明
由于本系统功能比较简单，但完全满足实验要求，所以不涉及太多维护方面的操作，系统的操作主要由用户和管理员完成，在装有MicrosoftVisualStudio2010版本以上的电脑上均能运行。
相对一个完整的、具有超强使用性的同类系统来说，本系统的功能有较大的差距，局限性也较大，比如由于时间关系未能实现用户注册功能，而且对车票的保护和统计方面也有不合理之处，但依旧能够实现实验内容要求。
1.3技术可行性分析
根据实验要求，本系统要完成订票、退票以及查询车次、发站和到站时间、票价、票源情况等功能且所有功能均是在用户登陆情况下实现的以及对系统功能的理解，对所有的操作都要求有结果显示，不论对与错，但通过对其分析可知要实现本系统相关功能，并没有太大的难处，在技术上完全可以达到。
1.4经济可行性分析
由于本系统操作较为简单以及其用途单一，不存在经济方面的因素，所以这里就不再涉及经济可行性。
1.5社会因素可行性分析
1.5.1法律因素
由于本系统完全有本人独立完成，未涉及抄袭、重用等手段，完全没有触犯任何法律。
1.5.2用户使用可行性
数据库中初始设置的用户均可使用本系统，而且可实现本系统承诺的所有功能。
1.6可供选择的方案
我们可以从网上获取火车站点的web服务，这样可以更全的去了解每趟车的情况。
软件需求规格说明书（SRS）
1.7需求概述
1）给出软件需求的摘要和简单描述
在用户登陆情况下，要求火车订票管理系统最终可完成订票、退票以及查询车次、发站和到站时间、票价、票源情况等功能。
规定了票的种类包括包厢、软卧、硬卧、软席、硬席、站票等，而且根据乘车人群的不同将车票分成学生票、儿童票、现役军人票、铁路职工票等，依据不同乘客种类，对相应的票价进行调整，具体方案为半价票、1/3票和免费票。
2）运行环境
MicrosoftVisualStudio2010及以上版本的计算机
1.8功能需求
图2.2.1系统用例图
图2.2.2管理员时序图
图2.2.3退票时序图
图2.2.4订票时序图
1.9数据描述
图2.3.1类图
1.10性能需求
1）数据精确度
由于系统本身的特性决定了本系统的数据精确度较高，例如：
车票的数量和车票上的座位等信息均正确无误。
2）时间特性
时效性较好，数据更新及时，例如：
当一个用户订购车票后，数据库中的相关车票的信息及时更新，不会影响之后用户的操作，而且当用户退订车票的时间已经超过所退车票的发车时间时，系统会提示对话框，提示列车已开，无法退票。
3）适应性
由于时间以及实验要求等客观因素，与同类实用系统相比，本系统的适用性较差。
但依旧可以满足实验要求。
1.11运行需求
1）用户界面（见附录）
2）硬件接口
3）软件接口
4）故障处理：
当用户输入错误时，系统会有相应的错误提示。
（见附录）
1.12其它需求
实验独立在一周内完成，在尽可能满足实验内容要求的基础上，可以加入自己的创意元素，使系统在功能、美观、实用性等方面达到最佳的效果。
用指定软件绘制类图、数据流图等系统相关图。
2.软件设计说明书
2.1软件模块结构图
时间
始发站/终点站
用户退票
用户定票
火车票预购管理系统
用户登陆
车票查询
票价/座位
2.2文件结构和全局数据
1）数据库设计/外部文件描述：
包括数据库的逻辑设计和外部文件的逻辑设计。
管理员表Administrator
字段名
字段类型
长度
描述
含义
用户名
nchar（10）
10
不允许为空，主键
管理员用户名
密码
nchar（10）
10
管理员密码
剩余票表Tickets
字段名
字段类型
长度
描述
含义
终点站
varchar（50）
50
不允许为空
终点站
票种
nchar（10）
10
不允许为空
包厢、软席、硬席、软卧、硬卧、站票
座位
nchar（10）
10
不允许为空，主键
座位号
票价
nchar（10）
10
不允许为空
此票价为基本票价，不随乘客种类而改变
发车时间
varchar（50）
50
不允许为空
格式“时：
分”24小时制
车次
varchar（50）
50
不允许为空，主键
车次
本站
nchar（10）
10
不允许为空
初始为保定
到站时间
varchar（50）
50
不允许为空
格式“时：
分”24小时制
售出票表
字段名称
字段类型
长度
描述
含义
车次
varchar（50）
50
不允许为空，主键
车次
乘客种类
nchar（10）
10
不允许为空
学生、儿童、现役军人、工人
终点站
varchar（50）
50
不允许为空
终点站
本站
nchar（10）
10
不允许为空
统一为保定
发车时间
varchar（50）
50
不允许为空
发车时间
到站时间
varchar（50）
50
不允许为空
到站时间
票种
nchar（10）
10
不允许为空
包厢、软卧、硬卧、软席、硬席、站票
原价
nchar（10）
10
不允许为空
基本价格，随票种不同而不同
座位
nchar（50）
50
不允许为空，主键
座位号
现价
nchar（10）
10
不允许为空
随乘客种类不同而改变
2）全局数据：
由于系统性质问题，无全局数据。
2.3模块描述
2.3.1用户登陆模块描述
1）功能：
为系统限制操作用户类型，增加系统安全稳定性。
2）接口：
登陆成功后便可享用系统功能。
3）数据：
用户名、密码（均为string类型）
4）处理：
流程处理如图3.3.1所示：
选择功能
输入用户名及密码
登陆成功
错误
Administrator
2.3.2查询功能模块描述
1）功能：
查询剩余车票所有详细信息。
2）接口：
登陆成功后可实现这部分功能。
3）数据：
发车时间、到站时间（string类型，“时：
分”形势，24H），其他均为string类型。
4）处理：
车票
查询
显示车票信息
2.3.3
数据库跟新
输出订购车票信息
输出车票
提示信息
提示信息
否
是否晚点
是
否
是否有余票
输入车票信息
定票模块描述
1）功能：
实现用户定制火车票，并显示相关信息，能够判断输入错误。
2）接口：
登陆成功后可操作该内容。
3）数据：
string类型
4）处理：
2.3.4
输入
否
更新数据库
否
检验时候已过发车时间
输入车票信息
退票模块描述
1）功能：
实现用户退订火车票功能，跟新数据库信息。
2）接口：
登陆后可实现。
3）数据：
string类型
4）处理：
是
是
提示信息
提示信息
3.软件测试报告
3.1测试范围
测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。
成功的测试在于发现了迄今尚未发现的缺陷。
所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。
由于本系统较为简单，在编程过程中已经将可能出现的问题进行了有效的解决，所以期望的结果是本系统不会发生任何漏洞。
正规的测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。
3.2测试计划
表4.2.1测试计划安排表
阶段
历时时间（h）
内容
备注
第一阶段
1
单元测试
无
第二阶段
2
集成测试
无
第三阶段
0.5
确认测试
无
第四阶段
0
无
不适合此处
3.2.1测试阶段
1）第一阶段是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
这一阶段对登录、订票、查看票务信息、退票四个模块进行了测试，主要对其正常情况下的功能实现和异常情况下的处理进行测试。
例如：
订票时，当输入的信息无误且有余票时应当显示订票成功，而当输入的信息有错误时应当显示相应的错误提示。
2）第二阶段是集成测试，把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
这一阶段对系统的整个完整的操作进行测试，也就是将第一阶段测试无误的各个模块组合起来，进行整体的测试。
比如当用户输入正确的用户名和密码后系统应当能转到票务操作界面，当输入信息后进行相关的操作系统应该有相应的结果提示本次操作成功或是失败。
例如：
用户登陆后，输入正确的票务信息，点击订票后，如果系统还有票则应该显示“订票成功”。
3）第三阶段是确认测试，是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
这一阶段要尽可能将实验要求的所有系统功能全部实现一次，以便确定系统是否满足需求分析中提到的要求。
4）理论上，第四阶段是系统测试，把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
由于这里本系统没有外部的大环境，所以这里这一阶段省去。
3.2.2测试进度：
由于本系统较为简单，所以不存在测试日程安排的问题，只在程序完成之后便展开测试任务。
测试的顺序和依赖关系也较为简单。
测试的进度、顺序和依赖关系如下图：
退出系统
正确处理
查询票务信息
订购火车票
登陆
继续操作
异常处理
退订火车票
3.3测试项目说明
登陆环节，主要是测试数据库中有信息的用户能否正常登陆，非数据库中的用户登录时是否会出现错误提示；在查询票务信息阶段，主要是测试用户所选择的查询信息是否与数据库中对应的车票信息一样，也就是系统能够根据用户给出的关键字来输出正确的票务信息，当用户输入的信息错误，包括格式错误和类型错误等时，系统是否会有提示；订购车票阶段，主要测试当用户输入的信息无误且车票有余时，用户能否正常订票，当用户订票后是否有相应提示，并且测试数据库中的相关车票数是否有减少，本次操作是否影响了其他车票的相关信息，当用户输入错误时是否有系统提示，提示是否与错误相对应；在退订火车票时，当用户输入正确时能否正常退票，退票后是否有正确提示，数据库中对应的票务信息是否已经更新，本次操作是否影响到了其他票务信息，当用户输入出现错误时系统是否有提示，数据库中的数据是否有变化。
3.3.1单元测试
1）测试目的：
测试各个模块的功能是否能够正确实现。
测试方法和测试软件：
黑盒测试
2）测试用例
测试用例1：
用户名：
张三，密码：
456；预计输出：
转入下一功能界面；
测试用例2：
用户名：
于德儿，密码：
313；预计输出：
提示“用户名或密码错误”；
测试用例3：
车次输入895，时间输入568，点击查询；预计输出：
提示“请输入正确时间”；
测试用例4：
车次输入T220，时间输入16:
30，选择学生，硬座后点击订票；预计输出：
提示“订票成功”；
测试用例5：
点击退票后，在票价一栏中输入ASD，其他正常输入；预计输出：
提示“票价输入有误；”
3.3.2集成测试
1）测试目的：
测试各个模块组合后的功能是否能够正确实现，即系统能否正常运行。
2）测试方法和测试软件：
黑盒测试
测试用例1：
用户名：
张三，密码：
456，车次输入T220，时间输入16:
30，选择学生，硬座后点击订票；预计输出：
提示“订票成功”并显示车票；
测试用例2：
用户名：
王五，密码：
789，直接点击订票；预计输出：
提示“请输入完整信息”；
测试用例3：
用户名：
张三，密码：
456，点击退票后，不输入随便一项内容后点击退票按钮；预计输出：
提示“请输入完整票务信息”；
测试用例4：
用户名：
王五，密码：
789，在目的地中输入“北京西”，点击查询；预计输出：
显示所有目的地是北京的车票信息；
测试用例5：
用户名：
张三，密码：
456，车次输入T220，时间输入，选择学生，硬座后点击订票；预计输出：
提示“请输入正确时间”；
测试用例6：
用户名：
张三，密码：
456，车次输入13:
52，时间输入12:
00，选择学生，硬座后点击订票；预计输出：
提示“请输入正确车次”；
3.3.3确认测试
1）测试目的：
检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
2）测试方法和测试软件：
黑盒测试
测试用例1：
用户名：
张三，密码：
456，车次输入T220，目的地输入北京西，起始站输入保定，选择学生，硬座后点击订票；预计输出：
提示“订票成功”并显示车票；
测试用例2：
用户名：
张三，密码：
456，车次输入T220，点击查询；预计输出：
提示车次为T220的所有车票的信息；
测试用例3：
用户名：
张三，密码：
456，点击退票，车次输入T220，发车时间输入16:
30，到站时间输入17:
30，目的地输入北京西，始发地输入保定，票价输入45.00，座位号输入15车007，票种输入硬席；预计输出：
提示“退票成功”；
测试用例4：
用户名：
张三，密码：
456，车次输入T220，目的地输入北京西，起始站输入保定，选择铁路职工，硬座，下调后点击订票；预计输出：
提示“订票成功”并显示车票；（观察票价变化）
3.4测试分析
本部分将从实测结果数据、与预期结果数据的偏差、该项测试表明的事实、该项测试发现的问题等方面对测试进行分析。
3.4.1第1个阶段的测试分析
表4.4.1单元测试分析表
实测结果数据
与预期结果数据的偏差
该项测试表明的事实
该项测试发现的问题
用户名：
张三，密码：
456
无
数据库中存在用户可正确登录系统
无
用户名：
于德儿，密码：
313
无
数据库中不存在用户不可正确登录系统
无
车次输入895，时间输入568，点击查询
无
时间格式必须为：
XX:
XX
车票上的发车时间与系统当前时间如何比较
车次输入T220，时间输入16:
30，选择学生，硬座后点击订票
无
正常的输入后可实现订票功能
无
点击退票后，在票价一栏中输入ASD，其他正常输入
无
填写退票信息必须准确无误，否则系统不认可
如果同时出现多处填错，系统如何提示错误信息
3.4.2第2个阶段的测试分析
表4.4.2集成测试分析表
实测结果数据
与预期结果数据的偏差
该项测试表明的事实
该项测试发现的问题
用户名：
张三，密码：
456，车次输入T220，时间输入16:
30，选择学生，硬座后点击订票
无
系统可完成订票功能
无
用户名：
张三，密码：
456，点击退票后，不输入随便一项内容后点击退票按钮
无
退票能发现输入错误
如何提示输入错误信息
用户名：
张三，密码：
456，车次输入13:
52，时间输入12:
00，选择学生，硬座后点击订票
无
能发现订票错误
无法判断输入的车次是否客观存在
3.4.3第3个阶段的测试分析
表4.4.3确认测试分析
实测结果数据
与预期结果数据的偏差
该项测试表明的事实
该项测试发现的问题
用户名：
张三，密码：
456，车次输入T220，目的地输入北京西，起始站输入保定，选择学生，硬座后点击订票
无
可实现订票功能
无
：
用户名：
张三，密码：
456，车次输入T220，点击查询
无
可实现查询功能
无
用户名：
张三，密码：
456，点击退票，车次输入T220，发车时间输入16:
30，到站时间输入17:
30，目的地输入北京西，始发地输入保定，票价输入45.00，座位号输入15车007，票种输入硬席
无
可实现退票功能
无
三、课程设计总结或结论
软件工程（SoftwareEngineering，简称为SE）是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。
通过本次课程设计，我深深的体会到了软件工程的“威力”。
本次课程设计一共30个题目，每个课题都有很强的综
升级会员 