基于B/S的城市公交线路管理及查询系统

2 系统需求分析

需求分析是对所要做的系统进行分析，通过使用文字和图表的综合形式，以相对来说容易让人理解的方式去描绘需求的数据、功能、行为，更可以直接评审其正确性、完整性和一致性[2]。通过查询相关的资料，对所做的系统进行分析，整理资料，得出如下的需求分析。

2.1 系统设计目标

基于B/S的城市公交线路管理及查询系统，给用户提供一个良好的用户界面，让用户对相关的信息进行浏览，足不出户就能完成相关的操作，合理安排出行,而在后台的管理界面中，管理员可以很容易的对信息进行增、删、改、查等操作，并对用户信息进行管理。

2.2 功能需求分析

根据对资料的整理和可能涉及到的功能分析，系统应包括以下功能：汽车配置，司机信息，公交路线信息，公交站点信息，留言板，公交换乘，福州著名景点信息以及对管理员进行管理等。其中，汽车配置，司机信息，公交路线信息，公交站点信息，公交换乘信息，福州著名景点信息可以在用户界面中查看，留言板可以对该系统进行留言跟回复相应的留言，或对服务进行评论，但后台管理不仅可以对所有信息进行浏览，留言板跟客服投诉信息的添加跟回复外，还可以对其他信息进行添加、删除、修改，很方便的对信息进行整理和管理，还可以对管理员进行管理。

2.3 数据流图

数据流图（Date Flow Diagram，DFD）虽然不是UML的正式组成部分，却可以补充UML图并提供对系统的需求。DFD使用分层的方式表示，即第一个数据流模型从整体上表现系统，随后的数据流图改进环境图，提供每个后续层增加的细节。[2]

数据流图有助于软件工程师开发信息域的模型，并同时开发功能域的模型。当DFD被改进到非常详细的程度时，分析师同时也就完成了系统功能分解。并且，当进入使应用具体化的处理时，DFD的求精导致了数据的相应求精。[2]

    

2.3.1 第0层数据流图

普通用户和管理员可以登录城市公交线路管理及查询系统。详见图2-1。

图 2-1 第0层数据流

2.3.2 第1层数据流图

第一层数据流图可以分为查询、汽车配置信息维护、司机信息维护、公交线路信息维护，路站信息维护、公交站点信息维护、留言板信息维护、客服投诉信息维护，福州著名景点信息维护，详见图2-2。

图 2-2 第1层数据流图

2.3.3 第2层数据流图

2.3.3.1 第2层查询数据流图

查询模块可以查询到汽车配置信息，司机信息，线路信息，公交站点信息，福州著名景点信息,公交换乘信息,留言板信息，客服投诉信息等，详见图2-3。

图 2-3 查询数据流图

2.3.3.2 第2层公交线路信息维护数据流图

公交线路信息维护可以对公交线路信息进行删除、添加、修改信息详见图2-4。

图 2-4 公交线路信息维护数据流图

2.3.3.3 第2层留言板信息维护数据流图

留言板信息维护可以对信息进行删除和修改。详见图2-5。

图 2-5 留言板信息维护数据流图

2.4 系统需求分析阶段的UML图

统一建模语言（UML），一种为面向对象开发系统产品进行说明、可视化和编制文档的语言。通过UML模型，用户可以很直观的对问题进行理解，及时的发现哪些地方是错误的或是疏漏的，可以加强人员之间的沟通，方便获取设计结果，对系统的完成提供保证[3]。

2.4.1 用例图

用例图是帮助定义系统以外的存在什么以及系统应该完成什么，很直观的看到系统下一些用例或参与者之间的关系，使用户可以很好的理解怎么使用这些元素，也使得开发者可以很好的实现这些元素[2]。

2.4.1.1 顶层用例图

顶层用例图是对系统进行分析设计的总的用例图。详见图2-6。

图 2-6 顶层用例图

2.4.1.2 系统管理员用例图

系统管理员可以对各种信息进行维护操作。

