环境监测信息系统总体设计方案.docx
《环境监测信息系统总体设计方案.docx》由会员分享，可在线阅读，更多相关《环境监测信息系统总体设计方案.docx（73页珍藏版）》请在冰豆网上搜索。
环境监测信息系统总体设计方案
环境监测信息系统
总体设计方案
引言
1.1设计思想
首先将其定位为“GIS应用系统”。
本系统不是一个简单的GIS系统，系统不但包括环境监测的各个业务系统，还包括电子化文档流、任务流程管理控制等不同的管理功能。
其次，业务的可控性目标将贯穿整个系统，这是区别于一般GIS应用系统的特点之一。
许多GIS应用系统简而言之仅仅是一个空间分析并提出决策的系统，需大量的现成数据支撑。
而该环境监测信息系统具备了实时监测并把记录存储在数据库中的功能，可以实时进行数据的分析并提出决策。
第三，系统具有完善的质量体系程序文件作为依据，因而具有业务的规范性。
1.2设计背景
目前，国内许多环保机构在进行环境质量分析时主要依赖图纸；即便使用管理信息系统也只是面对空间对象的属性数据，这导致了空间信息与属性数据的分离，造成了分析和管理上的不便，增加了工作的冗余量。
因此，建立一个支持环境监测信息管理和分析的地理信息系统是环境监测部门信息化管理的必然发展趋势。
一些国家已经在这方面取得了一定的成果，利用地理信息系统强大的空间分析、空间查询以及空间数据管理功能提高环境监测工作的工作质量和工作效率。
国内的环保部门和相关研究人员也已经意识到并开始着手建立有效的环境监测信息系统。
1.3参考文献
[1]GBT18578-2001城市地理信息系统设计规范国家标准
[2]国家空间数据基础设施的标准与规范
[3]国家基础地理信息系统元数据标准（草案）
[4]工程地理信息系统软件通用标准（中华人民共和国国家标准）
[5]《地理信息国家标准手册》
2系统概述
2.1系统设计原则
本项目的设计以需求为导向，尽量收集用户的要求，采用构件的设计思想，便于系统功能的重组和扩充。
系统采用“总体规划、分步实施”的策略，第一步完成通用控制页面的设计，接下来完成常用的后台服务程序的开发，最终达到实现质量体系的目标。
为保障项目的各项性能，本项目在设计和实施过程中应遵循如下的原则：
实用性：
充分考虑到环境监测管理与决策的实际需要，设计方案留有一定的余地，即在设计中构造明晰的体系结构，便于更改；完全根据实践进行软件设计，达到实用的目的。
可扩充性：
采用面向对象的设计思想和开发技术以及组件设计思想，保证在用户的需求发生变化和增加时，使系统的修改量减到最小。
开放性：
由于本系统涉及许多硬件设备和外部应用软件，为了更好地和各种硬件设备和应用软件接口，在设计时，应提供主要的接口标准。
标准化：
在系统总体规划设计中，所有软、硬件产品的选择必须选择符合开放性和国际标准化的产品和技术；在应用软件开发中，必须遵循总体组制定的各项规范和要求，还要接受公司的质量保证部的监控。
安全与保密：
系统设计时应充分考虑系统的安全，提供备份的功能，保证当系统出现硬件或软件的故障时，能进行恢复；另外，应对用户进行权限管理，保证信息的安全。
以数据为中心：
本项目采用以主题数据库为中心的设计思想，首先把本项目的主题数据库设计出来，再在此基础上开发各种应用。
由于主题数据库是项目的基本信息资源，它具有很好的不变性和稳定性，相对独立与具体的应用，当用户的需求发生变化时，使修改量减到最小。
2.2系统目标与运行环境
2.2.1系统目标
环境监测信息系统的目标是用计算机对影响环境状况的各种要素进行分析，而且能通过污染源、监测点的详细资料，对整体环境的状况进行分析、监测，使环境管理部门从日常繁重的图数查询和手工分析、制图的工作中解脱出来，使管理者有充裕的时间去进行环境污染源的监督、查处、环境监测计划的实施意见环境规划的制度等工作。
2.2.2运行环境
服务器：
CPU：
4核3.0G以上
内存：
4G
硬盘：
500G以上
网络：
100M/1000MEthenet
客户机：
CPU：
2核2.0G以上
内存：
1000M以上
硬盘：
300G以上
操作系统：
Windows系列之一
浏览器：
IE7.0以上版本
网络：
100M/1000MEthenet
操作系统：
Windowsvista/7
WEB服务：
IIS5.0
数据库：
MySQL
2.3需求分析
2.3.1功能需求
在环境监测信息系统中，主要有地图操作、地图编辑、专题制图、数据输出、空间查询、空间分析等功能。
功能分析如下：
（1）地图操作：
可对地图进行任意放大、缩小、漫游、复位等操作，并可通过鹰眼定位显示区域。
并且可以进行图上测量，用户根据需要可在电子地图上量算任意两点间的距离或任意区域的面积。
（2）地图编辑：
可在电子地图上对新点位信息进行增加、删除、修改、存储操作，属性数据保存在后台数据库内。
（3）专题制图：
图件可以以任何地点为中心，比例尺任意，使用突出效果的特殊字符有效地显示所选择的信息。
例如，可以制作质量功能区划，酸沉降临界负荷分布，环境背景，污染源分布等环境专题地图。
（4）数据输出：
可生成布局窗口：
包括各专题图层的输出、查询和统计结果的图层和表格输出。
并可将已生成图转换其他文件格式。
表格可以另存为文本格式。
（5）空间查询：
可以进行空间图形与属性的相互查询，点击地图图层上的点、线、面各要素可弹出其属性信息表，并可以选取希望列出的属性信息库字段。
输入数据库字段（精确及模糊）可在地图上显示查询结果。
对点、线、面要素周边地区进行查询。
对于点：
以点为中心的圆形或矩形区域；对于线：
以线性要素为中轴的矩形区域或包括以两端结点为圆心的半圆在内的胶囊型区域；对于面：
与其边界等距离的外环区域。
以上各项根据情况可手画或选择数值定义实际距离。
2.3.2性能需求
（1）系统易操作性
所开发的系统应做到操作简单，尽量使系统操作不受用户对电脑知识水平的限制。
（2）系统具有可维护性
由于系统涉及的信息比较广，数据库中的数据需定期修改，系统可利用的空间及性能也随之下降，为了使系统更好地运转，使用者可以对系统数据及一些简单的功能进行独立的维护及调整。
（3）系统具有开放性
该系统能够在开放的硬件体系结构中运行，并且能与其他系统顺利连接，不会因外部系统的不同面要做在量的修改工作。
2.3.3数据要求
本系统的数据类型多样，根据设计要求需要数据类型主要如下：
（1）污染源数据以及污染源汇总数据
（2）各种环境要素的监测数据
（3）污染物代码、环境标准数据及系统所需的其他数据
（4）基础地图和环境专题图数据
3系统总体设计
环境监测系统将采用通用的开放操作系统和开发平台，确保该软件的通用性和可扩充性。
考虑到该系统的主要功能是实现对环境质量的管理和对周围环境的保护，即将环境部门主要日常工作的质量管理活动及实时提出保护决策实现程序化，并最终设计出完全符合环境部门功能需求的软件。
因此，在兼顾系统的稳定性、实用性、可扩充性的情况下，考虑采用成熟的系统体系结构和开发方式保证系统的稳定性；完全依托软件工程的质量体系手册进行各功能模块的设计来保证系统的真正实用性；同时考虑采用新颖的服务器端编程方法具体实现该系统对主要业务的控制要求以保证软件的可扩充性。
环境监测系统将为环保部门对环境的管理的实现提供完整的功能，不仅实现污染源管理、监测数据分析，还将实现总量预测和监督管理的体系化和电子化，实现任务流的生成和控制以及网上信息发布等。
本系统实现了：
●实现业务管理与监督管理的结合；
●实现了从监测——分析——预测的统一平台的管理；
●实现网络信息发布与实时分析决策的同一性；
●提供系统的可扩展性，即保证各种新增业务方便的电子化管理新需求的接口；
●保证该系统的稳定性要求，即所有数据集中统一管理在后台数据库中，防止数据的丢失；通过统一的开发平台和通用的开发软件，保证系统的通用性。
●采用B/S/D架构的成熟技术，可做到兼顾灵活性和稳定性的要求
3.1系统物理结构
3.1.1系统流程图
图表1环境监测信息管理一层数据流图
图表2环境监测信息管理二层数据流图
3.1.2技术要求
根据系统定义，要达到系统目标和功能需求，本系统必须达到以下技术要求：
首先，各部门用户通过计算机网络实现数据的互通和共享，业务流程规范、合理；其次，多用户数据并发编辑：
通过空间数据图层级上锁、属性数据记录级上锁的方式，获得授权的各部门用户可同时对空间地图数据和属性数据进行建设、编辑和维护。
其他用户可通过刷新来获取更新的数据，极大提高了数据更新和维护效率；再次，对海量图库的高效管理和模糊查询定位：
系统继承地理信息系统平台的特点，具有强大的空间数据管理能力；同时能在大面积的底图中迅速的对符合条件的图件进行定位查询，可浏览该图件的属性和参数；最后，强大的统计功能和完善的分析能力：
系统能够根据污染源的历年资料进行污染源排序，并可以对污染源资料和监测资料进行分类和统计，以多种统计图的形式进行输出。
同时系统能够提供对包括工业三废和噪音、空气污染在内的各种污染物的分析，提供完整的分析图表，并且实现表格中的监测点和底图位置联动浏览。
3.1.3系统体系结构
根据系统定义中建立的数据流图，采用自顶向下的设计方法，逐步建立系统结构。
3.2子系统功能描述及实现
3.2.1系统总体结构
环保信息系统由四个子系统组成：
污染源管理系统、监测资料分析系统、总量控制系统以及监督管理系统。
3.2.2子系统结构
（1）污染源管理系统
污染源信息是环境信息的核心部分。
污染源管理子系统包括污染源信息输入、污染源信息查询、污染源历年统计分析、污染源缓冲分析和等标负荷分析等模块。
本系统利用GIS技术将污染源数据库管理系统和图形库管理系统结合，提供具备空间信息管理、信息处理和直观表达能力的应用软件。
并且实现污染源信息的编辑和综合查询，以及环境情况综合分析，为有关的评价、预测、规划等决策提供信息支持。
该子系统提供污染源数据导入接口，支持各种标准的数据格式。
并且同时与总量控制模块和监督管理模块之间有数据接口，分别向它们提供分析结果。
（2）监测资料分析系统
监测资料分析系统不断采集和更新监测资料，并根据监测点资料，对当前区域内造成的环境质量变化进行分析，可以输出各种专题地图和表格。
该子系统包括监测点信息输入、监测点信息查询、等值线分析、噪声分析、空气质量周报和水质分析等模块。
该子系统也提供各种标准数据接口，接受外部监测点数据。
同时也提供与总量控制模块之间的接口，向该模块提供分析结果。
图3、图4为监测系统的定义：
图表3监测系统的定义
图表4监测系统的数据传输
（3）总量控制系统
通过各种总量控制计算模型，总量控制系统根据监测点资料和污染源资料分析出当前的环境容量，工作人员结合企业的实际情况，提出具体总量控制方案。
该子系统包括水环境容量分析、大气污染物排放控制和固体废物总量控制及评价系统等模块（见图5、6、7）。
该子系统与其他三个模块之间均有数据接口，分别用于接收污染源管理模块和监测点分析模块的分析结果，以及向监督管理模块提供总量控制分析及评价结果。
（4）监督管理系统
根据以上三个模块的分析结果，结合实际情况，相关工作人员可以利用监督管理系统的帮助向社会提供计划与决策信息。
该子系统包括建设项目、排污申报、行政处罚和行政复议模块。
该子系统提供文字编辑、报告模板和工作流等功能。
该子系统与污染源管理模块和总量控制模块之间有数据接口。
自然经济社会
污染源、水利工程设施
监测数据
数据库模型库
知识库、方法库
工程信息、位置、基础工艺、性质、规划、污染种类
排放方式、治理措施
大气模型
地下水模型
过程模拟地表水模型
生态响应模型
噪音模型
土壤模型
单项指标法
影响评价评价方法综合指标法评价指标体系
供求平衡法
经济因素分析
评价结果
图表5评价系统的业务流程
图表6环境监测信息系统管理模块
3.3各子系统功能模块的实现
3.3.1信息输入模块
选择主窗体中各子系统信息模块下的信息输入，就可进入添加各子系统的模块信息，在该窗体中我们可以对污染源的属性信息、监测资料监测数据、大气污染物排放信息、排污申报等信息进行添加。
设计时尽可能设想各种边界条件，如记录为空，输入为空，输入出错等，当输入的信息满足这些边界条件时，将会弹出一个提示框提醒用户，以便用户能及时地做出修改。
添加的信息将全部存储到数据库中。
在窗体上放置多个文本框和下拉式文本框，用来输入信息；两个按钮用来确定是否输入信息；一个按钮用来退出窗体；多个标签用来提示文本框中需要输入的内容。
3.3.2信息修改模块
点击各子系统相应信息管理模块下的修改信息，就进入修改信息的窗体，在该窗体中我们可以对前面添加的各种信息进行修改。
由于用户的需求不同，有的是要对污染物的信息做个别的改动，有的是需要删除该条记录，所以该窗体同时包括了修改记录的功能和删除记录的功能。
3.3.3信息查询功能
进入各子系统相应信息管理模块下的查询信息窗体，在该窗体中可以对需要的信息进行查询。
在设计时，一方面考虑到简洁的因素，用户可以只设置一种查询方式进行查询；另一方面又为了避免数据的重复，用户可以输入详细的信息，也就是同时设置多种查询方式进行查询。
进入查询窗体时，窗体中会显示出所有信息，如果不设置查询方式就进行查询，是无效查询，系统会给出提示。
在设置好查询方式后，便开始查询，将在查询窗体中显示出用户所需的信息。
3.3.4信息分析功能
点击各子系统相应信息管理模块下的信息分析，进入分析信息窗体，在该窗体中可以对污染源进行缓冲分析和等标负荷分析；对历年统计资料进行统计分析；对监测资料进行等值线分析、噪声分析等操作。
由于用户和分析对象不同，可以设置不同的分析属性，来得到不同德分析结果。
3.3.5信息输出功能
进入各子系统相应信息管理模块下的信息输出窗体，可以输出各种用户所需要的数据。
在这个窗体中我们可以输出污染源影响图，监测资料等值线图以及监测资料文本数据等数据。
考虑到用户所需数据的格式多样性问题，点击数据输出设置下拉文本框，设置好数据格式后就可输出数据。
3.3.6其它功能
用户或操作人员在遇到困难时即可进入帮助菜单寻求帮助。
帮助菜单下的“使用说明”将解答你的疑问。
帮助菜单下的“关于”详细地列出了关于作者的一些情况，关于版权的一些情况和关于系统的一些情况。
图表7评价模型库
图表8环境监测信息系统中的建模模块
3.4软件结构图
3.4.1应用软件的设计思想
环境监测系统的主要组成从软件实现上可分为四部分，即环境监测前端、环境管理前端、环境预测前端、环境监督前端；从系统架构上可分为三部分，即应用程序客户端、网络应用程序和数据后台。
软件设计采用三层结构的设计方法，即通过服务器层实现应用前端与后台数据库的数据共享，通过JSP语言和相关的小服务程序以及XML电子数据交换格式实现网络形式的新形态企业综合管理系统。
3.4.2软件系统总体架构
图表9软件系统构架
图表10软件建模模块
软件子系统如上图所示，其主要特点是：
统一的数据存储。
后台小服务程序为本系统的主要功能部件，而Applet技术与HTML语言的结合确保了整个应用程序的可视性和美观性。
多种网络技术的结合使用，既综合了不同方法的优点加以使用，又避免了各种方式的自身缺陷，保证了系统的实用性和可扩展性。
4开发过程
4.1系统开发环境
模块
开发环境
负责编写人员
备注
污染源管理
Vb6.0
小组一
有很强的数据收集功能
监测资料分析
Vb6.0
小组二
强大的数据分析及查询功能
总量预测
Vb6.0
小组三
提供多种数学模型
监督管理
Vb6.0
小组四
丰富的专家知识
图表11系统开发配置表
4.2总体进度计划
里程碑事件
2010年
2011年
5
6
7
8
9
10
11
12
1
2
1
总体计划
▲
2
需求分析
▲
▲
3
软件初次评审
▲
4
编码测试
▲
▲
5
模块的接口优化
▲
6
整个项目的整合
▲
7
试运行预验收
▲
8
软件系统交付
▲
9
正式验收
▲
▲
10
系统正式运行
▲
图表12总体进度计划表
4.3经费预算
人员成本
周期为10个月
日常生活
交通补助
资料
工资
奖金
合计
50
10
100
3000
1000
312600
60000
12000
600
180000
60000
设备成本
笔记本电脑
服务器
路由器和交换机
其它
47000
5000
10000
2000
3000
6台
1台
2部
图表13经费预算表
5软件设计标准
5.1用户界面
图表14用户主界面
5.2硬件接口
说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。
说明本系统之内的各个系统元素之间的接口的安排。
5.3系统架构
环境监测信息系统的主要对象是污染源及监测管理到评价建模体系的实现，通过对环境监测日常业务的质量管理的实现，建立完整的后台数据中心，为环境监测信息系统的质量管理标准化、规范化提供帮助。
5.3.1B/S/D架构的优势
环境监测信息系统系统包括的主要内容为：
污染源管理系统、监测信息分析系统、总量预测系统、监督管理系统。
作为行政Intranet的主要应用系统，该系统的主要架构设计为B/S/D架构，以下将比较其与其他架构的优劣。
C/S结构的限制
网络应用绝大部分都可分为以下四个层次：
表现层、事务层、数据逻辑层和数据存储层。
在C/S结构中，表现层和事务层都放在客户端，而数据逻辑层和数据存储层则置于服务器端。
这种组织安排带来诸多的限制：
1、客户端很庞大，以致于应用程序升级和维护时十分困难且耗资很大：
如对应用程序一个小小的改动，就必须通知或亲临每一个客户端去更新；新增或升级一台机器，都要把应用及其相关的文件安装在客户端上。
在环境监测信息系统综合科研管理系统中有大量的客户端，可以想象维护的工作量有多大。
2、事务层不能与跨平台的客户端共享。
3、孤立了不同的逻辑组件。
4、没有统一的数据逻辑层来提供不同种类的数据存储层。
5、C/S组织结构不支持Internet。
C/S与B/S混合结构的不足
不可否认的是C/S与B/S混合结构确实适于一些企业组织其应用管理系统，但总的来说，其适用范围是有限的。
1、大多数的C/S与B/S混合结构的选择实际是在原有C/S架构上的Web应用升级，而在B/S结构已可替代大多C/S结构功能的今天，创建单一的架构显然更有利于系统的维护和升级。
2、C/S结构与B/S结构毕竟是不同的两种架构，要将其有机的结合起来需要ApplicationServer的支持，导致软件开发费用的增加和系统复杂度的增加。
3、考虑到环境监测信息系统的具体特点，B/S架构的功能已能实现全部管理功能。
5.3.2B/S/D架构的Web应用解决方案的优势
Web平台是一个调度任务集中的、以客户为中心的应用程序平台；它是一个分布式、开放、适用性强、高性能、端到端的平台；它可使企业利用技术获取竞争优势。
1.分布式
C/S技术的出现，给系统集成方案带来了集中的信息和本地的PC环境，但其数据的共享程度是很不够的。
当今的信息技术需要新的解决方案，它提供以客户为中心的用户界面和Web的分布结构，它带有IT环境的个人特征，如数据存取、安全性能等，这就是我们通常所说的三层结构。
2.Web结构的优势
在Web结构中，事务层和数据逻辑层放在中间组件层，这是关键，是与C/S结构的最大区别，它能解决以下几个问题：
（1）客户端很瘦小，并且很容易在运行时自动升级；
（2）事务层可在跨平台的客户端上共享；
（3）不同逻辑组件的分离意味着图形设计人员、事务逻辑开发人员和数据库分析人员可以独立地设计他们各自的部分；
（4）统一的、抽象的用户界面可使用户更有效地从同一数据源中存取数据；
（5）这种结构可更有效地在企业内部网、国际互联网和外联网上运行。
中间组件层充当一个服务器，这就是通常所说的应用服务器。
3.开放性
Web是一个开放的环境，应用由复用组件集成，通过标准语言汇编、跨平台的统一协议发布，用标准用户界面显示，它与硬件平台和操作系统无关。
现在有三种组件模型：
ActiveX、JavaBeans和CORBA。
但并不是每一种浏览器都支持动态的HTML，Java脚本的扩充至少支持三种模型：
ActiveServer、LiveWire和PowerDynamo。
4.适应性
一个可适应的开发环境是非常重要的，采用应用服务器的目的在于它支持多种组件模型，但在客户端和数据库服务器端需要有更强的适应性。
随着Web技术的介入，用户界面设计已发生了巨大的变化，因为在站点上，并没有类似迷惑用户的东西或用户手册。
一个成功的站点应首先吸引用户，而后留住用户。
而引入新的、面向图形化的和直觉的用户界面标准，就允许最终用户可以直接与它们交流。
5.3.3B/S/D结构中各部分的分工
Web发布部分
Web服务器仅仅是把要显示的内容从站点上以文件的形式读取，然后以静态的HTML格式送到客户端的浏览器；也可以Applet增强表现能力，但它仅仅是利用ActiveX或JavaBeans通过页面或组件，并没有通过任何事务数据服务器。
数据处理部分
Web数据处理增强了标准Web站点存取数据的能力，包括许多数据类型。
我们可根据数据的存取容量把数据分成两大组类：
标准的在线事务处理（OLTP）程序将花费大量时间去检索和操作核心在线数据，这种数据需要连续读取和回写。
而另一种辅助数据是只读的，如帮助文件、用户信息和文档等。
Web数据处理主要集中在辅助数据，而WebOLTP主要集中在核心在线数据。
客户端
客户端是表现逻辑层，执行含有各种扩展的HTML（包括动态HTML）页面，这些扩展既来自浏览器，也来自可视化JavaBeans和ActiveX组件。
在任何情况下，我们至少需要一个HTML页面，由此HTTP可从服务器端传至客户端，应用程序的其它部分可以是一个整体。
因为大部分的Web应用都是为Internet编写的，对专业的IT应用而言，Web是一个成功的平台，用户可以在断开连接后继续工作，这就意味着远程象本地一样可存取事务和逻辑数据。
这样不仅要分发应用程序，而且还要分发数据。
应用和数据服务器端
Web结构中的剩余部分就是完成应用程序如何与数据协同工作。
数据可分成两大类：
事务逻辑和数据逻辑。
数据逻辑驻在数据服务器中，而事务逻辑则置于应用服务器中。
事务逻辑又可分为两类：
事务组件和应用服务，事务组件定义了事务及其操作，而应用服务则是提供一般应用性能的组件，如菜单管理、主从数据格式等。
在一个完整的应用中，以上方式往往同时存在。
例如，对不存取任何数据的Web
升级会员 