基于lbs的信息采集系统设计与实现毕业论文(编辑修改稿)

基于lbs的信息采集系统设计与实现毕业论文(编辑修改稿)内容摘要：

一层客户端，第二层应用服务器和第三层地图服务器。 通过引入三层结构，可以将更多的精力放到第一层客户端和第二层应用服务器的功能开发上，而对于第三层地图服务器则可以采用成熟的商用解决方案。 这样的系统结构缩短了项目开发的周期，在扩展性方面留有充分的余地，维护起来也很方便，同时使得系统在更加灵活的同时也更加强壮。 用户在实际使用时可以通过三种方式访问系统。 最通常的情况下，用户将 通过移动电话上运行的客户端程序，在具有定位能力的无线网络支持下访问系统；当用户使用自带定位能力的 PDA(Personal Digital Assistant)时，根据PDA 功能的差异，可以直接通过 Inter 访问系统或者通过无线网络间接访问系统；此外，为了增加系统的适用范围，还允许用户用 PC(Personal Computer)通过 Inter 直接访问系统。 虽然随着技术的进步，目前的 PDA和移动电话都具有了一定的嵌入式计算能力和存储能力，以目前市场上常见的中高端手机为例，其计算能力一般为 1M MIPS，存储能力一般为数兆～数十兆。 显而易见，这样的硬件条件是不足以处理庞大的地理数据的。 因此，系统将主要的计算任务交由后台服务器完成，如地图的产生、移动和缩放；地图目标的查询：最短路径搜索等。 PDA 或移动电话只负责完成发起查询和显示查询结果，而不保存地理数据和进行复杂的地图相关的运算。 这样的系统设计带来的弊端是系统交互次数增加；数据传输量大，占用运营商过多的带宽；后台服务器负担重等。 但是硬件设备的发展数度是很快的，当用户端的掌上设备达到一定的要求后，可以将系统的计算任务从后台服务器向用户端转移，从而改善 系统的性能。 无论用户采用何种访问方式，系统都必须根据用户终端的显示能力和运算能力提供适当的响应。 同时为了适应不同的访问方式和提高系统的可扩展性，系统在客户端和应用服务器之间、应用服务器和地图服务器之间都定义了统一的 XML 接口。 XML 接口提供了与平台无关的数据传输，只要遵循了这套接口，就可以从不同的平台上来访问服务器。 应用服务器提供了客户端和地图服务器间的接口，它负责翻译和转换用户的输入以及地图服务器的响应，同时它还负责完成用户信息的基于 LBS 的信息采集系统设计与实现 7 管理和计费。 地图服务器采用了 ESRI 公司的产品 —— ArcIMS， ArclMS 地图服务器适用于无线互联网、 Inter、 Intra 的地图应用的开发，能以多种图形格式发布地图，很容易建立基于 PDA 或手机的可扩充的移动定位服务应用。 对于 LBS 应用，核心问题是解决大用户量的并发访问问题， ArcIMS 采用了先进的负载平衡和流量控制技术，当需要扩大系统容量时，只需简单的增加地图服务器的数量就可以满足用户的要求。 至于地理数据则可以从特定的基础地理数据生产商处购买，并且根据实际需要，还要对 GIS 地理数据进行一些自己感兴趣的加工，比如采集并添加宾馆酒店、自动取款机、公共汽车站等数据信 息。 （二 ） 系统 结构设计 随着移动互联网的发展和智能移动终的普及，移动信息服务系统正逐步在取代传统信息服务系统，其便捷的优势是传统信息服务系统无法比及的，而随着 LBS 技术的成熟及应用，结合 LBS 的移动信息服务系统更能发挥其地理位置与信息服务的优势。 本文提出了一种基于 LBS 的新型校园信息服务方式：移动客户端一旦在校园内启动该软件，服务器就将已经整合好的院校通知信息，推送到客户端。 使得学生和老师省去了上多个院网，校园 BBS 以获取校园动态的繁琐操作，达到校园信息的一站式阅读。 因为移动手机自身的便携 带性，所以基于 LBS 的信息服务更有即时性，同时限定信息的使用者和发布者都是校园里面的人，从而一定程度上保证了信息的安全性。 1． 业务需求分析 目前的大学就业过程中，学生对招聘信息的需求是十分巨大的，但却缺少知晓校园招聘信息的渠道，学校主要是通过学校就业网站显示招聘单位和职位，或者通过学院 群等方式通知相关信息，这样就存在着消息闭塞，缺乏实时性和共享性等缺点。 同时，很多学生平日在学校里专心研究，很少走出校门，对城市地理环境并不熟悉，针对这个问题，我们在系统中融入 LBS 服务，从而给求职者关于企业和招聘会 的路线导航和乘车推荐。 通过调查研究，系统业务主要包括以下几个方面： 基于 LBS 的信息采集系统设计与实现 8 ①个人注册和企业注册：求职者可以通过注册页面填写基本信息后注册到该系统，系统会自动保存其信息。 企业用户通过填写其企业基本信息后，通过管理员审核通过后，系统也会保存其信息。 管理员可以通过 Web 管理客户端对个人用户信息和企业用户信息进行管理。 ②企业信息发布：当企业通过注册后，可以在管理平台上面发布该企业的招聘信息，例如职位名称、职位介绍等。 同时企业也可以通过管理平台发布该企业宣讲会详情。 ③招聘信息查找：当求职用户注册成功后，用户可以通过行业 分类来查找与专业对口或者感兴趣的职位，其次用户也可以根据所在职位类型来查找相关的工作职位。 用户可以申请或自己感兴趣的职位。 ④路径规划：用户如果想去该公司所在地或者宣讲会所在地，可以通过定位功能实现线路规划，这样大大方便了对地理环境不熟悉的求职者。 ⑤企业对应聘者的查询：当求职者申请了某公司的职位后，企业用户可以通过管理平台查看到申请人的具体信息。 系统业务流程如图 所示： 2． 功能需求分析 为了明确系统设计目的，通过分析和进一步的整理归纳，系统整体功能需求如下： (1) 系统应允许求职者可以通过 手机客户端注册为系统用户，同时也允许管理员和企业用户使用浏览器访问 Web 管理端。 管理员可以对其他用户信息进行查看，基于 LBS 的信息采集系统设计与实现 9 能够对分类模块和推荐模块等进行操作。 (2) 系统允许企业用户添加招聘具体信息和宣讲会信息，当提交的招聘职位有求职者申请时，企业用户可以通过 Web 管理系统查询到，并能查看申请人的基本信息。 (3) 系统求职用户可以通过客户端检索求职信息，检索条件可以是行业分类名或者职位类型名，当查看自己想应聘的职位信息时，可以申请和收藏该职位。 并能通过 LBS 服务导航到相关地点。 用户还可以检索宣讲会信息，并也能导 航到宣讲会地点。 (4) 系统能通过后台推送一些求职方面的资料或文章，供客户端用户查看学习。 (5) 系统能保证后台数据库的安全性，同时能维护系统数据库表，包括对表进行增删改查操作。 3. 性能需求分析 作为一个便捷的实时求职信息服务平台，除了完成上述功能性的要求外，还需要满足一些非功能性要求，具体包括系统整体性、可扩展性、并发性、数据安全性四个方面。 (1) 整体性：提供良好的用户体验，统一的界面风格，有较好的互操作性；具有多种连接网络的方式，例如 WiFi 接入、 3G 网络接入；降低系统资源的消耗，保证系统 的稳定性和反应时间。 (2) 可扩展性：系统要具有低耦合性和良好的可扩展性，便于系统日后维护和升级；当新模块或新功能、修改等因素情况下，系统各版本能够兼容，方便系统的改进和完善。 (3) 并发性：当系统用户数量增加时，系统服务器必须保证较高的并发性能，防止该情况下，系统出现访问延时或访问断开等现象，影响系统运行。 (4) 数据安全性：为保证系统信息安全和通信安全，在网络传输、数据校对等过程中，必须对程序中的隐私数据进行一定的加密安全处理。 4. 体系架构 我们将本系统分为 Web 管理端、 Android 客户 端和系统服务器端三部分，在管理端我们采用典型的浏览器 /服务器 (B/S)架构，在 Android 客户端采用客户端 /服务器 (C/S)架构。 同时，为了遵循系统可扩展性和可复用性的设计原则，采用 MVC 软件设计模式。 将应用程序的主要功能分离到不同的类层中，抽取出业务逻辑，实现底层控制与业务逻辑的分离，从而实现系统的低耦合性，使后期开基于 LBS 的信息采集系统设计与实现 10 发和维护更加方便。 架构是指在一定的设计原则基础上，对组成系统的各部分进行合理的分析和安排，将多个小结构有效的融合形成大的体系。 它将系统的各个组成部分及其属性之间的相互关系通过不同的角度 进行展示。 在应用系统中最常见的一种架构模式是分层，通过层次结构将系统的各职责区分开来，每个层次仅负责与本身相关的系统，通过层次间的相互依托和调用来完成整个系统功能。 这样可以将一个巨大的系统拆分成不同的组件，不仅理清了系统的结构逻辑，也在很大程度上弱化了系统耦合度。 系统也不会因为任一层次组件的调整而整体变更。 一般情况下，一个系统大致可以分为三层，从上到下依次为应用层、服务层、数据层，也就是我们通常所说的三层架构模式，其各层功能如表 2． 1 所示。 应用层 负责具体业务和视图展示。 如系统的页面显示和结果展示 服务层 为应用层提供服务支持，包括维护系统业务逻辑和数据接口 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜素引擎等 系统分层架构功能描述 根据上述的分层模式的优势，本系统也严格遵循分层模式的设计方法，实现系统的低依赖性和高复用性，本系统的完整的体系结构设计如图 所示。 系统总体结构图 通过对系统总体结构的分析，通信终端仅仅显示数据，而应用层负责处理人机交互过程，移动终端通过系统客户端完成界面显示，而 Web 管理端通过浏基于 LBS 的信息采集系统设计与实现 11 览器进行界面交互；服务层主要是负责系统各业务规则逻辑服 务组件的实现，并为业务逻辑层提供访问这些业务逻辑的接口；客户端通过调用 Web Service 接口和业务基类共同完成业务逻辑处理，数据流传输等操作， Web管理端则通过 HTTP请求与 Web 应用服务器通信完成数据传输和业务逻辑处理；最后，系统通过数据层完成与数据库服务器的数据交互。 总而概之，系统数据层从数据库服务器获得原始数据，通过逻辑处理层的处理，业务逻辑层再把数据转换成符合业务规则的数据格式，最后，通过视图层将信息转换为用户可以理解的信息格式。 可见，这种设计实现了系统的分层和互操作性。 5. 系统服务器 端结构设计 与传统应用系统相比，高并发，大流量、高可用性、海量数据、用户分布广泛，网络情况复杂等是互联网应用系统所具有的特点，这就要求系统服务器具有较高的性能。 通常的小型系统中应用程序、数据库、文件等所有资源都在一台服务器上，但是随着系统的发展，一台服务器是不能满足系统发展的需求的。 越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足等问题将表现的愈来愈明显。 为了克服上述问题，本系统的服务器设计采用分布式集群架构，其结构图如图 所示。 系统服务器结构图 基于 LBS 的信息采集系统设计与实现 12 由上图可知，服务器端由负 载均衡调度服务器、应用服务器、文件服务器、缓存服务器、数据库服务器五部分组成，在服务器架构中，通过服务器对硬件资源的需求各不相同，我们将应用服务器与数据服务器分离。 应用服务器需要强大的 CPU 来处理大量的业务逻辑；文件服务器需要大容量硬盘来存储大量用户上传的文件；数据库服务器需要更快的硬盘和更大的内存来快速磁盘检索和进行数据缓存。 系统通过负载均衡调度服务器，将来之用户的访问请求分发到应用服务器集群中的任何一台服务器上，使应用服务器的负载压力不再成为整个系统的瓶颈。 同时，通过使用缓存，是绝大部分数据读操作访问都 可以不通过数据库就能完成，提高系统访问速率。 由于目前主流数据库都提供主从热备份功能，通过配置两台数据库服务器主从关系，实现数据库读写操作分离，从而改善数据负载压力，同时保证数据安全。 6. 系统客户端设计 客户端是应用程序与用户之间交互的桥梁， 主要是负责数据显示、功能模块转换等功能。 本系统有两个客户端，一个是 Web 端的 Web 管理客户端，其包括管理员功能界面和企业用户功能界面。 另一个是 Android 应用客户端，只针对求职用户功能设计。 Web 管理客户端。