（1）公交线路信息维护包括三个部分：添加、删除、修改。详见图2-7。

图 2-7 公交线路信息维护用例图

（2）路站信息维护包括三个部分：添加、删除和修改。详见图2-8。

图 2-8 路站信息维护用例图

（3）公交站点信息维护包括三个部分：添加、删除和修改。详见图2-9。

图 2-9  公交站点信息维护

（4）福州著名景点信息维护包括三个部分：添加、删除和修改。详见图2-10。

图 2-10 福州著名景点信息维护用例图

2.4.2 类图

类图是显示模型的静态结构，特别是模型中存在了的类和类的内部结构以及类与类之间的关系，包括类的属性和操作。类图说明了在需求分析阶段各个类之间的关系[4]。经过分析，将汽车配置,司机信息，留言板，公交线路，公交站点，福州著名景点作为类。系统的设计类。详见图2-11。

图 2-11 系统的设计类

2.4.3 活动图

活动图是通过提供特定的场景内交互流的图形化表示来补充用例的。活动图增加了额外的细节，这些是用例不能直接描述的[2]。活动图描述满足用例功能需求所要进行的活动以及活动间的约束关系，画活动图有助于识别并行活动[21]。详见图2-12。

图 2-12 活动图

2.4.4 顺序图

顺序图----行为模型之一，是说明事件如何引发从一个对象到另一个对象的转移。一旦通过检查用例确认了事件，建模人员就创建了一个顺序图——用时间函数表现事件如何引发流从一个对象到另一个对象。事实上，顺序图是用例的速记版本。它表现了导致行为从一个类流到另一个类的关键类和事件。[2]

一旦完成了完成的顺序图，所有导致系统对象之间转移的事件都可以被整理为输入事件集合和输出事件集合（从一个对象）。对于将要构建的系统而言，这些信息对于创建有效的设计非常有用。[2]

2.4.4.1 汽车配置信息维护顺序图

删除汽车配置信息顺序图。如图2-13。

图 2-13 删除汽车配置信息顺序图

2.4.4.2 司机信息维护顺序图

添加司机信息顺序图。如图2-14。

图 2-14 添加司机信息顺序图

2.4.4.3 公交线路信息维护顺序图

（1）删除公交线路信息顺序图。如图2-15。

图 2-15 删除公交线路信息顺序图

（2）修改公交线路信息顺序图。如图2-16。

图 2-16 修改公交线路信息顺序图

（3）添加公交路线信息顺序图。如图2-17。

图 2-17 添加公交线路信息顺序图

2.4.4.4 路站信息维护顺序图

删除路站信息顺序图。如图2-18。

图 2-18 删除路站信息顺序图

2.4.4.5 添加留言板信息顺序图

添加留言板信息顺序图。如图2-19。

图 2-19 添加留言板信息顺序图

2.4.4.6 添加客服投诉信息顺序图。如图2-20。

图 2-20 添加客服投诉信息顺序图

2.4.4.7 添加客服投诉回复信息顺序图。如图2-21。

图 2-21 添加客服投诉回复信息顺序图

2.4.4.8 公交站点信息维护

删除公交站点信息顺序图。如图2-22。

图 2-22 删除公交站点信息顺序图

2.4.4.9 景点信息维护

修改福州著名景点信息顺序图。如图2-23。

图 2-23 修改福州著名景点信息顺序图

2.4.4.10 查询功能顺序图

（1）查看公交线路信息顺序图。如图2-24。

图 2-24查看公交线路信息顺序图

（2）查询公交站点信息顺序图。如图2-25。

图 2-25 查询公交站点信息顺序图

3 系统设计及实现

系统的设计是在进行完需求分析后对用户的要求进行概括和总结，对所做的系统进行总体规划，然后确定系统的结构和数据，是生成代码和测试的前一个阶段。

3.1 系统开发的环境和工具

（1）开发工具：MyEclipse；

（2）操作系统：Windows 7；

