气象信息综合服务平台方案.docx

天津市气象信息综合服务平台

软件技术方案

北京航天宏图信息技术有限责任公司文档管理
版本管理
版本
生效日期
变更内容
编制人

文档审批
审批人
职位
签名
日期

目 录
1 概述 6
1.1 项目背景 6
1.2 系统概述 6
1.3 建设目标 7
1.4 设计依据 7
1.5 术语与缩略语 8
1.5.1 术语 8
2 设计约束与要求 11
2.1 设计约束 11
2.1.1 研制方法 11
2.1.2 文档要求 11
2.2 设计约束 12
2.2.1 硬件环境 12
2.2.2 软件环境 12
3 总体需求分析 14
3.1 系统总体定位 14
3.2 系统总体目标 14
3.3 系统主要功能 15
3.3.1 支撑平台 16
3.3.2 发布平台 16
3.4 系统主要用户 16
4 业务模式分析 17
4.1 业务模式 17
4.2 数据流程 18
5 支撑平台需求规定 19
5.1 主要功能 19
5.2 组成与结构 20
5.3 基础支撑模块 20
5.3.1 数据源管理 20
5.3.2 基础数据的综合查询与管理 20
5.4 产品生产模块 21
5.4.1 模型服务管理 21
5.4.2 模型分类管理 21
5.4.3 生产调度管理 21
5.4.4 模型调度监控 21
5.5 模型集成 21
5.5.1 气象灾害风险区划评价模型集成 21
5.6 产品管理模块 23
5.6.1 产品目录管理 23
5.6.2 产品结果管理 24
5.7 服务管理模块 24
5.7.1 服务注册管理 24
5.7.2 服务接口使用说明 24
5.7.3 服务监控模块 24
6 发布平台需求规定 25
6.1 主要功能 25
6.2 组成与结构 25
6.3 发布管理模块 26
6.3.1 发布对象管理 26
6.3.2 产品发布管理 26
6.4 门户功能模块 26
6.4.1 门户网站综合展示 26
6.4.2 门户登录管理功能 27
6.5 产品发布模块 27
6.5.1 Webgis展示 27
6.5.2 图表数据展示 27
6.5.3 文本数据展示 27
6.5.4 分市区县多级发布 28
6.5.5 产品数据检索下载 28
6.5.6 Webservice接口发布 28
7 非功能性需求分析 28
7.1 性能需求 28
7.1.1 支撑平台服务器性能需求 28
7.1.2 发布平台WEBGIS性能需求 29
7.2 稳定性需求 29
7.2.1.1 系统并发执行的考虑 29
7.3 可扩展性需求 29
7.3.1 数据源可扩展性 29
7.3.2 产品生成算法可扩展性 30
7.3.3 产品可扩展性 30
7.3.4 发布对象可扩展性 30
7.4 二次开发能力需求 30

图表目录

图 1系统总体功能结构图 15
图 2系统总体功能结构图 15
图 3业务模式图 17
图 4业务数据流程模型图 19
图 5支撑平台组成与结构图 20
图 6气象灾害风险区划模型集成图 23
图 7发布平台组成与结构图 25

