地理信息系统概要设计说明书.docx

地理信息系统概要设计说明书.docx

《地理信息系统概要设计说明书.docx》由会员分享，可在线阅读，更多相关《地理信息系统概要设计说明书.docx（49页珍藏版）》请在冰豆网上搜索。

地理信息系统概要设计说明书

概要设计说明书

上海数慧系统技术有限公司

ShanghaiDigitalIntelligenceSystemsTechnologyCo.,Ltd.

文件修改记录（发布到外部的文档请将此部分删除）

版本号

版本说明

修改人

审核人

批准人

审批日期

1.0

第一次提交评审

苏君毅

TMO

2010年6月1日

请保护环境，注意纸张的回收利用

版权信息

本文件涉及之信息，属上海数慧系统技术有限公司所有。

未经上海数慧系统技术有限公司允许，文件中的任何部分都不能以任何形式向第三方散发。

上海数慧系统技术有限公司完全拥有知识产权，并受国际知识产权法律保护。

第1章.

引言

1.1.目的

编写目的：

本说明书是在《河南省环境保护厅环境地理信息系统投标方案》、《河南省环境保护厅环境地理信息系统需求分析说明书》的基础之上，经过分析和系统设计编写而成。

用于将软件系统需求转换为未来系统的设计，逐步开发强壮的系统构架，使设计适合于实施环境，为提高性能而进行的设计工作，对后面的概要设计、编码实现、测试、部署实施、运行维护工作有着关键性的影响。

适用读者：

河南省环境保护厅项目组成员

数慧公司项目组成员

1.2.文档概述

本说明书包括引言、系统概述、总体设计、功能设计、接口设计、数据结构设计、出错处理设计、系统部署设计等，以提供关于程序系统的逻辑和数据功能实现方式的总体描述。

1.3.术语定义

ØOGC：

开放地理信息系统协会（OpenGISConsortium,OGC）,OpenGIS规范致力于为地理信息系统间的数据和服务互操作提供统一。

ØW3C：

是对网络标准制定的一个非赢利组织，像HTML、XHTML、CSS、XML的标准就是由W3C来定制。

W3C会员（大约500名会员）包括生产技术产品及服务的厂商、内容供应商、团体用户、研究实验室、标准制定机构和政府部门，一起协同工作，致力在万维网发展方向上达成共识。

ØSOA：

面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

ØWebservice：

是创建可互操作的分布式应用程序的新平台。

Webservice的主要目标是跨平台的可互操作性。

为了达到这一目标，Webservice是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。

ØREST（RepresentationalStateTransfer）是一种轻量级的WebService架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。

ØSOAP（SimpleObjectAccessProtocol），它是一种标准消息传递协议，通常是WebService的事实标准。

SOAP是以XML为基础，SOAP消息格式是由XMLSchema模式定义，通过XML命名空间使SOAP具有很强的扩展性。

ØWMS：

Web地图服务（WMS）利用具有地理空间位置信息的数据制作地图。

其中将地图定义为地理数据可视的表现。

ØWFS：

Web地图服务返回的是图层级的地图影像，Web要素服务（WFS）返回的是要素级的GML编码，并提供对要素的增加、修改、删除等事务操作，是对Web地图服务的进一步深入。

ØWCS：

Web覆盖服务（WCS）面向空间影像数据，它将包含地理位置值的地理空间数据作为“覆盖（Coverage）”在网上相互交换。

ØESB：

企业服务总线（EnterpriseServiceBus）：

传统中间件技术与XML、Web服务等技术结合的产物。

ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。

基本功能为动态查找与路由、消息聚合与分发、消息转换、数据绑定转换。

1.4.参考资料

Ø《河南省环境保护厅环境地理信息系统投标方案》

Ø《河南省环境保护厅环境地理信息系统需求分析说明书》

Ø《软件架构设计》

Ø《SOA原理.方法.实践》

Ø《SOA整合之道》

Ø《企业应用架构模式》

Ø《WEB服务架构与开放互操作技术》

第2章.系统概述

2.1.系统开发背景

河南省近年来高度重视环境保护工作，坚持以污染防治为重点，以改善重点流域、重点区域环境质量为主线，不断加大环境保护力度。

到2009年底河南省将建成覆盖全省的多个环境环境自动监控系统。

此大规模自动监控系统建设，迫切需要一个统一的建设规范和标准，约束改造和代建的新系统。

因此，有必要建设地理信息系统，实现环境自动监控数据的空间表达，充分发挥最新通讯技术、信息技术、数据库技术、空间技术的优势，为河南省环境保护的管理、评价、决策工作提供有效支持。

2.2.建设目标

