公交查询系统的设计和实现.doc

公交查询系统设
计与实现

班级：12物联网工程
学号：141057
姓名：郑秀成
日期：12月15日

引言
随着因特网发展日新月异，人们运用网络实现资源共享以及协同工作越来越成为时代潮流，使用各种网上软件以便生活，已经成为了一种不可扭转趋势。以此设计题目为目，选取郑州市作为实践对象，以郑州市公交系统为基本，再运用所学知识，纯熟运用开发工具后，开发一种郑州市手机公交线路查询软件，并且尽量将其开发为一种以便大众使用公交线路查询软件。
并且在当今公交出行线路多数是通过PC机查询获得，但是假想一下在公交出行线路走到一半时候筹划有所变化，公交出行线路需要有所调节，那么如何可以动态掌握线路信息显得尤为重要，并且将来对生活满意度也不但仅是百姓致富安居乐业就足以，而是逐渐趋向于一种更人性化服务。都市交通服务以及附属某些服务始终都在不断随着社会进步而进步，这些服务从最开始直接人力服务转向技术型服务，如电话询问，路牌等，然而这些服务总是有比较大局限性，即纵然你懂得了这条路该怎么走，下条路线该通到哪却不知，于是开发这个手机公交线路查询软件，可在手机上随时随处对公交线路进行查询，对顾客将要出行路线了如指掌，这对顾客来说可以省去诸多麻烦，节约不少时间。本次毕业设计结合郑州市公交线路系统开发一种郑州公交线路手机查询软件,服务于大众。

目录

第一章 需求分析与概要设计 1
1.1 可行性分析 1
1.2需求分析 1
1.2.1系统功能需求 2
1.2.2 服务器端需求分析 2
1.2.3 客户端需求分析 3
1.2.4 开发环境及工具需求分析 4
1.3 概要设计 4
1.3.1 开发流程 4
1.3.2 系统数据流图 5
1.3.3 系统整体构造阐明 6
1.3.4 系统功能模块划分 7
第二章 模式设计 10
2.1 C/S模式简介 10
2.2 B/S模式简介 10
2.3 B/S-C/S模式 11
2.3.1 B/S-C/S模式定义 11
2.3.2 B/S-C/S模式特点 12
第三章 数据库设计 13
3.1 数据库构造 13
3.2 服务器数据库设计： 13
3.3 客户端数据库设计： 17
3.3.1 SQLite简介 17
3.3.2 数据库设计 18
第四章 系统测试 20
4.1系统测试方案 20
4.2 性能分析 20
总结 21

第一章 需求分析与概要设计
1.1 可行性分析
可行性分析是对系统进行全面、概要分析。它任务是拟定项目开发时与否必要和可行。它重要目的是：进一步明确系统目的、规模和功能，对系统开发背景、必要性和意义进行调查分析，并且提出系统逻辑模型和各种也许方案，从而为系统开发项目决策提供科学根据。重要从三个方面进行研究：（1）技术可行性：以既有技术进行系统开发及系统实行，是完全可行。一方面，从自身来分析，通过2年多学习已经初步掌握了JSP控件、SQL数据库等方面编程技巧，对该软件设计并不存在技术上难点。第二方面，在设计这个系统之前，我进行了一系列先期调研，查阅了关于使用JSP进行数据库开发方面论著、教材和论文，更多是运用网络便利条件，从网上查阅了北京、上海、广州、昆明等大型都市公交查询系统，并认真地对其进行了分析研究，由于时间紧,任务重，我没有更多时间来开发完整系统，因此就以查询作为这个系统核心。另一方面，从数据库方面来分析，也是可行。系统所建立数据库表中包具有五个字段：bus_number,bus_station1，bus_station2，bus_station3，bus_station4。bus_number用来存储车次，bus_station1，bus_station2，bus_station3，bus_station4这四个字段用来存储站点。（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手机操作系统是在Android SDK提供虚拟机中运营，该虚拟机运营在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.1 C/S模式简介
精简说：C/S模式是一种三层构造系统,第一层在客户机上安装了客户机应用程序,第二层在服务器上安装服务器管理程序，第三层是数据访问层。在C/S模式工作过程中,客户机程序发出祈求,服务器程序接受并且解决客户机程序提出祈求,然后返回成果。
C/S模式特点：
(1)C/S模式将应用与服务分离,系统具备稳定性和灵活性
(2)C/S模式配备是点对点构造模式,合用于局域网,有可靠安全性
(3)由于客户端实现与服务器端直接连接,没有中间环节,因而响应速度快
(4)在C/S模式中,作为客户机计算机都要安装客户机程序,一旦软件系统升每台客户机都要安装客户机程序,系统升级和维护较为复杂发。
2.2 B/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.3 B/S-C/S模式
2.3.1 B/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.1 B/S-C/S模式构造图

