公交查询系统的设计与实现Word格式文档下载.docx
《公交查询系统的设计与实现Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《公交查询系统的设计与实现Word格式文档下载.docx（25页珍藏版）》请在冰豆网上搜索。
（2）经济可行性：
从这方面来说，本系统的开发作为课题来说不需要什么经济投入，因此来说也是可行的。
（3）营运可行性:
国内很早就开始应用公交查询系统，我国大部分城市都有公交查询系统。
那么从这方面来说是可行的。
1.2需求分析
手机公交线路查询软件最基本的功能是能够有效的为用户提供查询服务，在最短的时间内给用户一条或多条到达目标地的路径。
整个查询过程中，只有数据信息是依靠服务器同步获取，其余功能均在手机端完成。
在此分别对手机公交线路查询软件的服务器端和客户端做需求分析。
1.2.1系统功能需求
本系统的用户包括用户和管理员两类，其中管理人员对此系统进行数据的修改、删除、查找、添加路线以及发布公交动态等功能。
而用户则可运用本系统合理有效的查询路线、安排行程。
功能规划：
本系统有两大功能：
查询功能以及更新维护功能。
其中查询功能包括站站查询功能、车次查询功能、公交站点车次查询三项基本功能。
功能描述：
a.站站查询：
乘客通过输入起点和终点的站名，那么通过这两个车站的所有车次就会显示出来供乘客选择合适的乘车路线
b.车次查询：
乘客通过输入公交车车次就可以查询出该车次经过的所有站点，乘客可以根据站点来选择自己的乘车路线
c.公交站点车次查询：
这种方案一般针对不城市公交不熟
悉的人，通过输入站点或者车次就可以同时显示站点和车次两种
信息，根据这个就可以选出最佳的乘车方案。
d.更新维护：
管理员负责对公交路线修改和更新，以及系统的维护，同时公布最新的变动信息（包括车次变动和价格变动等）或者有关城市公交的新闻
对性能的一般性规定：
1灵活性：
当要对系统进行添加数据或删除、更新等操作时，可以容易地对系统进行操作，并且不影响系统的正常运行，更不会有任何出错的现象。
2数据精确:
因为此数据为系统内部数据,所以要求不能有误差。
3时间特性:
系统应有即时性,能尽快查询出所需结果
1.2.2服务器端需求分析
服务器作为后台，需要专业人员对服务器操作和维护，一般情况可由非专业人员借助管理软件对服务器进行常规维护。
服务器可以通过数据库同步，为客户端数据库提供数据。
通过仔细分析服务器需求之后，服务器端要完成以下功能：
1、服务器后台管理功能
服务器后台管理是针对数据库进行操作，具有增、删、改、查功能。
2、数据同步功能。
采用Servlet技术，响应客户端请求，返回给客户端一端数据流，该数据流按照Xml语言规范写入数据流。
服务器端功能模块划分如图1.1.1所示。
图1.2.1服务器端功能模块图
1.2.3客户端需求分析
客户端主要是手机，用户无法通过手机对本地数据库进行操作，也无法对服务器数据库操作，管理员可以通过手机浏览器登录到服务器管理员页面对数据库进行操作，可以使用一些功能。
该软件应满足若干要求，比如能够随时掌握公交信息，动态更新最新数据等。
也要考虑作为手机软件可能会出现查询速度慢，数据流量过大，过度依赖服务器等问题。
通过仔细分析用户需求之后，该软件要完成以下功能：
1、查询线路功能
获得线路经过的每个站点信息以及线路的票价信息和发车时间信息。
2、地图查询功能
借助GoogleMap，完成公交查询并显示地图线路。
3、数据更新功能
服务器响应客户端请求返回一段数据流，客户端接收此数据流后，按照Xml语言规范对数据流进行解析，解析后将数据存入客户端数据库。
4、意见反馈功能
通过手机邮件将意见发送到管理员的邮箱。
客户端功能模块划分如图1.1.2所示。
图1.2.2客户端功能模块图
1.2.4开发环境及工具需求分析
服务器端开发环境，以windows7操作系统为开发平台，用Tomcat6.0做为服务器，Mysql5.0作为数据源，JSP作为开发工具，Dreamweaver8.0作为辅助开发工具，运行在一般的PC机上即可。
客户端开发环境，以Android手机操作系统为开发平台，用Android手机操作系统自带的SQLite作为数据源。
Java语言和Xml语言作为开发工具，Eclipse3.5作为辅助开发工具。
整个Android手机操作系统是在AndroidSDK提供的虚拟机中运行，该虚拟机运行在windows7操作系统上，所以客户端的开发是在windows7操作系统上运行的Android操作系统中进行的二次开发。
1.3概要设计
1.3.1开发流程
开发流程如图1.3.1所示。
图1.3.1开发流程图
1.3.2系统数据流图
系统数据流程如图1.3.2所示。
图1.3.2系统数据流图
1.3.3系统整体结构说明
该系统包括前台和后台两部分，主要包括用登陆、站点输入、线路输出、站点修改、线路更新等功能。
系统的整体功能模块图如图1.2.3所示：
图1.3.3整体功能模块图
1.3.4系统功能模块的划分
公交查询系统功能划分模块如下：
1）查询系统模块该模块实现公交查询功能。
可实现按起点－中转站－终点查询查询和按线路查询两种查询方式。
图1.3.4查询系统模块
2）录入系统模块
该模块实现数据的录入、修改、删除功能。
该模块由公交站点管理与公交线路管理两部分组成.详细设计视图如图1.3.5录入系统模块所示：
图1.2.5录入系统模块
3）信息输入输出模块如图1.3.6所示：
图1.3.6信息输出模块
第二章模式设计
2.1C/S模式简介
精简的说：
C/S模式是一种三层结构的系统,第一层在客户机上安装了客户机应用程序,第二层在服务器上安装服务器管理程序，第三层是数据访问层。
在C/S模式的工作过程中,客户机程序发出请求,服务器程序接收并且处理客户机程序提出的请求,然后返回结果。
C/S模式特点：
（1）C/S模式将应用与服务分离,系统具有稳定性和灵活性
（2）C/S模式配备的是点对点的结构模式,适用于局域网,有可靠的安全性
（3）由于客户端实现与服务器端的直接连接,没有中间环节,因此响应速度快
（4）在C/S模式中,作为客户机的计算机都要安装客户机程序,一旦软件系统升每台客户机都要安装客户机程序,系统升级和维护较为复杂发。
2.2B/S模式简介
B/S模式是一种从传统的三层C/S模式发展起来的新的网络结构模式，其本质也是三层结构的C/S模式。
在用户的计算机上安装浏览器软件，在服务器上存放数据并且安装服务应用程序，服务器有WWW服务器和文件服务器等。
用户通过浏览器访问服务器，进行信息浏览、文件传输和电子邮件等服务。
B/S模式特点：
（1）系统开发、维护、升级方便每当服务器应用程序升级时，只要在服务器上升级服务应用程序即可，用户计算机上的浏览器软件不需要修改，系统开发和升级维护方便。
（2）B/S模式具有很强的开放性在B/S模式下，用户通过通用的浏览器进行访问，系统开放性好。
（3）B/S模式的结构易于扩展由于Web的平台无关性，B/S模式的结构可以任意扩展，可以从包含一台服务器和几个用户的小型系统扩展成为拥有成千上万个用户的大型系统。
（4）用户使用方便B/S模式的应用软件都是基于Web浏览器的，而Web浏览器的界面是类似的。
对于无用户交换功能的页面。
用户接触的界面都是一致的，用户使用方便。
2.3B/S-C/S模式
2.3.1B/S-C/S模式定义
B/S-C/S模式是将B/S模式和C/S模式组合而来的，吸取这两种模式的优点，达到互补的作用。
B/S模式和C/S模式都是三层结构，B/S模式第一层是表现层，第二层是业务逻辑层，第三层是数据访问层。
C/S模式三层结构中第一层是客户端与B/S模式中的第一层不一样，其余两层相同。
在B/S模式和C/S模式数据访问过程和业务逻辑处理过程中是在服务器端完成，用户只需接受服务器返回的结果。
在B/S-C/S模式中，一部分数据访问过程和业务逻辑处理过程在客户端完成，另外一部分数据访问过程和业务逻辑处理过程在服务器端完成。
本手机公交线路查询软件一部分功能只要依靠手机本地数据库就可以实现，令外一部分功能需要借助互联网实现。
目前不论是手机硬件还是计算机硬件，更新速度很快，而且硬件的配置水平也越来越高，在硬件条件允许的情况下把一部分业务处理、数据访问的过程放在客户端去完成，那么对服务器的硬件要求就会低一些，甚至一些高性能的PC机就可以作为服务器。
从整个作业量来看，本质上是把作业量往客户端多分摊一部分，降低服务器的作业量，因此，对客户端的硬件要求是比较高的。
B/S-C/S模式结构如图2.3.1所示。
图2.3.1B/S-C/S模式结构图
本软件系统采用B/S-C/S模式，系统框架如图2.3.2所示。
图2.3.2系统框架图
2.3.2B/S-C/S模式特点
B/S-C/S模式在继承了B/S模式和C/S模式的优点之后，还具有以下特点：
（1）可靠性高
1、客户端不必完全依赖于服务器，即便脱离服务器，还有手机数据库的支持，可以继续使用一部分功能。
2、客户端的数据丢失的时候，可以采用数据库同步的方式从服务器获得新的数据信息。
（2）省资源
一部分作业在客户端完成，服务器的访问量和作业量都会减少，省资源，维护起来会更加方便。
第三章数据库设计
3.1数据库结构
服务器数据库为总数据源，每一个客户端都拥有独立的小型数据库。
客户端数据库信息从服务器端同步获得。
服务器的数据库是基于Mysql建立，客户端数据库是基于SQLite建立。
数据库体系结构如图4.1.1所示。
图3.1.1数据库体系结构图
3.2服务器数据库设计：
用户的需求具体体现在对各种信息的提供、保存、更新和查询等方面。
因此，一个满足要求的数据库必须充分满足对各种信息的输入输出需要。
公交查询系统应满足以下信息需求：
●管理员必须先登录系统后台管理才能对系统中线路、站点等信息进行添加、删除、修改等工作。
●普通用户不需进行注册就可以直接查询相关信息。
●一辆公交车经过多个站点。
●每个站点有多辆公交叫信息。
●一辆公交只有一条行驶线路。
●一条线路包括多个站点。
综合上面对网上购物系统数据库的需求分析，考虑到未来功能上的扩展，设计如下的数据项结构：
●管理员信息包括的数据项：
帐号、姓名和密码。
●公交车信息包括的数据项：
线路号、始发时间、末班时间、车辆等级、车辆类型、始发站、终点站。
●站点信息包括的数据项：
站点名称、要经过的线路号。
●线路信息包括的数据项：
线路号、线路中包括的站点号。
通过上面数据库的需求分析可知，该系统的实体有管理员实体、公交车实体、线路实体、站点实体。
管理员实体如图3.2.1所示：
管理员
Name
图3.2.1管理员实体图
公交车实体图如图3.2.2所示：
图3.2.2公交车实体图
线路实体如图3.2.3所示：
LineNum
Note
图3.2.3线路实体图
站点实体图如图3.2.4所示：
图3.2.4站点实体图
各实体间关系的E-R图如图3.2.5所示：
1n
1m
nn
11
mn
nm
图3.2.5各实体间关系E-R图
根据上面的E-R图，本软件服务器端定义的arashmen数据库设计了以下4张表：
站点表：
station（表2）、线路表：
routes（表3）、发车时间表:
departuretime（表4）、票表:
fare（表5）。
本软件服务器数据库所包含的表的描述如表1。
表3.1管理员信息表
数据名称
字段类型
说明
Account
文本
管理员帐号
管理员姓名
PassWord
管理员密码
线路的信息表如表3.2所示：
表3.2线路信息表
LineName
线路名称
BeigenSt
起始站点
EndSt
终止站点
线路信息
公交车的信息表如表3.3所示：
BusNum
公交线路号
始发站
终点站
BusLevel
公交等级
BusState
公交类型
BeigenTime
始发时间
EndTime
末班时间
表3.3公交车信息表
站点的信息表如表3.4所示：
表3.4站点信息表
StName
站点名称
StNote
站点信息
3.3客户端数据库设计：
3.3.1SQLite简介
Android数据库使用的是SQLiteDatabase，我们来简单的介绍下Android平台上的SQLiteDatabase。
SQLite是一款轻型的数据库，是遵守ACID的关联式数据库管理系统，它的设计目标是嵌入式的，而且目前已经在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。
它能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，比如Tcl、PHP、Java等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款世界著名开源的数据库管理系统来讲，它的处理速度比他们都快。
该软件数据库的建立是完全在Android平台上执行Java代码，通过DVM编译来建立的，没有什么辅助工具，由于整个SQLite数据库是非可视化操作，所有对数据库的操作都是通过执行Java代码实现，在完成其查询功能的时候没有使用数据库高级编程，较为麻烦的关节是在如何有机的将客户端数据库整体结构实现出来，实现过程是无可视界面，也没有数据库辅助工具情况下，整个过程很抽象。
且表的设计应尽量简单，不要有错综复杂的关系，每张表都是独立的，不存在任何约束，数据库也是独立数据库，不采用Android特有的可共享数据库。
3.3.2数据库设计
E-R关系如图3.3.1所示。
图3.3.1客户端数据库E-R图
根据上面的E-R图，本软件客户端定义的arashmen数据库中包含以下4张表：
station（表7）、线路表：
routes（表8）、发车时间表:
departuretime（表9）、票表:
fare（表10）。
本软件服务器数据库所包含的表的描述如表6。
表3.6数据库概况表
表名
描述
主要字段
stations（站点表）
保存站点信息
ID，station
routes（线路表）
保存线路信息
ID，RouteName，Content
Departuretime
（发车时间表）
保存首班发车时间
保存末班发车时间
RouteName
FirstDepartureTime,LastDepartureTime
fare（票价信息表）
保存公交线路票价信息
ID，isFixed，FullFare
表3.7站点表
字段名
数据类型
长度
主键/外键
默认值
id
Int
4
PK
ID，自动增长
Station
Varchar
50
表3.8线路表
Char
20
Content
LongText
线路全径
表3.9发车时间表
FK
FirstDepartureTime
Time
首班发车时间
LastDepartureTime
末班发车时间
表3.10票价信息表
isFixedFare
5
是否为分段计费
FullFare
Double
8
全程票价
第四章系统测试
4.1系统测试方案
根据本程序的实际情况，进行了如下测试：
1）输入异常数据或进行异常操作
在主页面中输入与车次无关的站点信息，系统将对所输入的信息与数据库中的信息作比较，如果没有找到相对应的信息，则系统显示为空。
当用户没有输入任何字符的时候，系统会提示用户输入相应的信息，以便查询。
只有符合数据库中的信息，才能进行相应的查找。
2）灾难恢复性测试
由于本系统需要一个数据库作为数据存储的平台，所以当数据库遭到破坏的时候就无法运行，所以管理员在日常的添加、修改和删除前都要进行必要的数据库备份工作。
另外由于本系统是静态网页，所以当管理员进行数据的添加、修改和删除操作后，无法实时地显示被添加、修改和删除操作后的信息。
此时用户如果想获取最新的车次以及站点信息就需要进行手工的网页刷新，这也是静态网页一个弊端之一。
从容错性测试的概念可以看出，容错测试是一种对抗性的测试过程。
要测试软件出现故障时，如何进行故障的转移与恢复有用的数据。
故障转移（Failover）是确保测试对象在出现故障时，能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行。
4.2性能分析
经过这段时间的努力，本软件基本完成了任务要求。
经过测试和分析得到以下结论：
（1）各个界面基本能够运行成功，且界面友好、布局合理、操作简单
（2）系统运行速度较快，系统启动运行时间不超过5min，人机界面交互时间不超过5s
（3）容错能力强，性能优
（4）安全可靠性优化
总结
一个应用程序设计开发的好坏，与设计人员对开发工具的掌握程度息息相关。
根据个人情况，尽量选择了自己较熟悉的开发环境及工具，以便能够顺利的实现系统避免延期。
同时设计的思想，方式在开发前要不断的进行思索和考察，一个好的设计思路是开发出好的系统的基石，据公交查询系统的性质采用B/S模式是比较合适的。
尽管如此在本系统的开发设计过程中，由于本人对开发工具的掌握尚有欠缺，可以说整个的开发过程是一边摸索一边实践出来的。
但令人欣慰的是，通过这样一个边学习边应用的过程与其他同学、老师的帮助，本人基本完成了公交查询系统的开发工作，并基本实现了该应用程序背景所要求的功能。
在此过程中我的学习和应用能力得到了相应的提升，为日后设计开发和学习增强了勇气和信心。
但总的来说，程序仍然存在着许多不足之处，在整个开发过程中本人一直本着认真、虚心、刻苦、积极的态度，坚持自己独立完成设计，努力完成应用设计的简单功能要求。
虽然这个过程是比较辛苦的，亦却是充实的，在这期间对大学四年所学的东西有一个回顾、总结和提升的过程，直到学习一样东西要从态度、方式、方法三个方面来考虑，这样才能很大一部分决定学习的结果，此次毕业设计就很好验证了这一点，我想这对我以后不管是工作还是学习上都会有很大的帮助。
感谢下载!
欢迎您的下载，资料仅供参考
升级会员 