1 概述
1.1 项目背景
天津气象局经过多年积累，形成了庞大的自有数据体系。经过多年连续不断的深入研究和探索，在生态农业、风险区划、灾害评估等方面积累了大量的模型算法；存在着模型繁多缺乏统一管理，模型运行过程人工干预处理多、操作流程复杂、自动化程度低等现实问题。为了解决这些问题，并实现数据调用、产品生产、产品发布过程的一体化管理，搭建一套自动化程度高、可扩展性强的业务平台，满足未来业务发展的需要，提出设计和实现本系统。
1.2 系统概述
系统建设立足现实，着眼未来，以信息化为发展理念与方式，以集约化和标准化为基本要求，采用分布式云计算架构、保持开放式插件化设计理念，本着适应未来业务变化的原则，构建结构完善的、功能先进、服务产品体系齐全、运行高效的平台；系统需要完成的主要工作包括，对多源数据的处理、产品生产模型的管理与调度、和产品的自动发布。基于对系统目标的需要我们将系统分为两个平台
(一) 支撑平台
由于数据的来源不同、种类各异。为了更好地使用数据，需要在基础数据和上层应用之间搭建一个数据服务层。将对数据的各种应用包装成不同数据服务。需要搭建的服务数据主要包括：基础信息数据、基础Gis数据、业务数据等。
平台中首先要实现对多种数据资源的统一管理。对多种数据资源要能够配置各种数据资源；查看数据资源的属性；检测数据的完整性；能够对数据进行管理和修改数据值等。
另外最为基础和产品发布的中间层，需要能够调用服务平台的统一接口，提取数据并进行整理；调用产品生产模型对数据进行加工生成形成最终产品。对于生产模型的调度做到可配置、可管理、可维护。对调度过程和产品结果达到可以监视、可查阅。对产品生产的目录可管理、可扩展。
(二) 发布平台
数据在发布平台的展示主要以传统页面结合WebGis的方式为主。既要能够发挥传统页面对数据内容丰富多彩的展示方式，又要能够通过webGis方式直观的展示数据与地理信息的关系。并且增加传统页面与webGis的交互功能。用户可以通过与webgis的交互，分门别类的查看自己关心的信息；并且可以按照不同角度、不同维度、不同要素对一定时间内数据进行统计，使结果直接反应在webgis上。
发布平台只对指定的发布对象发布产品，发布对象可以横向扩展，可以对发布对象逐级分类。系统管理员可以对发布对象可以看到的产品进行设置，约束不同对象只能看到指定的产品。发布对象也在管理员指定的产品列表中选择自己感兴趣的产品进行定制发布。
系统提供数据的分类查看和下载功能。
1.3 建设目标
系统建设的总体建设目标包括：
Ø 系统可以根据模型自动生产产品。
Ø 产品生产的算法模型可以扩展、编辑。
Ø 产品生产的目录可灵活配置和无限扩展。
Ø 生产出来的产品可以自动发布。
Ø 产品的发布对象可管理可扩展。
Ø 产品对象的浏览权限可以控制，发布对象对可权浏览的产品可选择性查看。
Ø 发布的产品可下载。
Ø 发布形制多种多样，生成的专题产品可按模板配置。
1.4 设计依据
软件设计过程遵循天津气象局客户意愿，系统实现功能依照本文档罗列内容，如有重大调整，双方协调解决。
1.5 术语与缩略语
1.5.1 术语
一、 产品目录
产品目录用来存储通过模块调度生成的产品。产品目录可以动态的添加和修改。产品目录主要定义数据存储规则和存储位置。将要发布的产品从产品目录中自动探测和获取。产品目录包含类别，如：水清。
产品目录可扩展。
二、 发布对象
发布对象是指发布平台的产品的使用者，发布对象由系统添加。 发布对象按照“市级>县级” 逐级添加和管理。
发布对象可扩展。
三、 发布产品
发布产品主要是通过对数据调度指定模块后生成的可发布的产品。发布产品主要包括：
1. 空间信息数据（可以叠加到webgis上）；
2. 按照市>县行政区划或其他行政边界统计的信息（Excel）；
3. 文本信息（一段文字性的描述）；
4. 专题图（产品分析结果图）
四、 用户控制
用户控制是指用户对发布产品的控制。用户控制包括两方面：
1. 省（区）级用户可以指定给不同的地、市级用户生成哪些产品可以供其使用。
2. 地、市级用户可以定义在自己地市级的平台上选择哪些产品对外发布。
五、 发布形制
发布形制主要指以何种方式展示我们的产品。目前可以确定的发布形制有4种：
1. Webgis
2. 图表
3. 文本
4. 动态表达：是指对一定时间内的历史数据有一个连续的动态表达；如播放一个连续的动画。
六、 任务调度
是指对编制好的模型可以按照一定的调度规则定时自动启动，自动完成产品的生产。
任务调度需要定义的内容包括：
1. 调度启动时调用的模型
2. 模型输入参数配置：ａ．可能需要定义基础的来源（如：气象观测数据）ｂ．将基础输入整理成模型可识别类型（如：提取指定要素值与经纬度信息生成新数据）
3. 模型输出参数配置：通过输出配置将模型生成与产品目录关联起来。
七、 模型
模型是指包含了一系列算法的调度序列，调度的每个节点的输出作为下一个节点的输入。模型包括基础模型和复合模型。基础模型是模型编制的基础，需要在系统实现时全部完成。复合模型是根据产品生成的需要在基础模型基础上创建的模型。
八、 业务数据
业务数据是指现有业务环境中已经存在的数据，主要包括：气象观测数据、农业气象数据、生态数据、预测预报数据。
九、 GIS（Geographical Information System）
GIS是由计算机硬件、软件和不同方法组成的系统，该系统设计用来支持空间数据采集、管理、处理、分析、建模和显示，以便解决复杂的规划和管理问题。
十、 空间数据库Spatial Database
空间数据库是某一区域内关于一定地理要素特征的数据集合。具有数据量大、属性数据和空间数据联合管理、数据应用范围广泛的特点。
十一、 WebGIS
WebGIS是指支持在Internet上发布地理信息和服务，而用户可以随时随地获得分布的空间数据和服务的一种技术，它是Web技术和GIS技术相结合的产物。
十二、 矢量数据（Vector Data）
矢量数据通过记录空间对象的坐标及空间关系来表达空间对象的位置。
十三、 栅格数据（Raster Data）
栅格数据以规则像元阵列表示空间对象的数据结构，阵列中每个数据表示空间对象的属性特征。或者说，栅格数据结构就是像元阵列，每个像元的行列号确定位置，用像元值表示空间对象的类型、等级等特征。
十四、 硬件配置项(HWCI)：
为合同要求的独立的系统功能而设计的且能满足最终用户要求的一组硬件。
十五、 计算机软件配置项（CSCI）
为独立的配置管理（技术状态管理）而设计的且能满足最终用户要求的一组软件，简称软件配置项。
十六、 计算机软件部件（CSC）
计算机软件配置项中功能和性质不同的部分。计算机软部件可以进一步分解成其它计算机软部件和计算机软件单元，简称软件部件。
十七、 计算机软件单元（CSU）
计算机软部件设计中确定的能单独测试的一部分程序，简称软件单元。是最低层次的软件成分。例如：结构化编程语言中的函数、子程序，面向对象编程语言中的类等。
十八、 计算机软件模块computer software module
简称模块，按照国家标准的定义，模块指的是逻辑上可以分开的系统成分。泛指逻辑上相对独立的软件成分，如CSCI、CSC和CSU等。
十九、 计算机软件文档 computer software documents
一组数据或信息的集合, 包括计算机软件的列表和打印输出。该文档记录了计算机软件的要求、设计、实现、功能、操作或上述各项的相关细节, 解释了软件的能力和限制条件，并提供了在软件运行中或保障时使用的操作命令。
二十、 非开发软件 non-development software
由承制方、使用方或第三方提供的、而不是按照合同开发的可交付软件。非开发软件按其来源可分为商用软件、可重用软件以及订购方（或使用方）提供的软件。
二十一、 软件工程环境（ software engineering environment）
软件工程工作中所需的一组软件工具、固件和硬件的集合。软件工具可包括(但不局限于)CASE工具、编译程序、汇编程序、连接程序、装入程序、操作系统、调试程序、模拟器、仿真器、测试工具、文档编制工具和数据库管理系统等。
二十二、 软件测试环境（ software test environment）
测试软件所需的一组软件工具、固件和硬件的集合。软件工具可以包括(但不局限于)测试工具, 如模拟软件、代码分析器和测试用例生成器等, 也可能包括包含在软件工程环境中的工具。