（3）后台数据库：Microsoft SQL Server 2000；

（4）开发语言：JAVA。

3.2 关键技术

3.2.1 Jsp

Jsp是java server pages的说些，是基于Java servlet以及整个java体系的web 开发技术，是有sun公司倡导，并采纳了计算机软硬件，通信，数据库领域多家厂商的意见而共同制定的一种基于java的web动态网页技术。[18]

Jsp技术的设计目的是为了更加容易和快捷地构造基于web的应用程序，而这些应用程序能够与各种web服务器，应用服务器，浏览器和开发工具共同工作，为创建动态生成内容的web页面提高了一个简洁而快速的方法。[18]

Jsp技术秉承了Java的“编写一次，到处运行”的精神，既同硬件平台无关，也同操作系统和web服务器无关，是一种与平台无关的技术。利用Jsp技术我们可以设计出先进，安全和跨平台的动态网站。[18]

3.2.2 JAVA

JAVA是SUN公司推出的心一带面向对象的程序设计语言，它是一种简单的面向对象的分布式可移植性能优异的多线程的动态语言。它具有一下特点。1.简单。JAVA的编程风格类似于C++的风格，JAVA中没有C++中的指针和内存管理的概念，可以避免犯错误，在JAVA中有丰富的类库，大大方便了编程工作。2.面向对象的特性。3.分布性。4.鲁棒性。5.安全性。6.体系结构中立.7.多线程性。8.动态性[3]。

3.2.3 Microsoft SQL Server 2000

Microsoft SQL Server是由微软公司开发和推广的数据库管理系统（DBMS），是Microsoft Back Office中最重要的部分，它是一种典型的关系数据库管理系统（RDBMS）。

Microsoft SQL Server使用Transact—SQL在客户机和SQL Server之间发送请求，在SQL Server的客户机/服务器体系结构中，工作负载被划分为在服务器计算机上运行的任务和在客户机上运行的任务两部分，客户程序负责业务逻辑和给用户显示数据，而SQL Server负责管理数据库和多个请求之间的服务器资源。[19]

在当今的互联世界中，数据和管理数据的系统必须始终为用户可用，且能够确保安全，有了SQL Server 2000，组织内的用户和IT专家将从减少应用程序运行时间、提高可伸缩性及性能、更紧密的安全控制中获益[6]。SQL Server 2000也包括了很多新的和改进功能来帮助企业的IT团队更有效率的工作。

Microsoft SQL Server 2000是由美国Microsoft公司制作并发布的一种性能优越的关系型数据库管理系统，具有强大的数据库创建，开发，设计和管理功能[7]。

3.2.4 servlet技术

Servlet是一种独立于平台和协议的服务器端得Java技术，可以用来生产动态的Web页面。Servlet具有很好的可移植性，具有高效，方便，跨平台，功能强大，灵活性和可扩展性，共享数据，安全等特点。Servlet是使用java servlet应用程序设计接口及相关类和方法的java程序。Java语言能够实现的功能，servlet基本上都能实现（除了图像界面外）。Servlet主要用于处理客户端传来的HTTP请求，并返回一个响应[7]。

3.2.5 浏览器/服务器结构

随着网络技术的不断发展，Internet为系统数据库应用提供了新的机会，构建以Web技术为中心的应用日益流行[8]。在浏览器/服务器（B/S）体系结构系统中，用户通过浏览器向分布在网络上的许多服务器发出请求，服务器对浏览器的请求进行处理，将用户所需信息返回到浏览器。B/S结构简化了客户机的工作，客户机上只需配置少量的客户端软件。服务器将担负更多的工作，对数据库的访问和应用程序的执行将在服务器上完成。浏览器发出请求，而其余如数据请求、加工、结果返回以及动态网页生成等工作全部由Web服务器完成[9]。B/S结构请参见如下图3-1。

图 3-1 B/S三层结构图

