基于c#net的公交查询系统设计与实现本科学位论文.docx
《基于c#net的公交查询系统设计与实现本科学位论文.docx》由会员分享，可在线阅读，更多相关《基于c#net的公交查询系统设计与实现本科学位论文.docx（32页珍藏版）》请在冰豆网上搜索。
基于c#net的公交查询系统设计与实现本科学位论文
基于C#.NET的公交查询系统设计与实现
摘要
随着“公交先行,节能减排,低碳生活”概念的提出,使得各大城市的公共交通得到迅速的发展,因此乘客需要实时的查询公交系统的信息以便出行,在此背景下,本文最主要采用vs2010来实现公交查询系统的设计采用SQLServer2008数据库来实现系统所需的数据需求。
在公交查询系统设计过程中考虑用户查询的模块为:
线路查询、站点查询、换乘查询，管理员模块则应该包括对数据增、删、查、改等操作，对于数据库设计应该体现出数据之间明确的联系关系。
关键词：
数据库、vs2010、公交查询、管理员
Abstract
Asthe"busfirst,energyconservationandemissionsreduction,lowcarbonlife"conceptisputforward,makethecitypublictransportationtogetrapiddevelopment,sothepassengersneedtoreal-timeinformationqueryofpublictransportationtotravel,inthiscontext,inthispaper,themainvs2010isusedtorealizethebusquerysystemdesignusingSQLServer2008databasetorealizedatarequirementsrequiredbythesystem.
Atthebusquerysystemdesignconsideringuserquerymoduleis:
intheprocessofroutequery,sitequery,changetothequery,theadministratormoduleshouldincludethedatatoadd,delete,check,change,suchasoperation,forthedatabasedesignshouldembodythedefinitecontactrelationshipbetweendata.
Keywords:
database,vs2010,busquery,administrator
第1章绪论
1.1前言
1.1.1系统开发背景
出行是人类生活的基本活动之一。
城市的快速发展、科技的发展以及环保意识的增强，对城市公共交通的发展趋势的快速性、舒适性、便捷性、环保等方面提出更高要求。
先进的信息技术也促进了公共交通技术的发展，从而为乘客提供了良好的出行条件，并且能够逐渐满足市民出行多样化的交通需求。
为城市的进一步发展提供便捷条件，对于城市公共交通来说，必然要优先发展公交，因此，公共交通的地位也不断得到提升。
【】
2005年以来，中国先后印发了关于优先发展城市公共交通的意见等系列文件正式确立了公交优先发展的战略思想，为优先发展城市公共交通指明了方向，有力推动了中国城市公交事业的发展。
截止2009年底到全国公共汽电车运营线路网总长度28.9万公里,公交专用车道里程达7452公里，10余个城市开通运营快速公交路线，公交运输总量达到780亿人次。
【】
随着城市公交的快速发展和节能减排的理念升入人心，使得人们的出行越来越选择以公交的方式出行,并且由于城市的人口居住以及就业形态的已经形成，协调好公交的换乘、增加交通可达性势在必行。
随着城市的发展，必然带来道路基础设施的扩展，公交线路随之增长，有些城市多达上百条，以至于居民难以掌握大量的公交信息，为出行带来了一定的困扰。
因而，公交查询系统便应运而生。
1.2选题目的与意义
1.2.1选题目的
随着节能减排低碳生活的提出，以及公交先行的理念日渐深入人心，建立一个公交查询系统是公众出行的迫切需要——人们对于出行的要求增多，对公交系统的需求也逐渐的增加，公交的监督电话也方便顾客的监督和查询。
建立完善的公交线路网也是我国对于公共交通的一个长远计划，而在整个公共交通中公交又占有相当大的比重，建立一个公交查询系统则可以为顾客的出行提供很直接、便捷的出行方案。
1.2.2选题意义
贵阳市是贵州省省会，是我国内陆开放城市及西南地区的重要的交通通信枢纽、工业基地、商贸和旅游服务城市，城市道路交通的发展从某种意义上讲可以制约或促进整个城市的发展方向。
【】目前贵阳的公共交通现状如下：
贵阳市区由中心区、小河、龙洞堡、花溪、白云、金阳等地组成，12米以上的道路291.41公里，公交运营车辆截止到2010年12月共计1576辆，市、郊线路150条，车运量达到5.9亿人次，承担了全市约70%的客运量【】。
在这种情况下城市公交的查询系统则可以做到:
1、城市公交查询系统能够最快、最方便的满足人们的出行需要,帮助人们正确的选择公交出行的线路,提高人们的出行速率。
2、城市公交查询系统是智能公交的重要组成部分,智能公交系统是一个整体工程,而公交查询系统则属于智能公交查询系统的软件组成部分。
3、作为省会城市则可以帮助外来人员快速的查询到公交信息，提高人们的出行的效率和城市的综合的地位。
1.3系统开发环境及简介
系统开发环境分为两部分——1.硬件部分、2.软件部分
1.3.1硬件部分
一般电脑配置即可
1.3.2软件部分
软件部分包括SQLServer2008数据库、MicrosoftVisualStudio2010
（一）数据库采用SQLServer2008数据库
数据库可以理解为存储数据的仓库。
他是按照一定的组织方式存储的相互有关的数据的集合，这些数据不仅彼此关联而且可以动态变化。
它具有以下几个特点：
1、数据结构化
2、数据共享
3、数据的独立性
5.数据的一致性与正确性
在数据库中最核心的一部分为DBMS即数据库管理系统他是使用户能够实现数据加工的数据管理系统，为用户提供以下几个功能：
1、建库功能
2、数据的操作功能：
实现对数据的增、删、查、改等功能【】
（二）编程软件采用MicrosoftVisualStudio2010
VisualStudio是Windows平台应用程序的开发环境，它是建立在IDE（统一开发环境）的基础之上，可用于开发多种不同类型的应用程序
第2章
需求分析
2.1需求分析概述
需求分析是软件定义时期的最后一个阶段，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。
需求分析是软件工程中的一个关键过程。
在这个过程中，系统分析员和软件工程师确定顾客的需要。
只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。
2.1.1需求分析的基本任务一个阶段
它的基本任务是准确地回答“系统必须做什么？
”这个问题。
需求分析的任务还不是确定系统怎样完成他的工作，而仅仅是确定系统必须完成那些工作，也就是对目标系统提出完整、准确、清晰、具体的要求【】。
具体说需求分析的任务有以下几个方面：
（一）、确定对系统的综合要求——通常对软件系统有下述几个方面的综合要求：
1、功能需求——这方面的需求制定系统必须提供的服务。
通过需求分析应该划分出系统必须完成的所有功能
2、性能需求——性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间、信息量速率）【】
3、可靠性和可用性需求——可靠性需求定量地指定系统是的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度，例如：
“在任何时候主机或备份机上的机场雷达系统应该至少有一个是可以用的，而且在一个月内在任何一台计算机上盖系统不可以用的时间不能超过总时间的2%。
”【4】
4、出错处理需求
5、接口需求
6、约束
7、逆向需求
8、将来可能提出的要求
（2）分析系统的数据要求
每一个系统在本质上都是处理信息的，系统必须处理的信息与系统得到的信息在很大的程度上决定了系统的“面貌”，因此必须分析系统的数据要求，而分析系统的数据要求通常采用建立数据模型的方法即实体——联系图（2.2节）。
复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
利用数据字典可以全面的定义数据，但是数据字典不够形象直观。
为了提高可理解性，我们可以用层次方框图和Warnier图辅助描绘数据结构。
2.2实体——联系图（E-R图）
2.2.1实体——联系图概述
为了把用户的数据要求清楚、准确的描述出来，系统分析员通常建立一个概念性的数据模型。
概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。
它描述了从用户角度看到的数据，它反映了用户的显示环境，而且与在软件系统中的实现方法无关
2.2.2符号系统
在实体——联系图中包含3种相互关系的信息如表格1所示：
表格1ER图符号
图形
名称
描述
数据对象
数据对象时对软件必须的复合信息的抽象。
所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物（例如，宽度）不是数据对象
属性
数据对象一般具有若干特征，这些特征就称为数据对象的属性，例如：
数据对象“学生”，具有学号、姓名、性别、出生日期和系别等特征，这些就是它的属性。
联系
实体之间可能会有各种关系。
例如，“学生”与“课程”之间有“选课”的关系。
这种实体和实体之间的关系被抽象为联系。
在实体联系图中，联系用联结有关实体的菱形框表示，如图1.9所示。
联系可以是一对一（1:
1），一对多（1:
N）或多对多（M:
N）的，这一点在实体联系图中也应说明。
例如在大学教务管理问题中，“学生”与“课程”是多对多的“选课”联系联系。
【】
2.2.3公交实体——联系图
在本文中的公交E-R图如图21所示：
图21公交E-R图
2.3层次方框图
层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割的元素）。
在本文中的公交查询系统层次方框图如图22所示：
图22层次方框图
2.4数据流图（DFD）
2.4.1数据流图概述
数据流图（DFD）是一种图形化技术，它描绘信息流和数据流从输入移动到输出的过程中所经受的变换。
在数据流图中没有任何具体的物理部件，他只是描绘数据在软件中流动和被处理的逻辑过程。
数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此，他是分析员与用户之间几号的通信工具。
此外数据流图设计时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，因此他也是进行软件设计的很好的出发点。
2.4.2符号系统
数据流图通常包含以下几种符号:
符号
名称
说明
正方形
表示数据的源点或终点
圆角矩形
代表数据的变换处理
开口矩形
代表数据存储
箭头
表示数据流，即特定数据的流动方向
2.4.3画图原则
画图原则：
（1）数据流图上所有图形符号只限于以上四种基本图例
（2）顶层数据流图必须包含4种基本元素；
（3）顶层数据流图上的数据流必须封闭在外部实体之间；
（4）至少有一个数据输入流和一个数据输出流；
（5）在数据流图中必须按层给处理框加编号，该编号表明该加工处；
在那一层以及上下层父图与子图的对应关系；
（6）规定数据流图与他上一层的一个处理对应，两者的输入数据流和输出数据流必须一致，即父图与子图平衡，还应该在数据流图中缴入必要地说明以帮助用户理解；
（7）图上的每个元素都应该有名字，数据流和数据文件名字表明流动的数据是什么，而处理的名字应表明处理做了说明事情。
2.4.4公交DFD图
图23公交DFD图
2.5系统功能模块划分
一个系统可以看成是由多个小模块组成，这些小模块之间应该具有高内聚、低耦合的特点：
耦合：
是对一个软件结构内不同模块之间互联程度的衡量。
而耦合程度取决于模块时间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
耦合包括以下几种：
1、数据耦合2、控制耦合3、特征耦合4、公共耦合。
内聚：
内聚标志着一个模块内各个元素之间的彼此结合程度。
内聚包括以下几种：
1、功能内聚2、顺序内聚3、通信内聚4、过程内聚5、时间内聚6、逻辑内聚7、偶然内聚。
公交查询系统可以看成是由两个大模块组成即：
用户查询模块和管理员模块。
2.5.1用户查询模块
用户查询模块主要供用户使用其主要完成的对公交信息的查询，这些查询包括公交站点、公交线路以及公交站点到站点的额查询（公交换乘插叙）并将查询的结果通过一定的方式显示出来，并且需要制定一个“选择框”以便用户进行模糊查询。
2.5.2管理员模块
管理员在公交查询系统中拥有最高的权限，它能够对公交信息进行增、删、查、改等一系列工作，当然对于管理员模块需要进行身份验证，当正确以后才能进行操作。
第3章
详细设计
3.1系统详细设计
系统的详细设计阶段其根本目标是确定应该怎样具体的实现所要求的系统，也就是经过这个阶段的设计工作，应该得到对系统的准确描述，从而在编码阶段可以把整个描述直接翻译为用vs2010编写的程序代码，在这一阶段不是实现软件的具体代码编写
3.1.1系统总体功能设计
系统功能详细设计主要表述系统的功能架构如图1.3.1所示
图31系统功能架构
3.1.2系统各功能模块详细设计
对于用户模块来说就是完成对信息的查询功能并返回值如图3.1.2.1，对于管理员来说不仅可以查询公交的信息还可以对公交信息进行增、删、查、改等工作如图32、图323所示：
图32功能图图33功能图
3.2.数据库设计
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括数据管理需求和数据操作需求。
【】
数据库设计的好坏,直接影响到系统的功能能否实现,数据操作是否简单。
设计良好的数据库很容易使用,并且能够保护数据的有效性。
而设计不好的数据库虽然能够发挥相当的作用,但是可能会导致数据的无效、错误或者丢失。
【】
3.2.1数据库设计步骤
建立了数据库的步骤：
数据库系统的生存期可划分为：
需求分析、概念结构设计、逻辑结构设计、物
理结构设计、实施和运行维护七个阶段，而需求分析和概念结构设计可以独立于任何数据库管理系统而进行。
逻辑结构设计和物理结构设计与选用的DBMS（databasemanagementsystem）密切相关。
我们通常把前五个阶段称为“数据库的分析和设计阶段”，后两个阶段称为“数据库的实现与运行阶段。
”【】
（1）需求分析：
在这一步需要做的主要工作是收集数据库所有的信息内容和处理要求，并对其进行分析。
（2）概念结构设计：
经过需求分析后，在这个阶段把用户的需求加以解释，并用概念模型（概念模型是现实世界到信息世界的抽象，具有独立于具体的数据库实现的优点，因此它是用户和数据库设计人员之间进行交流的语言。
）表达出来。
（3）逻辑结构设计：
这个阶段的主要任务是利用数据库管理系统所提供的工具将信息世界中的概念模型映射为计算机世界中为数据库管理系统所支持的数据模型，并且将其用数据描述语言表达出来。
（4）物理结构设计：
数据库的物理设计是指对数据库存储结构和存储路径的设计，即将数据库的逻辑模型在实际的物理存储设备上加以实现，从而建立一个具有较好性能的数据库。
【】
（5）数据库实施：
数据库实施和运行维护阶段的主要工作是：
装入数据，投入使用，同时根据数据库运行中所产生的问题以及用户提出的需求不断完善和提高数据库的功能以及性能
3.2.2数据库设计原则
建库原则
在建立数据时应遵循以下几个原则：
（1）组织有序、层次分明。
公交信息查询系统对数据的存取访问需要数据库有序的组织在一起，方便查询使用
（2）最小冗余度原则。
数据库的设计要遵循最小冗余度原则——数据应该尽可能的不重复达到减少数据存储的冗余量，最终节省数据的存储空间——这时因为同一个系统如果包含有大量重复的数据，这不但会浪费大量的存储空间，还会存在潜在的不一致危险，即同一记录在不同文件中可能不一样（如，在一个文件中修改了某一个数据而没在另外的文件中没有修改相应的数据）。
最小冗余度也是数据库的一大优势
（3）数据独立性原则。
数据独立性原则指的是数据的存放应尽可能地与使用它的应用程序相独立。
数据独立性可以分为数据的物理独立与数据的逻辑独立两个方面。
由于有了数据的独立性，数据库系统就可以使用户数据与物理数据完全分开，因此，可以使用户摆脱了繁琐的物理存储细节。
由于用户程序不依赖于物理数据，从而降低用户程序的维护开销。
（4）标准化、规范化原则。
在建立数据库时应该合理规定数据库的名称（例如：
公交站点可以命名为BusStation，公交线路可以命名为BusLine），保证系统数据能够满足应用要求。
（5）系统可靠性、安全、完整性原则。
一个数据库系统的可靠性主要体现在其软硬件故障率小、运行可靠、出了故障时能迅速恢复到可用状态等几个方面。
数据库的安全性是指系统对数据的保护能力，防止非法使用所造成的数据泄密和破坏。
即对系统数据进行控制，使用户可以按照系统规定的规则来访问数据，以防止数据有意或无意地泄露。
数据库的完整性原则是指数据的正确性、有效性以及兼容性。
完整性检查可以将数据控制在有效的范围内，或保证数据之间满足一定的关系。
开发人员通常通过设置各种完整约束条件来解决这一问题。
【】
3.3公交数据库详细设计
公交数据库的设计主要包括了公交的站点数据库设计、公交线路的设计、城市的设计、和其他的一些设计，在统一建立好一个名为“公交数据库”的数据库后分别建立各个数据的分表分别对这些表进行设计
3.3.1公交站点的数据库设计
公交数据站点的设计如图表格2公交站点字段表所示：
表格2公交站点字段表
表名：
BusStation（公交站点）
字段名
数据结构
说明
BusInfoID
Nvarchar（255）
数字对应busInfo表ID
Station
Nvarchar（255）
车站点称，例如：
贵大
StationIndex
Float
车站的序号（人为规定一个方向进行排序）
其实体——联系图（E—R图）如图34实体-联系图所示：
图34实体-联系图
3.3.2公交线路的数据库设计
公交数据线路的设计如图表格3公交线路字段表所示：
表格3公交线路字段表
表名：
BusLine（公交线路）
段名
数据结构
说明
ID
Float
数字（对应BusInfo表中BusLineID）
AreaID
Float
AreaID（对应Area表ID）
LineCode
Nvarchar（255）
公交线路
其实体——联系图（E—R图）如图35实体E-R图所示：
图35实体E-R图
3.3.3公交线路信息数据库设计
公交数据线路信息的设计如表格4公交线路信息字段表所示：
表格4公交线路信息字段表
表名：
BusInfo
字段名
数据结构
说明
ID
Nvarchar（255）
数字对应BusStation表中的BusInfoid
BusLineID
Float
对应BusLine表ID
StartTime
Float
起点首班车时间
EndTime
Float
起点末班车时间
LastStartTime
Float
终点首班车时间
LastEndTime
Float
终点末班车时间
TimeInfo
Nvarchar（255）
首末车时间说明
TicketSystem
Nvarchar（255
票制
Carfare
Nvarchar（255）
全程票价[元]
KM
Nvarchar（255）
线路长度[公里]
OtherInfo
Nvarchar（255）
其他信息
BusInfoIndex
Float
排序
其实体——联系图（E—R图）如图36实体E-R图所示（只包含部分属性）：
图36实体E-R图
3.3.4公交城市信息数据库设计
公交城市数据库主要用于存放不同的城市信息,其公交城市信息数据库设计如表格5城市字段表所示：
表格5城市字段表
表名：
Area（城市）
字段名
数据结构
说明
ID
Float
数字
Province
Nvarchar（255）
省份
City
Nvarchar（255）
城市例如：
贵阳市
City2
Nvarchar（255）
城市短名称例如：
贵阳
Pinyin
Nvarchar（255）
拼音
其实体——联系图（E—R图）如图37实体E-R图所示：
图37实体E-R图
上面的四张实体——联系图通过合并就可以得到公交数据库的完整的实体——联系图（如图21公交E-R图所示）
通过上面的设计我们得到了四张数据库表这四张数据库表为Area.dbo、BusInfo.dbo、BusLine.dbo、BusStation.dbo，利用这四张表可以实现公交数据信息的查询，但是对于管理员来说，这四张表只能够查询而不能够限制用户只进行数据的查询，而不进行数据的增、删、查、改等操作因此还需要建立一张系统管理员验证表（qadmin表）
3.3.5公交管理员信息数据库设计
公交管理员数据库的设计如表格6管理员字段表所示：
表格6管理员字段表
表名：
qadmin
字段名
数据结构
说明
adusers
nchar（50）
存放系统管理员的用户名用于登陆验证
adpwd
nchar（50）
存放系统管理员的登陆密码用于登陆验证
其实体——联系图（E—R图）如图38实体E-R图所示：
图38实体E-R图
此时当系统管理员输入用户名和密码，通过查询与设计的表qadmin中的adusers和adpwd作比较，如果一致则进入系统管理员的增、删、查、改等界面，如果不一致则无法进入到系统界面，从而能实现了管理员功能模块验证功能。
3.4数据库关系图
通过上面的分析我们可以得出数据表Area.dbo、BusInfo.dbo、BusLine.dbo、BusStation.dbo之间存在疑点的关系，我们可将其关系画为如图39关系图所示，通过这张图可以清晰的反应四张数据表之间的对应关系。
图39关系图
第4章
实现
4.1系统界面设计与实现
系统设计是新系统的物理设计阶段。
根据系统分析阶段所确定的新系统的逻辑模型、功能要求，在用户提供的环境条件下，设计出一个能在计算机网络环境上实施的方案，即建立新系统的物理模型。
对于公交查询系统主要涉及两个方面：
1、用户功能模块设计2、系统管理员模块设计,其设计界面如图41系统主界面所示:
图41系统主界面
其中当点击”用户查询模块”后进入用户操作主界面,同理当点击”
升级会员 