本软件系统采用B/S-C/S模式，系统框架如图2.3.2所示。

图2.3.2 系统框架图
2.3.2 B/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 服务器数据库设计：
顾客需求详细体当前对各种信息提供、保存、更新和查询等方面。因而，一种满足规定数据库必要充分满足对各种信息输入输出需要。
公交查询系统应满足如下信息需求：
l 管理员必要先登录系统后台管理才干对系统中线路、站点等信息进行添加、删除、修改等工作。
l 普通顾客不需进行注册就可以直接查询有关信息。
l 一辆公交车通过各种站点。
l 每个站点有多辆公交叫信息。
l 一辆公交只有一条行驶线路。
l 一条线路涉及各种站点。
综合上面对网上购物系统数据库需求分析，考虑到将来功能上扩展，设计如下数据项构造：
l 管理员信息涉及数据项：帐号、姓名和密码。
l 公交车信息涉及数据项：线路号、始发时间、末班时间、车辆级别、车辆类型、始发站、终点站。
l 站点信息涉及数据项：站点名称、要通过线路号。
l 线路信息涉及数据项：线路号、线路中涉及站点号。

通过上面数据库需求分析可知，该系统实体有管理员实体、公交车实体、线路实体、站点实体。
管理员实体如图3.2.1 所示：
管理员

Num

Password

Name

图3.2.1 管理员实体图
公交车实体图如图3.2.2所示：

公交车

BusNum

EndTime

BeigenSt

BeigenTime

EndSt

BusState

BusLevel

图3.2.2公交车实体图

线路实体如图3.2.3所示：

线路

Note

LineNum

EndSt
BeigenSt

图3.2.3 线路实体图

站点实体图如图3.2.4所示：

站点

StNote

StName

图3.2.4站点实体图

各实体间关系E-R图如图3.2.5 所示：

添加、删除、修改

管理员
站点

1 n

添加、删除、修改
1 m
涉及

n n
公交车
行驶
线路

1 1

m n

查询
顾客
查询
n m

图3.2.5各实体间关系E-R图
依照上面E-R图，本软件服务器端定义arashmen数据库设计了如下4张表：站点表：station(表2)、线路表：routes(表3)、发车时间表:departuretime(表4)、票表:fare(表5)。
本软件服务器数据库所包括表描述如表1。
表3.1 管理员信息表
数据名称
字段类型
阐明
Account
文本
管理员帐号
Name
文本
管理员姓名
PassWord
文本
管理员密码

线路信息表如表3.2所示：
表3.2 线路信息表
数据名称
字段类型
阐明
LineName
文本
线路名称
BeigenSt
文本
起始站点
EndSt
文本
终结站点
Note
文本
线路信息

公交车信息表如表3.3所示：
数据名称
字段类型
阐明
BusNum
文本
公交线路号
BeigenSt
文本
始发站
EndSt
文本
终点站
BusLevel
文本
公交级别
BusState
文本
公交类型
BeigenTime
文本
始发时间
EndTime
文本
末班时间
表3.3公交车信息表