2 设计约束与要求
2.1 设计约束
2.1.1 研制方法
要求严格按照《计算机软件工程规范国家标准》的软件工程化方法进行。
2.1.2 文档要求
按《计算机软件工程规范国家标准》确定的取舍与合并原则，产生并交付下列文档：
(1). 软件需求规格说明书；
(2). 软件设计说明书；
(3). 数据库设计说明书；
(4). 系统用户手册（包括：操作员手册和系统维护手册等）；
2.2 设计约束
2.2.1 硬件环境
cpu：4核以上
硬盘：200G以上
2.2.2 软件环境
(1). 操作系统：
Ø 支撑服务器由高可靠的Windows服务器组成；
Ø WEB服务器由Windows服务器组成，应用服务器使用Tomcat；
(2). 开发环境和程序设计语言：
Ø Windows平台配置JAVA语言和工具。
(3). 数据库系统采用Oracle 10g 以上数据库管理软件，满足以下要求：
Ø 支持流行的软硬件平台（PC服务器及Windows Server操作系统环境）；
Ø 支持客户机/服务器技术、浏览器/服务器技术；
Ø 支持异种数据库的互连，平滑实现数据的互操作；
Ø 支持大量的联机用户并发操作；
Ø 具有C2级以上数据安全控制机制和权限控制，支持多种数据备份方式；
Ø 多种数据库开发机制，具有开发三层结构、客户/服务器结构应用的工具；
Ø 具有在线备份和在线恢复功能；
Ø 配置相应的应用服务器与开发工具等软件。
(4). GIS平台支持
Ø Arcgis10.0以上版本Arcgis软件。
Ø 具备海量数据处理能力；
Ø 具备海量数据发布能力；
(5). 支持群集系统负载平衡。