河南省建立环境地理信息系统，以充分发挥全省的环境质量、污染源自动监控系统的作用，形象展示环境自动监控数据，为河南省的环境信息化坚实打下坚实的基础，为各级环保部门的环境管理、决策服务。

具体目标如下：

Ø建设满足省环保厅业务应用的基础地理空间数据库，数字影像数据库，环保专业专题数据库。

Ø建设面向省环保厅业务应用的地理信息平台，满足环保业务对空间信息辅助决策支持应用的需求。

Ø以基础地理空间数据库为依托，GIS能够为污染源在线自动监控系统、环境质量管理系统、移动监察与执法系统、环境应急决策支持系统、数据中心和综合分析系统等提供基本的电子地图和专题地图，实现空间信息、属性信息的双向查询以及空间分析服务。

基于SOA（Service-OrientedArchitecture，面向服务的架构），实现GISWebService与其它子系统的集成，并通过GIS发布功能为决策提供支持服务。

Ø提供C/S方式的环境地理信息编辑管理发布系统，基于WEB方式的环境地理信息查询分析系统，可进行环境专题图制作与输出、查询统计汇总。

实现空气污染扩散、水污染扩散模拟展示。

实现重点监控目标三维展示。

Ø基于环境地理信息系统，在大屏幕上实时、近实时展现环境、企业、污染物变化等信息。

2.3.约束条件与非功能需求

根据需求调研阶段的成果，本系统的约束条件包括软件开发环境要求，系统架构需求和性能需求几部分

2.3.1.开发环境要求

系统需要在Oracle11g数据库管理软件，ArcGISServer9.3地理信息系统软件的基础环境下进行开发建设。

2.3.2.软件系统架构要求

系统采用组件式开发方式，针对普通用户（包括公众用户）的功能采用B/S模式开发，针对管理用户的功能采用C/S模式开发，系统应采用分布式B/S三层架构的方式进行开发。

要求功能菜单、发布内容可用户定制，可根据数据情况进行动态关联，特别是针对新增表及表字段，可发布、可计算、可加工、可制作等。

本系统要求采用SOA系统架构，提供良好的可扩展性和容错性，采用WebService技术。

本系统的客户展现端要求支持多种操作系统。

2.3.3.性能要求

Ø一般操作响应时间应不超过1秒

Ø按图上信息检索调图时，每次调图时间不大于5秒；

Ø其他复杂操作最多不超过10秒；

Ø本项目面向的用户包括河南省环境保护厅及各省辖市相关业务用户。

系统应当支持的用户数规模为500个。

Ø允许并发操作用户数大于50；

2.3.4.质量需求

Ø以系统连续运行120小时以上系统无错误发生进行衡量；

2.4.用户

2.4.1.组织机构

本系统服务的机构从里到外分别是环保厅内部各职能部门、下属各市环保局、其它委办局，现阶段主要考虑的用户主要是环保厅内部各职能部门。

2.4.2.用户分类

专题业务用户：

包括环保厅内部相关业务部门，使用地理信息系统模块的其他系统。

可以进入专题应用系统，使用专题功能。

数据管理员：

空间数据入库、更新、编辑、地图文件管理。

系统管理员：

服务注册、发布、地图服务管理、目录管理、权限分配，地图管理，日常维护。

第3章.概念架构设计

3.1.系统划分

根据项目合同，招标文件和需求分析说明书，本系统需要实现的主要功能包括：

Ø地理数据处理、数据质检、空间数据库管理

Ø环境地理信息数据展示、业务应用功能、对外服务

Ø地图服务注册、管理，系统服务管理

Ø系统用户、角色、权限、日志等日常管理

根据系统功能和职责划分的原则，把系统分为如下子系统：

数据规整与建库、空间数据库管理系统子系统；环境空间信息综合展示系统子系统和综合应用子系统；服务调度管理子系统和运行维护管理子系统，如图3-1所示。

图3-1系统划分图

3.2.系统架构

系统的技术路线和架构模式，需要根据项目功能需求和性能需求，质量属性等非功能的需求、约束条件，综合考虑，因事制宜，才能满足项目的要求。

根据上文阐述，根据功能需求把系统划分为四个子系统。

环境空间信息综合展示子系统是本系统的主要对外部分，提供给厅内各个部门业务办公使用，需要尽量简便的客户段部署，方便用户使用；同时还要向环境自动监控、数据中心、应急响应系统等大量B/S架构的系统提供电子地图，空间信息查询等服务，所以适宜使用B/S技术架构。