B/S结构采用统一的浏览器作为客户端，这样就避免了客户端多种程序所带来的数据不一致性的问题，而服务器端的开放和基于标准的连接方案，使用Web应用更加大众化[10]。此外，在B/S模式中，能有效地实现表现层与逻辑层的分离，网页设计与应用逻辑开发可以单独进行，通常应用逻辑被集中起来置于一个或多个服务器(应用服务器)上。B/S结构具有分布式部署、跨平台以及容易部署和管理等优点[11]。

3.2.6 J2EE架构的裁剪

J2EE架构由于其重量级的原因，在使用它开发时一般都要进行裁减。在当前的软件开发领域，人们一般将信息系统分为表现、持久、业务、领域模型等多个层次。其中，表现层的主要职责是为用户管理请求和响应，提供一个控制器代理调用业务逻辑和其它上层处理，处理从其它层抛出的异常，为显示提供一个模型以及执行用户接口（UI）验证等；持久层保存、更新、删除储存在数据库中的信息，通过持久层的逻辑隔离，应用程序变得易于修改而不会影响其它层的代码；业务层的职责是处理应用程序的业务逻辑和业务验证，管理事务，预留和其它层交互的接口，管理业务层对象之间的依赖，增加在表现层和持久层之间的灵活性，使它们互不直接通讯，从表现层中提供一个上下文给业务层获得业务服务（business services）以及管理从业务逻辑到持久层的实现；领域模型层由那些代表现实世界中的业务对象组成。

3.3 功能模块描述

系统体系结构是一个综合模型，系统体系结构是由许多结构要素及各种视图（或观点）（View）所组成的，而各种视图主要是基于各组成要素之间的联系与互操作而形成的。所以，系统体系结构是一个综合各种观点的模型，用来完整描述整个系统。[20]

系统设计功能图 如图3-2。

图 3-2 系统设计功能图

3.3.1 前台展示模块

公交线路管理及查询系统分为前台展示跟后台管理两个模块。而在前台展示中用户可以查询公交换乘，公交线路，景点，公交站点，车辆配置，司机信息外还可以对系统进行留言。

3.3.2 后台管理模块

后台管理又分为线路管理（包括线路的添加，删除，修改；车辆配置信息的添加，删除，修改），景点管理（包括景点的添加，删除，修改），用户管理（包括用户的添加，删除，修改），司机管理（包括司机的添加，删除，修改），站点管理（包括站点的添加，删除，修改），投诉管理（即投诉信息的回复）。

3.4 数据库表的设计

3.4.1 E-R图分析

概念模型用于信息世界的建模，是现实世界到信息世界的第一层抽象，是数据库设计人员进行数据库设计的有了工具，也是数据库设计人员和用户之间进行交流的语言，因此概念模型一方面应该具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识，另一方面它还应该简单、清晰、易于用户理解。[17] 

E-R图是实体关系图。它是概念模型的一种表示方法，它提供了表示实体型、属性和联系的方法：

实体型：用矩形表示，矩形框内写明实体名。

属性：用椭圆表示，并用无向边将其与相应的实体型连接起来。

联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关的实体型连接起来，同时在无向边旁标上联系的类型（1:1,1：n，m：n）。

需要注意的是，如果一个联系具有属性，则这些属性也是用无向边与该联系连接起来。

E-R模型是软件工程设计中一个重要方法，E-R模型只能说明是实体间的语义联系，还不能进一步说明详细的数据结构[12]。本系统中由于线路跟站点之间是多对多的关系，所以就多建立了一个实体路站。其中本系统的E-R图如图3-3。

图 3-3 本系统E-R图

3.4.2 数据表设计

通过对前面总功能模块的设计及各个功能模块的功能设计，对系统的整体已经有了大概的定型，这时候，就需要建立一个数据库来实现具体数据的存储。

系统中设计了用于记录路线编号，路线名称,车辆运行时间，票价，公交公司以及月票是否有效的Route (路线表)，具体表结构如表3-1所示：

表 3-1 路线（Route）表