3 总体需求分析
3.1 系统总体定位
系统的总体服务对象为省内的各级气象部门，包括：市、区、县的气象部门；各有关单位，包括水利厅、林业局、减灾处等多个部门。系统以各种气象相关基础数据及各级产品数据为基础构建数据及产品的服务平台。系统用户可以以不同形制浏览产品级数据，可以通过一定途径下载数据和产品。系统的总体定位为服务于天津各级气象部门及相关部门的产品和支撑平台。
3.2 系统总体目标
系统以java作为基础开发语言，在系统安全、稳定的基础上，实现一套可以管理多种数据资源，能够按照一定规则自动生产产品并自动发布的一套系统。
(一) 搭建能够处理多种数据资源，能够提供多种整合的数据检索、数据提取、数据分享的服务平台。
ü 构建支撑气象专业服务的数据库体系。
ü 建立灵活的数据拓展及接入框架。
(二) 建立兼容多种格式的产品及信息产品统一发布平台。
ü 发布对象的管理和无限可扩展框架。
ü 构建发布产品的定制化发布体系。
ü 建立面向webgis的一体化农牧气象产品服务框架。
(三) 建立产品可自动扩展、自动化生产的支撑平台。
ü 构建实现产品目录无限扩展框架。
ü 实现产品计算模型的调度及管理框架。
ü 实现调度任务的监视、控制、及产品结果浏览的框架。

3.3 系统主要功能
基于对系统目标的需要我们将系统分为两个软件平台配置项：支撑平台、发布平台。平台结构功能图如下：

图 1系统总体功能结构图
3.3.1 支撑平台
数据是整个平台的基础，平台在数据和上层应用之间搭建了一座桥梁。通过平台上层应用按照统一的接口调用下层数据。通过平台提取底层数据，按编订的规则调用产品生产模型，生产产品并按照规则存储。平台的主要功能包括：
一、 实现数据资源的动态注册。
二、 实现对平台接口的统一管理。
三、 在平台内部能够实现各种数据类型的转化。
四、 提供统一的数据存取接口。
五、 管理产品目录及存储规则。
六、 配置产品生产模型的调度规则；实现模型的自动调度。
七、 对产品生产过程进行监控。
八、 对产品生产结果进行查看。
3.3.2 发布平台
发布平台是整个系统对外发布数据和产品的窗口和途径。产品的发布主要有三种方式：通过页面浏览以http方式发布；通过webservice接口方式获取结构化的数据。发布平台的主要功能包括：
一、 可以扩展发布对象并可对其进行管理。
二、 对产品发布可实现双向控制。
三、 具有可以按照多种形制发布产品的统一发布界面。
3.4 系统主要用户
(一) 天津省局用户
天津省局用户的职责主要是对系统运行的各个方面进行管理。主要权限包括系统参数配置、数据及产品的管理、产品生产过程管理、专题模板管理等。
(二) 产品发布对象
产品发布对象包括气象系统内部的下级（县）部门和有一定浏览需求的兄弟部门（如：林业局）。每类产品发布对象内都包含一个管理角色和任意个浏览角色。
Ø 发布对象中的管理角色：主要职能是定义本类发布对象内的用户可以浏览的产品。如：县管理员可以限定本县用户可以浏览的产品列表；林业局管理员可以定义林业局用户可以浏览的产品。
Ø 一般浏览者：只具有筛选产品、浏览数据和下载数据的权限。
4 业务模式分析
4.1 业务模式
系统运行过程中两个平台及一些外部软件或系统互相协作。形成如下业务模型：

图 2业务模式图
产品生产的主要过程如下：
1) 首先在支撑系统的后台进程按照定制的规则自动完成“产品生产的自动化调度”。
2) 产品的执行过程启动后首先加载“生产模型”和“产品存储逻辑”。
3) “生产模型”执行数据提取算法从支撑平台提取数据，进行数据加工。
4) “生产模型”执行数据存储算法将产品按照规则存储到指定目录，同时“产品生产的自动化调度”模块将生产的产品信息记入产品库。
5) 发布系统检测产品及产品库获得需要发布的产品的信息进行多种形制的发布。同时发布平台可以调用支撑平台接口对底层数据进行发布。