而空间数据管理子系统、运行维护管理子系统、服务调图管理子系统面向的用户为监控中心管理员，使用涉众较少，再者，对于复杂的空间数据入库，编辑管理，后台服务调度和运维管理，需要强调高效，实时性和可交互性。

更适合C/S的架构方案。

针对B/S的地理信息系统，采用分层架构模式是实现系统模块化的主流思想，该模式是为细化需求，降低模块间耦合，提高复用度而逐渐形成的应用系统标准模式。

此方法以传统的多层架构（至上而下为展现层、逻辑层、持久层）为基础，对整个软件系统的设计进行分解。

结合关键用例，以及质量属性与系统约束，涉及到架构的可复用性、可扩展性、易开发与维护性，并且在基于高效稳定的前提下，在系统的架构分层中提出服务层概念，包括基础服务层和数据服务层。

所谓服务层，是指将技术支撑子系统与模块单独隔离，以服务的方式提供给更高层的应用逻辑层访问，从而使得系统的开发更关注与业务逻辑的编排与组织。

从设计原则上来讲，业务逻辑属于变化的范畴，而对于技术层面来讲相对稳定。

因此将变化的部分有效隔离，完全符合面向对象设计思想的原理。

因此，整个系统的概念性架构的模式可以定位为：

采用B/S分层架构与C/S架构系统的综合运用。

在环境空间信息综合展示子系统采用B/S分层模式，而空间数据管理子系统、运行维护管理子系统、服务调图管理子系统，将采用C/S架构。

3.3.概念架构

3.3.1.B/S系统概念架构

B/S架构采用分层架构模式，可在概念上把整个系统划分为表现层、业务层服务层、基础服务层和数据资源层。

如图3-2所示，以以“断面信息查询”用例为例，说明了该用例鲁棒图所涉及的各种类在分层架构上的分布情况。

图3-2B/S系统概念架构图

各层级的主要职责如下：

数据资源层：

主要完成数据的分类存贮，数据库分为四个类：

基础地理数据库：

存放基础地形数据，包括各种比例尺的矢量数据、DEM数据、影像数据。

元数据库：

存放空间数据的元数据信息，包括目录结构、编目信息、层字段信息、坐标信息、生产日期。

业务数据库：

各种业务专题数据，如污染普查数据、环境统计数据。

这些数据库是以分布的形式部署在环保局各个部门中，不必都放在信息中心。

系统数据库：

存放安全信息、配置信息、日志信息。

基础服务层：

提供数据访问，地图访问服务。

本系统的的基础服务层由基础构件和第三方构件组成。

数据访问服务：

完成各种数据库访问，以及非结构化数据如文件数据的访问。

各类地图服务的提供，如地图访问，地图运算等。

业务逻辑层：

负责数据查询，分析运算，统计等与业务紧密相关的功能。

应用层:

负责数据资源的展现、发布、专题应用。

环境信息综合展示：

负责空间数据的浏览、查询，图层管理等基本GIS操作，以及统计，专题图输出，大气污染扩散模型，水污染扩散模型，三维系统等功能。

专题应用模块：

专题应用模块：

提供各类专题业务系统电子地图，提供空间信息和属性信息的互查等。

如在线监测系统、环统应急系统，数据中心系统。

3.3.2.C/S系统概念架构

C/S架构采用传统的MVC设计模式，把系统分为表现层，业务层，持久层三层。

如图3-3所示，以以“数据入库”用例为例，说明了该用例鲁棒图所涉及的各种类在分层架构上的分布情况。

图3-3C/S系统概念架构图

第4章.细化架构设计

细化架构也称作具体架构，它将以概念架构为基础，参照其架构模式，结合非功能性需求的“需求-场景-决策表”，分不同视角展开讨论。

细化架构可采用Rational公司推介的“4+1”视图，采用“5视图法”，两者在理念上并无太大的分别，但“5视图法”在实践上更易于理解，因此本文将采用“5视图法”，把细化架构划分为逻辑架构、开发架构、运行架构、数据架构和部署架构等五个视图，如图5-1所示。

其中逻辑、部署以及运行视图是决定系统架构的主要因素。

细化架构通常以逻辑架构为核心，以开发架构为结果。

该架构包含B/S与C/S两种模式。

B/S与C/S架构需要依赖共同的组件，但是在架构上有一定差别。

在后面章节分别论述。

图4-1系统细化架构的5个视图

4.1.逻辑架构

在分层架构的基础上，得到如图4-2所示的细化逻辑架构。

该架构分为B/S与C/S两个部分。

B/S架构分为数据访问层、地图服务层、业务逻辑层以及界面展现层。

C/S部分分为界面展现层，地图服务层和底层平台。

下面逐一描述各个层次的职责以及其交互机制。