名称	类型	备注	是否主键
[No]	Int（4）	路线编号	是
RouteName	Varchar（10）	路线名称	否
GoBacktime	Varchar（50）	车辆运行时间	否
Price	Numeric（9）	票价	否
Company	Varchar（50）	公交公司	否
IsmonthValid	Varchar（2）	是否月票有效	否
phone	Varchar（20）	客服电话	否

系统中设计了用于记录景点id，福州各景点的名称，景点简介,途径站点编号的Attractions(景点表) 具体表结构如表3-2所示：

表 3-2 景点（Attractions）表

名称	类型	备注	是否主键
Id	Int（4）	景点编号	是
Name	Varchar（100）	景点名称	否
address	Varchar（200）	景点地址	否
content	Varchar（8000）	景点简介	否
StationId	Int（4）	途径站点编号	否

系统中设计了用于记录车辆配置Id,车牌号，线路名称，司机编号的BusConfig(车辆配置表) 具体表结构如表3-3所示：

表 3-3 车辆配置（BusConfig）表

名称	类型	备注	是否主键
Id	Int（4）	车辆配置Id	是
BusNo	Varchar（15）	车牌号	否
RouteNo	Int（4）	线路名称	否
DriverNo	Int（4）	司机编号	否

系统中设计了用于记录留言或客服投诉的id，留言或客服投诉名称，留言或客服投诉内容，留言或客服投诉时间，点击次数，回复次数的Message(留言表), 具体表结构如    表3-4所示：

表 3-4 留言（Message）表

名称	类型	备注	是否主键
Id	Int（4）	留言或客服投诉的id	是
MessageName	Varchar（40）	留言或客服投诉名称	否
Content	Varchar（8000）	留言或客服投诉内容	否
Datetime	Varchar（30）	留言或客服投诉时间	否
clickCount	Int（4）	点击次数	否
restoreCount	Int（4）	回复次数	否
type	Int（4）	留言位置 0表示用户留言；1表示客服投诉	否

系统中设计了用于记录留言的回复id，留言或客服投诉的id,回复内容，留言时间的Restore(回复表) 具体表结构如表3-5所示：

表 3-5 回复（Restore）表

名称	类型	备注	是否主键
Id	Int（4）	回复id	是
MessageId	Int（4）	留言或客服投诉的id	否
Content	Varchar（8000）	回复内容	否
Datetime	Varchar（30）	回复时间	否

系统中设计了用于记录站点编号，站点名称，站点地址的BusStation(公交站点表) 具体表结构如表3-6所示：

表 3-6 公交站点（BusStation）表

名称	类型	备注	是否主键
id	Int（4）	站点编号	是
stationName	Varchar（20）	站点名称	否
stationAdd	Varchar（100）	站点地址	否

系统中设计了用于记录线路名称，站点编号，在线路中的顺序，线路中的存在方式的RouteStation(路站表),具体表结构如表3-7所示：

表 3-7 路站（RouteStation）表

名称	类型	备注	是否主键
routeNo	Int（4）	线路编号	是
stationId	Int（4）	站点编号	是
ordernun	Int（4）	在线路中的顺序	否
type	Varchar（1）	路线中的存在方式	否

系统中设计了用于记录司机的ID号，姓名，性别，联系方式，司机编号的driver(司机表), 具体表结构如表3-8所示：

表 3-8 司机（driver）表

名称	类型	备注	是否主键
id	Int（4）	司机的ID号	是
Name	Varchar（20）	姓名	否
Sex	Varchar（2）	性别	否
Tel	Varchar（20）	联系方式	否
Jobno	Varchar（10）	司机编号	否

系统中设计了用于记录管理员的id号，用户名，密码的manager(管理员表), 具体表结构如表3-9所示：

表 3-9 管理员（manager）表

名称	类型	备注	是否主键
Id	Int（4）	管理员id号	是
username	Varchar（50）	用户名	否
password	Varchar（50）	密码	否

 其他的定制服务  下方联系卡片↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 或者私信作者