站点信息表如表3.4 所示：
表3.4站点信息表
数据名称
字段类型
阐明
StName
文本
站点名称
StNote
文本
站点信息

3.3 客户端数据库设计：
3.3.1 SQLite简介
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 线路表
字段名
数据类型
长度
主键/外键
默认值
描述
RouteName
Char
20
PK

线路名称
Content
LongText

线路全径
表3.9 发车时间表
字段名
数据类型
长度
主键/外键
默认值
描述
id
Int
4
PK

ID，自动增长
RouteName
Char
20
FK

线路名称
FirstDepartureTime
Time

首班发车时间
LastDepartureTime
Time

末班发车时间
表3.10 票价信息表
字段名
数据类型
长度
主键/外键
默认值
描述
id
Int
4
PK

ID，自动增长
RouteName
Char
20
FK

线路名称
isFixedFare
Char
5

与否为分段计费
FullFare
Double
8

全程票价

第四章 系统测试
4.1系统测试方案
依照本程序实际状况，进行了如下测试：
1） 输入异常数据或进行异常操作
在主页面中输入与车次无关站点信息，系统将对所输入信息与数据库中信息作比较，如果没有找到相相应信息，则系统显示为空。当顾客没有输入任何字符时候，系统会提示顾客输入相应信息，以便查询。只有符合数据库中信息，才干进行相应查找。
2） 劫难恢复性测试
由于本系统需要一种数据库作为数据存储平台，因此当数据库遭到破坏时候就无法运营，因此管理员在寻常添加、修改和删除前都要进行必要数据库备份工作。此外由于本系统是静态网页，因此当管理员进行数据添加、修改和删除操作后，无法实时地显示被添加、修改和删除操作后信息。此时顾客如果想获取最新车次以及站点信息就需要进行手工网页刷新，这也是静态网页一种弊端之一。
从容错性测试概念可以看出，容错测试是一种对抗性测试过程。要测试软件浮现故障时，如何进行故障转移与恢复有用数据。故障转移（Failover）是保证测试对象在浮现故障时，能成功地将运营系统或系统某一核心某些转移到其他设备上继续运营。
4.2 性能分析
通过这段时间努力，本软件基本完毕了任务规定。
通过测试和分析得到如下结论：
（1）各个界面基本可以运营成功，且界面和谐、布局合理、操作简朴
（2）系统运营速度较快，系统启动运营时间不超过5min，人机界面交互时间不超过5s
（3）容错能力强，性能优
（4）安全可靠性优化

总结
一种应用程序设计开发好坏，与设计人员对开发工具掌握限度息息有关。依照个人状况，尽量选取了自己较熟悉开发环境及工具，以便可以顺利实现系统避免延期。同步设计思想，方式在开发前要不断进行思考和考察，一种好设计思路是开发出好系统基石，据公交查询系统性质采用B/S模式是比较适当。
尽管如此在本系统开发设计过程中，由于本人对开发工具掌握尚有欠缺，可以说整个开发过程是一边摸索一边实践出来。但令人欣慰是，通过这样一种边学习边应用过程与其她同窗、教师协助，本人基本完毕了公交查询系统开发工作，并基本实现了该应用程序背景所规定功能。在此过程中我学习和应用能力得到了相应提高，为日后设计开发和学习增强了勇气和信心。但总来说，程序依然存在着许多局限性之处，在整个开发过程中本人始终本着认真、虚心、刻苦、积极态度，坚持自己独立完毕设计，努力完毕应用设计简朴功能规定。虽然这个过程是比较辛苦，亦却是充实，在这期间对大学四年所学东西有一种回顾、总结和提高过程，直到学习同样东西要从态度、方式、办法三个方面来考虑，这样才干很大一某些决定学习成果，本次毕业设计就较好验证了这一点，我想这对我后来不论是工作还是学习上都会有很大协助。