图5-2系统逻辑架构

4.1.1.B/S架构

4.1.1.1.数据访问层

数据访问层是基础服务层的一部分，主要包括数据引擎、ArcObject对象访问服务、文件服务及XML框架，共四大模块，其相互间逻辑关系如图4-3所示。

各个模块的主要职责为：

Ø数据引擎主要用于对数据存取的操作，为整个系统提供统一的数据交互入口以及事务处理服务，属于该层的核心模块；

ØArcObject对象访问服务主要用于访问地理数据，为整个系统提供读写，编辑地理数据的服务，属于该层的核心模块；

ØXML服务的作用主要用于对业务元数据以及系统配置文件的读写操作，优化文件访问的性能；

Ø文件服务模块主要用于对本地或者远程文件的访问操作。

它套用了适配器设计模式（adapterpattern），屏蔽了不同访问方式之间的差异性，并提供可扩展的数据访问接口，以满足日后的不同文件访问方式——如通过网络二进制数据流直接构造文本文件等；

图4-3数据访问层架构

4.1.1.2.地图服务层

地图服务层是基础服务层的一部分，指用于支持业务运行的地图服务和地理运算服务，如图4-4所示。

图5-4地图服务层的逻辑架构

本层由第三方应用构件组成，主要是ArcGISServer服务。

这里需要说明的是：

在本文中，所谓构件，是指实现相应接口契约、独立组织的、自治的功能单元。

构件的运行一般需要相应的软件基础设施来提供环境，通过加载到相应的运行框架或者子系统来激活，因此，对于服务层的各个构件模块，相互之间可没有直接的依赖关系。

4.1.1.3.业务逻辑层

应用逻辑层是系统的核心部分，由业务服务和系统服务两部分组成，它们都要调用基础服务层的数据访问构件。

如图4-5所示。

图4-5应用逻辑层的逻辑架构

其中，业务服务由统计分析服务，智能搜索服务，图形查询服务，图形编辑服务，元数据服务，数据字典服务等功能组成。

如图4-6所示。

图4-6业务服务部分的逻辑架构

而系统服务端由界面管理服务，系统日志服务，系统异常服务，系统权限服务等组成，如图4-7所示。

图4-7系统服务部分的逻辑架构

4.1.1.4.界面展现层

界面展现层主要通过界面框架，将业务功能，界面布局，后台服务，消息、资源等组织起来。

功能以插件形式进行加载，而加载控制和服务的访问控制由前台框架和后台服务共同完成。

其逻辑结构如图5-9所示。

图4-8界面展现层的逻辑架构

4.1.2.C/S架构模式

4.1.2.1.C/S逻辑架构

需要CS架构的系统包括：

空间数据库管理系统，运行维护管理系统，服务调图管理系统。

这三个系统采用数慧DGP3.2平台，作为其基础服务支撑。

图4-9C/S模式的逻辑架构

4.2.开发架构

B/S架构系统开发工具使用J2EE平台以及FlexBuilder开发工具。

C/S架构系统开发工具microsoftvisualstudio以及.netframeworkSDK。

图4-10列出开发架构的核心工程：

图4-10开发架构的核心工程

4.2.1.技术路线

目前Flex技术是当前浏览器端的主流页面开发技术之一，这种技术有跨浏览器，跨平台，界面美观，互动性好等优点。

而B/S架构服务端，Java技术是目前最成熟，稳定可靠的技术，有大量的基础构建可供选用。

因此选用Flex作为B/S客户端的开发工具，Java做为开发技术路线。

B/S选用的公共类库与技术框架包括：

类库名

版本号

说明

JDK

1.5

JavaAPI

FlexBuilder

3.2

Flex开发工具

J2EE

1.4

Java开发平台

其他类库以及框架

上述框架所需要依赖的类库，使用方法请参考相关说明文档。

在C/S架构方面，微软的.net开发平台是主流的开发方式。

根据本系统的实际需求，以及公司已有平台的技术路线，选用了微软VisualStudio2008作为开发技术路线。

选用的公共类库与技术框架包括

选用的公共类库与技术框架包括：

类库名

版本号

说明

.NETframework

2.0

微软标准开发环境。

DeveloperExpress

8.2.2

第三方界面控件库，提供诸如复杂数据网格以及日历等控件。

DGP3.2平台

3.2

基础产品，提供底层的数据访问，通信，框架交互等功能。

其他类库以及框架

上述框架所需要依赖的类库，使用方法请参考相关说明文档。

4.2.2.B/S浏览器端开发视图

4.2.2.1.浏览器端包视图与依赖关系

图4-11B/S浏览器端工程视图与依赖关系