4.2 数据流程
整个平台以数据自动处理、产品自动生成和产品自动发布为基础目标构建。整个过程包括数据准备阶段、产品生产阶段和产品发布阶段。
准备阶段包括基础数据源的准备，数据服务准备，调度模型的编制，生成专题图的模板的准备等。在产品生产阶段通过任务调度、订单处理、根据产品目录设计和生产规则设置生产产品；并对生产过程实施监控，可以对生成过程和生产结果有直观的检查和查看。在产品发布阶段通过产品的发布设置发布产品，并通过专题图模板设置动态生成专题图。最终用户可以通过发布平台查看gis形式产品、专题图产品、文档产品数据和统计产品数据等，并且可以以动画形制查看一段时间内数据。
主要流程说明：
1. 搭建支撑平台，通过服务接口对外提供数据服务。
2. 数据转换与提取模块通过数据服务接口整理数据。
3. 数据格式化与任务调度模块将数据整理成统一格式，调用gp服务。
4. 模型按照编制情况执行，生产大量中间数据。
5. 产品生产模块按照产品生产规则生产最终产品。
6. 管理员可以通过产品生产监控功能监控产品声称情况。可以产出或重新生产产品。
7. 产品自动发布模块根据产品发布设置自动将产品数据对外进行发布。
8. 最终用户浏览结果成果。

图 3业务数据流程模型图
5 支撑平台需求规定
5.1 主要功能
支撑平台的主要功能是管理基础数据、对各类数据能够相互转化、能够为GP模型提供基础的数据服务、能够稳定有效的生产产品、能够对产品的生产过程和产品结果进行管理。
5.2 组成与结构
服务注册管理
服务监控管理
服务管理模块

支撑平台
基础数据管理模块

数据源管理
基础数据综合查询与管理

模型服务管理
模型调度监控
产品生产模块

产品管理模块

生产调度管理
模型分类管理
产品目录管理
录管理
理
生产结果管理
服务接口使用说明管理
说明服务监

图 4支撑平台组成与结构图
5.3 基础支撑模块
5.3.1 数据源管理
数据源是整个系统运行的基础。数据源管理的主要功能是管理基础数据资源。通过对数据资源的维护实现后续数据抽取、转化、整理等功能的自动化完成。
5.3.2 基础数据的综合查询与管理
基础数据的综合查询与管理功能主要是对基础数据能够直观的浏览，及对某些数据进行校正。通过对基础数据的查看可以验证生成产品的准确性，保准发布产品的正确性。
5.4 产品生产模块
5.4.1 模型服务管理
产品的生产模型是整个系统运转和调度的核心。产品的生产模型建立好以后需要发布成模型服务工调度中心调度。模型调度管理实际是将建立好的模型服务注册到整个平台，成为平台可识别、可调用的一部分。服务模型管理定义了模型的类型、名字、如何调用、输入输出等信息。
5.4.2 模型分类管理
模型分类管理实际是将建立好的模型服务进行分类维护，方便查找维护。
5.4.3 生产调度管理
生产调度是产品生产的核心组件。通过生产调度实现底层数据提取、生产算法自动调度、和产品结果输出的一系列工作。产品调度管理需要定义：以什么样的频率、调用哪些算法、使用哪些数据、产品如何输出等要素。
5.4.4 模型调度监控
模型调度监控主要是对产品生产的调度过程进行监控。通过该功能需要能够了解到何时进行了产品生产、生产过程是否顺利、以及能够知道单次生产产品的数量和生产过程失败的原因。
5.5 模型集成
5.5.1 气象灾害风险区划评价模型集成
气象灾害风险区划评价模型的处理流程较为复杂，首先需要是多源数据的收集机整理工作。来源主要有：天津全市历史气象灾害灾情数据；近几年天津市气象观测数据；基于高分辨率的Landsat 8数据，通过RS技术获取的高精度的天津市土地利用分类图；收集、整理的全市自然环境、经济概况、产业布局、交通、水利、农业等数据。
在获取上述数据后，通过GIS技术，对数据进行格式转换、投影变换等方便后续空间分析处理。
接着依托GIS技术支持，运用层次分析法和专家打分法等数量化方法，通过对四个方面的气象灾害风险区划的评价指标（致灾因子危险性、承灾体潜在易损性、孕灾环境敏感性以及防灾减灾能力）进行详细分析，建立合理的天津市气象灾害风险评估模型。模型技术流程图如下图所示
模型产出得到成果是：
l 全市各种气象灾害风险区划图
l 各区县各种气象灾害风险区划图
气象灾害风险区划评价模型系统集成的业务流程图如下：
图 5气象灾害风险区划模型集成图
5.6 产品管理模块
5.6.1 产品目录管理
产品是整个系统的最终结果。系统最终将生产哪些最终产品，这些产品按照何种方式存储，如何了解每种产品的信息等信息通过产品目录管理功能定义。产品目录管理的功能目的就是分门别类的管理产品信息。
5.6.2 产品结果管理
产品结果管理主要是按照产品目录层级能够浏览系统生成出来的产品结果，并可以对产品结果进行查看或删除。
5.7 服务管理模块
服务管理模块主要是管理服务的基本信息以及定义服务的有效性等。还包括对服务使用情况的说明与展示。
5.7.1 服务注册管理
服务注册模块的主要功能是将经过开发和严格测试的服务纳入到支撑平台的管理体系。在服务注册的过程中需要定义服务的类型，调用方法、接口位置与参数说明。
5.7.2 服务接口使用说明
这是服务平台对外公布服务信息的窗口。服务的使用者可以通过服务接口信息查看功能了解到服务使用的各个细节，了解到服务实现的内部逻辑，如何与该接口进行通信，以及接口调用的异常处理等信息。
5.7.3 服务监控模块
服务监控模块主要功能是了解服务的使用情况。根据服务监控模块反应出来的信息需要具备一定的服务优化能力。

