参考]精品基于xml的公交线路查询系统设计与实现定

参考]精品基于xml的公交线路查询系统设计与实现定内容摘要：

(如数据表 )的类型。 这两种类型之间联系密切，在数据库开发中两种类型都会用到。 然而，如果使用数据访问类型来填充数据表示类型将节省大量工作。 目前的主流版本是 ，比之前的版本提供了更先进的功能，主要包括以下高级特性： 支持批量复制，在其 .NET 类库中提供了批量复制类。 新的主要数据控件，包括 DataGridView、 DataConnector 和 DataNavigator。 DbProvidersFactories 类，该类能导出本地计算机中的 .NET 数据提供者列表。 DataTable 新增两个重要的方法： Load()方法和 Save()方法。 Load()方法可将数据对象直接加载到 DataTable 中，而 Save()方法可以将 DataTable 中的数据保存到一个持久化的存储媒体中。 支持自定义的数据提供者。 最短路径算法介绍 最短路经 算法 分静态最短路 径算法 和动态最短路 径算法。 静态最短路径算法是外界环境不变，计算最短路径。 主要有 Dijkstra 算法， A*（ A Star）算法。 动态最短路 径算法 是外界环境不断发生变化，即不能计算预测的情况下计算最短路。 如在游戏中敌人或障碍物不断移动的情况下。 典型的有 D*算法 [4]。 最短路径不仅仅指一般意义上的距离最短，还可以引申到其他的度量，如时间、费用、线路容量等。 相应地，最短路径问题就成为最快路径问题、最低费用问题等。 由于最短路径问题在实际中常用于汽车导航系统以及各种应急系统等（如 110 报警、 119 火警以及医疗救护系统），这些系统一般要求计算出到出事地点的最佳路线的时间应该在 1 s～ 3 s 内，在行车过程中还需要实时计算出车辆前方 的行驶路线，这就决定了最短路径问题的实现应该是高效率的。 其实 ,无论是距离最短、时间最快 、 费用最低，它们的核心算法都是最短路径算法。 经典的最短路径算法 —— Dijkstra 算法是目前多数系统解决最短路径问题采用的理论基础，只是不同系统对 Dijkstra 算法采用了不同的实现方法。 Dijkstra 算法的基本思路是：假设每个点都有一对标号 (dj, pj)，其中 dj是从起源点 s 到点 j 的最短路径的长度 (从顶点到其本身的最短路径是零路 (没有弧的路 )，其长度等于零 )； pj 则是从 s 到 j 的最短路径中 j 点的前一点。 求解从起 源点 s 到点 j的最短路径算法的基本过程如下：。 起源点设置为： 9 ① ds=0, ps 为空。 ② 所有其他点 : di=∞ , pi=?。 ③ 标记起源点 s，记 k=s,其他所有点设为未标记的。 k 到其直接连接的未标记的点 j的距离，并设置： dj=min［ dj, dk+lkj］ 式中， lkj 是从点 k到 j的直接连接距离。 从所有未标记的结点中，选取 dj 中最小的一个 i： di=min［ dj, 所有未标记的点 j］ 点 i 就被选为最短路径中的一点，并设为已标记的。 点 i的前一点。 从已标记的点中找到直接连接到点 i 的点 j*， 作为前一点 ,设置： i=j* i。 如果所有点已标记，则算法完全推出，否则，记 k=i，转到 2 再继续。 从上面可以看出，在按标记法实现 Dijkstra 算法的过程中，核心步骤就是从未标记的点中选择一个权值最小的弧段，即上面所述算法的 (2)～ (5)步。 这是一个循环比较的过程，如果不采用任何技巧，未标记点将以无序的形式存放在一个链表或数组中。 那么要选择一个权值最小的弧段就必须把所有的点都扫描一遍，在大数据量的情况下，这无疑是一个制约计算速度的瓶颈。 要解决这个问题，最有效的做法就是将这些要扫描的点按其所在边的权值进行顺序排列，这样每循环一次即可取到符合条件的点，可大大提高算法的执行效率 [5]。 还有一种基于 Dijkstra 算法的优化算法 ——— 邻接结点算法 ,该算法充分利用了网络拓扑信息中的弧段的连接关系 ,避免了使用含有大量无穷值的关联矩阵 ,使之更适合带有拐向限制设置的最短路径算法和大量结点的实际数据。 实践证明 ,该算法可以节约大量的内存 ,对于结点数比较大的网络 ,或带有大量拐向限制设置的网络 ,具有较好的适用性。 A*算法作为一种改进的 Dijkstra 算法 ， 实际上是一种启发式搜索，所谓启发式搜索，就是利用一个估价函数评估每次的决策的价值，决定先尝试那一种方案。 这样可以极大地优化普通的广度优先搜索。 一般来说，从起始点 A到终点 B的最短路径是固定的，可以写一个函数 Judge()来估计 A到 B的最短距离，如果程序已经尝试着从 A沿着某条路线移动到了 C 点，那么认为这个方案的 AB 间的估计距离为 A 到 C 实际已经行走了的距离 H加上用 Judge()估计出的 C到 B的距离。 如此，无论程序搜索展开到了哪一步，都会算出一个评估值，每一次决策后，将评估值和等待处理的方案一起排序，然 后挑出待处理的各个方案中最有可能是 10 最短路线的一部分的方案展开到下一步，一直循环到对象移动到目的地为止 [6]。 B/S 介绍 B/S（ browser/server，简称 B/S）模式 ，即 浏览器 /服务器 模式，它是 基于Intra 的需求而出现并发展的。 Intra 是应用 TCP/IP 协议建立的企事业单位内部专用网络，它采用诸如 TCP/IP、 HTTP、 SMTP 和 HTML 等 Inter 技术和标准，能为企事业单位内部交换信息提供服务。 同时，它具有连接 Inter 的功能和防止外界入侵的安全措施。 另一 方面，由于数据库具有强大的数据存储和管理能力，并且能够动态地进行数据输入和输出，如果把数据库应用于 Intra上，不仅可以实现大量信息的网上发布，而且能够为广大用户提供动态的信息查询和数据处理服务，进而加强企事业单位内部部门之间、上级部门与下级部门之间、企事业单位员工之间、企事业单位与客户之间以及企事业单位与企事业单位之间的信息交流，降低企事业单位的日常工作成本，提高企事业单位的经济效益。 它通常采用 3 层结构：浏览器―― WEB 服务器――数据库服务器。 在 Intra 框架中， Browser/Server模型的处理方式如下： 1．用户打开计算机中的浏览器。 2．输入或自动启动主页的 URL (Uniform Resource Locator)，浏览器生成一个 HTTP 请求并把它发给指定的 Inter 服务器。 3．服务器发回主页的 HTML (Hypertext Markup Language)页面。 浏览器将其显示在屏幕上。 4．用户在主页面上进行操作 (如：点击、键入等 )。 5．浏览器生成相应的 HTTP 要求，发送给相应的服务器。 6．服务器收到请求后，查看本站点是否拥有这个文档。 如果有，就将它放入响应信息中返 回给浏览器。 7．浏览器收到响应，查看头文件的格式，判断能否直接显示。 如果否，就调用对应的帮助应用程序或外挂程序处理显示。 11 第三章 系统需求分析 本章分析了系统的各项需求，包括性能需求 、功能需求、 模块划分 等。 性能需求分析 为了保证系统能够长期、安全、稳定、可靠、高效地运行，公交查询系统应该满足以下性能需求： 、 及时性 和响应速度 系统处理的准确性和及时性是系统的必要性能。 查询时应保证查全率，所有相应域包含查询关键字的记录都应能查到。 在系统设计和开发过程中，要充分考虑系统当前和 将来可能承受的工作量，使系统的处理能力和响应时间能够满足系统管理员对信息处理的需求。 响应时间，更新处理时间都 要 比较迅速， 应 满足 大部分 用户 的 要求。 一般操作的响应时间应在 12s 内，对数据的导入、导出的操作也应在可接受的时间内完成，原则上保证操作人员不会因为速度问题而影响工作效率。 系统在开发过程中，应该充分考虑以后的可扩充性。 例如，用户查询的需求也会不断地更新和完善。 这就要求系统提供足够的手段进行功能的调整和扩充。 而要实现这一点，应通过系统的开放性来完成，即系统应是一个开 放系统，只要符合一定的规范，可以简单地加入和减少系统的模块，配置系统的硬件。 通过软件的修补、替换，完成系统的升级和更新换代。 系统是直接面对使用人员的，而使用人员往往对计算机并不是非常熟悉。 这就要求系统能够提供良好的用户接口，易用的人机交互界面。 所以在系统开发的时候就考虑到了这一点，只要用户知道本系统的网址就可以直接使用本系统的查询模块而无须用户注册及登陆，充分节约了用户查询的方便及随意性。 其次，要实现本系统的易用性就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可 能出现的使用问题，要 提供足够的在线帮助，在本系统中专门设置了“联系我们”这一信息 ，可以让用户对本系统的不足之处让设计者知道，使系统更加完善。 公交查询系统中涉及到的数据是公交公司的相当重要的信息，系统要提供方便的手段供系统维护人员进行数据的备份，日常的安全管理，系统意外崩溃时数据的恢复等工作。 12 系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。 所有这些都要符合主流国际、国家和行业标准。 例如在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准。 如规范的数据库操纵界面、作为 业界标准的TCP/IP 网络协议及 ISO9002 标准所要求的质量规范等；同时，在自主开发本系统时，要进行良好的设计工作，制订行之有效的软件工程规范，保证代码的易读性、可操作性和可移植性。 目前计算系统的技术发展相当快，做为公交查询系统工程，应该保证系统长期保持先进，在系统的生命周期尽量做到系统的“与时俱进”，充分完成企业信息处理的要求而不至于落后。 这一方面通过系统的开放性和可扩充性，不断改善系统的功能完成。 另一方面，在系统设计和开发的过程中，应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。 功能 需求分析 本系统采用结构化设计的方法来实现系统总体功能，提高系统的各项指标，即将整个系统合理的划分成各个功能模块，正确地处理模块之间和模块内部的联系以及和数据库的联系，定义各模块的内部结构，通过对模块的设计和模块之间关系的系统来实现整个系统的功能。 普通用户需求分析 基于方便市民搭乘公交出行的原则，该系统应满足 普通用户 下面几方面 功能需求： ：方便用户了解到最快最新的线路信息，如 :此线路经过哪些站点，和站点在线路中的位置等。 ：用户如果对线路不清楚，只知道自己要去的 地方，那么站点查询会帮你快速找出可以搭乘哪些线路的公交车到达此地 ,还能提供 各线路的相关信息，并注明了此站点在相应线路中的顺序，方便用户了解该站点在线路中所处的位置。 ：如果没有直达线路，则找出转乘的最短公交路线。 用户输入起始站和终点站作为查询关键字，即可查询到三次转车内到达目的地址的公交线路。 可以为用户节省更多的时间，也提高了效率。 ： 将用户查询到的内容 自 动生成报表，并打印输出。 ：用户可联系管理员反映自己的意见。 查询者 可以执行线路查询、站点查询、换乘查询（包括：一次 换乘、二次换 13 乘、三次换乘查询）的操作。 查询者 的用例分析如图 所示： 查 询 者系 统线 路 查 询站 点 查 询换 乘 查 询一 次 换 乘二 次 换 乘三 次 换 乘 子 类 子 类 子 类 图 查询者的用例分析 由上图可查询者所需执行的系统功能。 管理员需求分析 为了维护系统的正常运行，系统还需提供 后台管理 功能， 用于管理员登陆，添加、修改、删除公交 数据信息 ，修改信息资料、安全密码，回复用户留言等 ，其中最主要的功能是新增、修改、删除数据信息 ，以保证公交 车线路 是正确可用的。 管理员的用例 分析如图 所示 ： 管 理 员系 统新 增查 看修 改删 除 e x t e n d s e x t e n d s 图 管理员的用例分析 由上图可知管理员所需执行的系统功能。 14 功能 模块划分 模块 该模块实现公交查询功 能。 可实现按线路查询、站点查询和起点－终点查询三种查询方式。 模块 该模块实现数据的新增、修改、删除功能。 模块的各功能划分如图 所示： 图 系统功能模块图 系统的功能模块由上图所示划分，在不同的模块下实现不同的功能 ，如普通用户模块下有车次查询、站点查询等功能，管理员用户模块下有修改、删除数据等功能，分工明确，一目了然。 公交路线查询系统 普通用户模块 管理员用户模块 车次查询 站站查询 站点查询 路线打印 新增 删除 修改 线路 车辆。