4.2.2.2.浏览器端界面框架开发视图

图4-12界面框架开发视图

4.2.3.B/S服务端开发视图

图4-13界面框架开发视图

4.2.4.C/S架构开发视图

4.2.4.1.服务调度管理

图4-14服务调度管理系统开发视图

Dist.Dgp.ServiceManager.exe为服务调图系统的入口程序模块，设计如下：

图4-15Dist.Dgp.ServiceManager.exe模块图

Dist.Dgp.ServiceConfig.dll是服务调图功能的具体实现工程，模块设计如下：

图4-16Dist.Dgp.ServiceConfig.exe模块图

4.2.4.2.运行维护管理

图4-17运维管理系统开发视图

Dist.Dgp.Builder.exe是运行维护系统的入口程序模块，设计如下：

图4-18Dist.Dgp.Builder.exe模块图

Dist.Dgp.ServiceConfig.dll是运行维护系统的具体实现工程，模块设计如下：

图4-19Dist.Dgp.WebConfig.dll模块图

4.3.运行架构

系统的运行架构表示系统在运行时软件对象之间的交互关系。

对于浏览器与应用服务层和数据服务层的交互，本文通过系统启动时序图和河流污染扩散模型来加以说明。

运行架构更详尽的内容，应体现在具体应用系统开发时的用例时序图中。

4.3.1.系统启动时序图

系统启动时的初始化过程将主要完成以下步骤：

（1）界面端初始化

（2）登录界面的加载；

（3）用户输入用户信息

（4）校验用户身份并初始化系统用户权限；

（5）如果2,3,4步骤已经完成则进入5步骤；如果未完成则等待并重复本步骤；

（6）请求界面内容系信息；

（7）获取界面内容信息；

（8）根据用户权限，加载资源，功能模块；

（9）写入系统成功登陆日志；

（10）展现系统主界面；

（11）系统启动完成。

上述步骤的先后次序如图4-20所示。

图4-20B/S浏览器端登陆时序图

4.3.2.河流污染扩散模型时序图

模型分析是系统功能中比较复杂的功能，它涉及到前端界面，业务逻辑运算，空间数据库访问，地图服务层渲染服务等，是一个比较典型的用例。

所以它为例，说明各层的交互情况：

河流污染扩散模型分析过程主要完成以下步骤：

1.用户在客户端输入模型参数

2.客户端做参数正确性验证，

3.客户端向业务逻辑层发送服务请求

4.河流污染扩散模型服务根据请求参数，通过数据服务层获取数据库中的河流信息。

5.河流模型服务计算事故影响河流

6.河流模型服务计算河流分段；

7.河流模型服务计算河流分段浓度值

8.河流模型服务把计算结果保存到数据库中

9.河流模型服务返回渲染信息到客户端

10.客户端请求地图服务层渲染模型结果

上述步骤的先后次序如下图所示。

图4-21B/S河流污染扩散模型时序图

4.4.数据架构

系统的数据架构主要定义各类数据库的模式（schema），为数据库管理员创建物理数据库提供依据。

数据架构描述了各类数据实体的结构，以及数据实体之间的关系，它实质是系统元数据的一种具体表现。

本系统的数据架构由业务模型数据库、环保空间数据库、系统数据库和三维数据模型组成。

如图4-22所示。

图4-22数据架构视图

其中，业务模型数据库主要包括环境质量，在线监测，污染源信息，环境标准，监测点位信息，移动监察信息等业务数据。

这部分数据可以从其他系统中获取。

系统数据库可以进一步划分为两部分内容：

图形元数据和系统管理数据。

图形元数据包括目录数据，符号数据，图层信息，图层方案配置数据，渲染数据等。

图4-23系统数据架构

环保空间数据包括环保专题数据，主要包括污染源普查信息，排污信息，水，气，声监测点信息，功能区信息等环保业务相关的数据。

作为背景参考的基础地形数据，遥感影像数据，和DEM高程数据等。

图4-24空间数据库架构

4.5.部署架构

4.5.1.系统部署架构

系统部署架构由网络和硬件配置、软件配置、数据库配置和部署规划等内容组成，如图4-25所示。

图4-25系统部署架构内容

4.5.2.部署设计

整个解决方案的部署规划如图4-26所示。

图4-26系统部署规划

地理信息系统服务器组由业务数据服务器，空间数据服务器，地图服务服务器，应用服务器，备份服务器等组成。

业务数据服务器部署系统数据库，业务数据库等；空间数据库服务器存放各种空间数据；地图服务服务器用来发布地图服务和地图运算；应用服务器用来发布系统基础服务，业务服务和界面