6 发布平台需求规定
6.1 主要功能
发布平台的对整个系统对外发布和分发数据的窗口。发布平台以基础http方式，结合webgis方式与webservice方式对外发布数据。发布平台需要能够提供多种发布策略，以多种发布形制发布数据；并能够灵活的扩展发布对象，定制发布对象产品权限。发布平台整体要求美观、大方、高效、易用。
6.2 组成与结构
发布平台的功能组成结构如下：
发布平台
发布管理模块

门户功能模块
产品发布模块

门户网站综合展示
门户登录管理功能
发布对象管理

产品发布管理

Webgis展示

图表数据展示

文本数据展示

产品下载

分省市县多级发布
Webservice接口发布

图 6发布平台组成与结构图

6.3 发布管理模块
6.3.1 发布对象管理
发布对象的使用者是系统的管理人员。发布对象是指产品生产结果的最终使用用户。对发布对象的管理主要包括以下两个方面：
一是管理人员对发布对象可扩展。主要包括发布对象的添加、修改和删除操作，以及发布对象基本信息的维护。
二是管理人员对发布对象可使用的产品权限的管理。主要功能是将发布对象与产品目录联系起来。为每个发布对象指定产品使用权限。
6.3.2 产品发布管理
产品发布管理的使用这是发布对象。发布对象在登录进入系统后可以根据自身需求对管理员分配的具有权限的产品进行二次筛选。定义自己在进入系统后具体展示的产品。发布对象定义的最终使用的产品是产品发布对象管理里管理员分配的产品列表的子集。
6.4 门户功能模块
6.4.1 门户网站综合展示
门户网站首页是系统的前段入口，通过门户首页将系统内重要信息进行集中展示。其次门户首页还将是其他平台或模块的直接入口。
通过门户首页终端用户可以对整个系统有直接认知：
1. 能够了解到系统能够提供的功能和服务。
2. 能够直接浏览系统最核心产品。
3. 能够由此逐级进入各产品和服务页面。
4. 能够了解系统功能变化动态，产品和服务变化动态。
5. 能够了解系统的使用方法。
6. 能够由此登录系统。
6.4.2 门户登录管理功能
门户登录是面向发布对象的功能，也是发布平台管理人员进入后台系统的入口。门户登录功能向各级发布对象提供友好的登录界面，并提供友好的登录失败反馈。
6.5 产品发布模块
6.5.1 Webgis展示
Webgis展示功能是将传统网页技术与gis技术相结合。通过webgis技术用户可以在web页面上得到和操作gis软件相同的操作体验。可以直观的浏览产品或数据在地理信息层面的信息。
Webgis展示主要提供：
1. 基础地理信息展示。
2. Gis数据和产品的影像叠加。
3. 无极放大、缩小与漫游。
4. 使用者与展示界面进行交互和数据反馈。
5. 具备一定的空间分析能力。
6.5.2 图表数据展示
图表数据是系统在生产产品是生成的统计数据或专题图数据。用户在使用是通过产品检索或的相应的图表信息列表，检索结果通过图表数据展示功能进行展示。
6.5.3 文本数据展示
文本数据是管理人员或系统业务人员对某类产品某一时次数据的总结性描述。在用户查询到数据时系统同时检索相应的文本描述结果，并进行相应的展示。
6.5.4 分市区县多级发布
分市区县多级发布主要是指根据发布对象的管理后，不同等级的用户进入系统后可以直接呈现不同级别的数据和产品。
6.5.5 产品数据检索下载
用户在浏览数据和产品是可以根据需要输入一定的参数对数据和产品进行检索。对检索到的结果可以直接查看，也可以对检索到的数据和产品结果进行下载。
6.5.6 服务接口发布
我们的系统除了提供通过页面浏览和获取数据外，还需要提供能够对外提供数据的webservice接口。其他软件或系统获得我们的授权以后可以通过调用我们提供的接口下载数据。数据将重点以结构化的数据为主，主要提供文本、json、xml格式的数据。
7 非功能性需求分析
7.1 性能需求
7.1.1 支撑平台服务器性能需求
从业务角度来说，支撑平台服务器完成数据到达监听，数据的自动预处理、产品自动生产、专题生产的全部工作。各个环节都要考虑一定的性能需求。对于支撑平台软件设计性能方面需要达到如下要求：
(1). 服务器总内存占用不超过用户预期。
(2). 该服务器能同时生产多种产品，运行性能不应受到明显影响。
(3). 要求服务器能够长时间连续无故障运行。
(4). 在后台进程大量执行过程中前台管理功能不受影响。
(5). 要求产品文件数目的增长不对文件检索时间产生显著影响。
(6). 内部功能模块之间的异步消息传递时间延迟不影响系统运行。
7.1.2 发布平台WEBGIS性能需求
就整体架构而言，发布平台使用WEB方式作为主要的用户界面。观察形式可能是矢量图形、数据统计图表、人工分析文本、一定时间的动态数据等，而且这些数据都需要和地理信息结合到一起以提高直观性和关联性，所以对发布平台来说需要解决WEB应用中嵌入GIS功能和图像图形渲染功能。发布平台webgis需要达到如下性能要求：
(1). 支持栅格数据和矢量数据的WEB显示。
(2). 要求对于矢量数据实现浏览器端绘制以提高效率。
(3). 浏览器的地图操作响应无迟滞感（在带宽充足的条件下）。
(4). 对于栅格数据采WEB实现加载时要求无明显拼接现象。
(5). GUI平均操作响应时间没有明显延迟。
7.2 稳定性需求
7.2.1.1 系统并发执行的考虑
支撑平台服务器为典型的多进程应用。其处理过程和数据相对较为复杂，接口较多，在设计过程中应采用适当架构和设计方法提高其稳定性。从架构角度应采用成熟的服务器设计模式兼顾复杂性和灵活性。从代码编写角度对关键部分编写防护性代码、减少使用指针等方式提高系统运行的稳定性。
7.3 可扩展性需求
7.3.1 数据源可扩展性
根据业务发展需要可能面临着需要接入更多的数据源，所以系统需要支撑数据源的可扩展性。在系统运行过程中可以动态的添加数据源，添加好的数据源可以通过支撑平台提供数据服务。提供的数据服务可以顺利进入产品生产流程生产响应的产品，并实现自动发布。
7.3.2 产品生成算法可扩展性
产品生成的中间算法需要符合arcgistools接口规范。中间算法可以按照一定的形制进行编制。只要是编制好的符合规范的模型系统都需要支持，可以进行动态调用。
7.3.3 产品可扩展性
产品的生产和发布是系统创建的最终目的。由于产品结果随时间的推移具有一定的可变性特点。所以系统需要按照生产和发布规范支撑符合规范的所有类型产品的生产的发布。在系统运行过程中需要能够按照用户的想法支撑产品的可扩展性需求。
7.3.4 发布对象可扩展性
产品在对外发布的过程中可能需要对产品的使用对象不断扩展，所以需要对发布对象具有可扩展性。
7.4 二次开发能力需求
根据系统总体架构及提供的接口用户可以扩展更多的产品。