农业气象业务经过了二十多年的发展，形成一些专业业务服务系统。有关气象部门先后组织研发了农业气象情报分析 (评价) 系统、国内外作物产量气象预报系统、农业干旱监测预警与评估服务系统、农业病虫害发生发展气象等级预报系统等^[1-9]，开展全国范围的作物生长发育状况评价、农业干旱、国内外小麦、玉米、水稻、大豆等作物产量预测以及北方草原蝗虫、江南稻飞虱、江淮小麦赤霉病、西南稻瘟病、东北玉米螟、黄淮条锈病和棉铃虫等气象等级预报服务。随着农业气象业务需求变化和软件开发技术的发展，部分业务系统已经引用了GIS组件、模块插件等新的开发技术，但总体来看，还存在一些不足：① 缺乏统一、规范的数据库支持，数据重复交叉使用；② 产品分析制作方式、风格各异，服务产品不规范；③ 软件开发方法、工具不同，代码重用性差，系统扩展性较差。这些因素导致相似系统重复性的投入开发，系统数据支持不完善，很难在全国范围内进行业务推广应用。

软件设计模式 (下简称设计模式) 是利用面向对象技术来解决特定环境中的问题的方法，是针对软件设计过程中某个特定环境下出现的问题的可重用软件设计方案。它不仅是过去的成功解决方案，还是经验的总结，更是智慧的结晶。它可以共享过去的成功经验，降低解决问题的复杂度，提高设计的模块化。当前气象软件建设进入了高速发展阶段，这对业务系统软件的可靠性和重用性也提出了更高的要求。在软件开发过程中，系统分析和设计模式分析也显得尤为重要。通过充分利用过去的开发实践，探索适合农业气象专业的软件开发模式，并将其应用到实际业务系统开发过程中，这有助于开发人员开发出逻辑清晰、构架合理、可重用性高的代码。

有些设计模式在气象业务系统中初步得到了应用。吴焕萍等^[10-11]在决策气象系统采用插件式系统框架，利用专业模块插件模型对多种专业模型进行了封装，实现了系统功能的扩展；傅希德等^[12]在三峡梯级调度可视化气象业务系统中利用了部分数据转换和质量控制模型、组件封装模型解决了MICAPS数据与GIS数据之间的转换、共享、控制和专业气象信息可视化问题。虽然这些相关技术能为农业气象业务系统的开发提供借鉴，但要系统地解决农业气象业务系统建设中遇到的问题，则必须通过对农业气象业务的综合分析，从系统各个层次上引入先进的软件设计模式与开发技术，进一步形成通用、规范的应用系统。

国家级农业气象业务已经开展近30年，业务系统也从无到有、从单一农业气象情报系统发展到农业气象情报、预报、评估等综合性的系统，现在已拥有包括农业气象灾害监测预警评估、农林病虫害气象等级预报、农业气象影响评价、作物产量气象预报、农用天气预报、生态气象监测评估、农业气象业务产品制作以及农业气象综合数据库应用等8个子系统、近60个核心模块 (图 1)。但因各阶段业务需求不同和计算机技术的快速发展，系统开发技术差异较大，缺乏规范的规划与管理，使得各时期开发的系统和模块相对零散，数据标准和产品制作方式规范不足。要充分利用现有开发成果，必须在系统高级功能层中，采用组合集成方法，建立大颗粒复用机制将各类专业模块和系统框架融合在一起，开发标准化的数据接口，提供标准化、规范化的数据库系统支持，构建适用于国家级、省级的农业气象业务系统。

图 1

图 1. 系统功能架构 Fig 1. System functional structures

从开发技术上看，农业气象业务系统需要考虑系统框架、数据库应用和GIS组件应用3个方面的关键技术。根据当前计算机开发技术的发展和业务应用状况分析，本文将在VS.Net框架技术、ArcGIS Engine组件和Oracle数据库系统开发环境下具体阐述农业气象业务系统设计模式。

业务需求是系统发展的源动力，系统发展由业务需求决定。农业气象业务具有以下特点：① 多种数据资源并存；② 业务具有较强的地域性；③ 技术革新速度快；④ 多种模型贯穿于业务应用。因此，农业气象软件设计模式必须注重以下功能：① 系统应采用开放式松散耦合框架，为进一步实施数据共享、低层和高层软件复用打下了坚实基础，局部技术变化不影响系统整体生命力; ② 专业技术模型具有独立更新或适应变化能力; ③ 具有较强的数据适应能力和数据处理能力; ④ 系统开放底层公共模块接口，支持二次开发，便于构建适应不同地域的系统。总结过去系统设计特点，吸取各方设计优点，构建实用的软件设计模式是集约化系统开发的总体目标。

设计模式包括创建型模式、结构型模式和行为模式三大类几十种模式, 常用的模式有模板方法、工厂方法、策略、装饰者、观察者、访问者和组合等模式^[13-15]。其中, ① 模板方法模式的目标是减少同属于一个父类的几个子类之间的重复代码量, 主要应用于商业服务网站设计；② 工厂方法模式封装了创建对象的代码，将实例化延迟到子类中，通过封装对象创建代码，设计中的其余部分可以依赖抽象类和接口来实现，从而满足业务发展需求的改变；③ 策略模式可以在系统运行时选择算法，允许多种算法用于同一个应用，通过运算结果确定最好的算法，以满足客户根据需要来选择具体的算法；④ 装饰者模式可以在运行时扩展对象的结构，在设计时也可以灵活地选择使用继承来创建支持新功能的子类；⑤ 观察者模式是发布-订阅体系结构风格的一种应用，在软件需要某个关键事件来通知多个对象的情况下，观察者模式作用不可忽视；⑥ 访问者模式将操作片段集中并封装于自身的类中，其主要优点是操作更加内聚，并且可以在不触及组合对象代码单位情况下增加新的操作；⑦ 组合对象模式是异构对象的汇集，表示一些组合的实体，组合模式的一个好处就是客户端模块仅与新接口交互，它们不需要知道组合对象的节点的结构如何，组合对象的类结构的改变也不会对客户端产生影响。

工厂模式和策略模式的作用就是减少耦合，在变化来临时争取做最小的改动来适应变化。选择策略模式的优点是能够提供管理相关算法族的办法，提供可以替换继承关系的办法。工厂模式的优点主要是能够根据外界给定信息，决定应该创建哪个具体类的对象；外界可以从直接创建具体产品对象的尴尬局面中摆脱出来，外界与具体类隔离开来，偶合性低；明确区分了各自的职责和权力，有利于整个软件体系结构的优化。因此，考虑当前及未来农业气象业务服务的需求与特点，本系统的设计采用策略模式为主、工厂方法模式为辅的方式，以适应运行时用户的不同需求，提高软件的复用效率。

总体框架模型由低到高分别由数据存储层、低层技术方法和高层系统功能层组成 (图 2)。

图 2

图 2. 总体框架模型 Fig 2. General framework of the model

数据存储层：由图形 (像) 数据库、产品数据库、气象数据库、地理空间数据库以及资料控制模型构成。

低层技术方法：针对于通过各种语言开发的具有独立功能的通用组件，在实际使用中，通用组件有地理信息开发组件 (ArcGIS Engine，MapGIS等)、图表分析组件 (Mschart，TeeChar等)、数据库访问组件 (OLE DB，ADO等)、报表制作组件 (FlexCell，Crystal Reports等) 和其他组件 (数据分析、转化等)。

高层系统功能：一是系统自带的准标准化共享功能模块，如产品制作、输出和系统管理等；二是插件管理的专业模块。各个专业模块与系统之间构成开放式松散耦合关系，专业模块形成独立维护格局，在实际应用中可以根据业务需要对提供的功能模块进行功能筛选裁剪。各类专业技术模型被封闭在专业模块内部，技术更新和模型变化只需对该模块进行单独维护，无需改变系统结构和环境，增强了系统适应性和生命力。

该框架技术通过以下技术处理来满足实际需要：① 在数据存储中，通过转化非标准数据到资料数据中，利用数据库强大的数据存储和处理能力支持系统运行，将产品和相关地理信息资料纳入数据库管理，方便数据共享；② 在分层系统框架中，将功能相对独立的的底层通用组件 (模块) 公开其开发接口，支持系统二次开发，满足不同地域业务需要；③ 在框架顶层实现各功能模块集成组装，各专业模块封装各类应用模型，通过接口管理和系统框架集成在一起，功能接口负责专业模块和系统框架通信。

针对农业气象信息资料的多样、庞大与共享应用的特点，在系统的数据层中重点解决数据接收、质量控制和实现数据标准接口中的数据库组件封装技术问题。

设计一个具有人工干预、包含数据转换和质量控制的数据控制模型 (图 3)。从多种数据源中定时 (手工触发) 提取需要的原始数据 (文本文件、表格文档、格式文件、其他数据库表等)，通过数据过滤并转化形成业务需要的数据，对特定的数据使用数据纠错机制 (如阈值法、临近比值法、回归法等)，使之符合质量要求。完成数据校正后写入本地数据库，同时对该次数据更新进行记录。预留的人工触发干预接口，便于业务人员进行应急处理。通过以上措施，增加数据可靠度，增强系统数据处理能力，提高系统兼容性。数据控制模型为数据库管理系统提供快捷、高效的数据处理功能，提高系统的兼容性。

图 3

图 3. 数据控制模型 Fig 3. Data control model

数据服务模型以构建数据库存储过程为核心，通过SQL指令与数据查询统计模块共同完成各种专业的数据服务 (图 4)。

图 4

图 4. 数据服务模型 Fig 4. Data service model

存储过程 (stored procedure) 是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中。在农业气象数据应用服务中，经常会涉及比较复杂的分析方法和模型，如稳定通过界限温度的活动积温、有效积温、初终霜日、干热风、寒露风、寒害、高温热害等特殊数据服务。在以往的应用系统中，一般采用简单的SQL查询/统计语言，实现从客户端检索数据到本地分析处理，不但延长了查询时间，降低数据库服务效率，而且也不便于处理方法的改进或更新。利用数据库存储过程管理方式，建立专业数据分析、处理模型，有效减少客户端的查询指令，在服务端执行已编译的SQL语句，运行效率和速度较好。使用存储过程还有其他优点，如封装性，存储过程在服务端完成包装，客户端不需要将程序和SQL语句捆绑在一起，而降低客户端负担，方便修改、维护；存储过程更有利于重复使用，提高开发效率，更快、更好地开发出高质量产品。这些特点有助于快速实现农业气象综合数据的专业应用服务，提供高质量的数据服务产品。

农业气象数据应用具有以下特点：① 多种模型贯穿于业务应用，不同模型对数据的要求有较大差异；② 业务具有较强的地域性，相同应用模型对数据配置也有差异；③ 技术革新速度快，新增数据需要不断引入到业务应用中。因此，需要根据数据服务模型配置具有二次开发能力的数据组件封装模型，在设计复用的技术上提高系统的生产力和质量，缩减软件开发和维护的花费。本文重点阐述数据库访问ADO (ActiveX Data Objects) 组件的封装模型，以便更快地访问Oracle, SQL Server等不同专业数据库系统，适应不同业务、不同区域的数据要求。

ADO访问包含连接对象 (connection)、命令对象 (command)、参数对象 (parameter)、记录集对象 (recordset)、字段集合 (field)、属性对象 (property) 和错误对象 (error)。ADO对象的初始化和销毁都有严格规定，对于不熟悉ADO数据库组件开发的人员使用不方便。本系统中，将ADO组件与地理空间数据访问引擎 (ArcEngine SDE) 相结合，封装成Dabase的新对象 (图 5)。通过公布其调用接口来使用多种数据库，为二次开发提供了底层支持，在系统再开发中具有重要意义，使得程序员可以直接使用该接口来访问各种数据库，而不是直接使用ADO数据库存取对象。

图 5

图 5. 数据组件封装模型 Fig 5. Data component package model

农业气象业务系统的软件框架采用插件式框架技术，为系统功能的扩充和推广应用部署奠定基础。插件引擎 (Plugin Engine) 用来解析和管理插件，提取其中包含的插件类型信息并负责将其生成相应的插件对象。在插件引擎的支持下，专业模块以插件的形式集成到一起。插件引擎搜索系统中所包含的专业处理模块，将命令 (ICommand)、工具条 (ITool)、菜单 (IMenuDef) 等接口对象传递给插件模块，在插件加载过程中，获取命令、菜单、工具条等内嵌资源并加载到主框架中 (图 6)。专业模块分为接口实现部分和功能实现部分，组件封装模型中专业模型在二次开发接口的支持下，完成特定功能，并输出产品数据。

图 6

图 6. 插件管理构架 Fig 6. Plug-in management framework

系统主框架和专业模块之间构成开放式松散耦合关系，是今后系统功能增加、筛选、裁剪的基础。开放的功能接口可以使专业模块具有通用性，即相同接口可以由不同编程语言来开发实现，且均能与系统框架完成信息交换、协同工作。

软件复用就是将已有的软件成分用于构造新的软件系统，软件复用可以极大地降低开发成本和复杂度，提高应用程序开发效率，保证软件质量，缩短开发周期。软件复用主要包含代码的复用、设计的复用、分析的复用和测试信息的复用4个级别^[14]。

现阶段国家级、省级及其他的一些业务单位已形成了功能不同、相对零散的各种农业气象业务系统软件，从服务领域划分, 主要有农业气象评价 (情报) 分析、农作物产量预报、土壤水分监测评估、农业气象灾害监测预警评估、农业病虫害气象等级预报、生态气象监测评估和气候资源利用与区划评估系统，以及新发展的农用天气预报系统，这些系统为发展新的、通用的农业气象业务服务系统提供不可缺少的软件资源，必须充分利用设计复用技术和分析复用技术，提高系统的开发效率、缩短开发周期，保障业务系统的顺利衔接。

开发架构最大难点就在找到一个合理的复用点，如果复用颗粒度小，复用性就会变高，但增加应用层开发复杂度；如果复用颗粒度过大，就会影响扩展性，对需求变化不利。因此，在确定业务需求和系统的功能情况下，现有软件应建立在相对较大颗粒度的基础上复用，才能将各类专业模块和系统框架融合在一起，适当减少开发工作量。基于接口通信机制 (图 7)，使系统框架能够屏蔽专业模块之间的差异，从而有利于软件的分析复用。在专业模块内部采用设计复用方法 (组件)，便于构建不同业务的实现。系统框架与专业模块的通讯依靠通讯契约来实现，通讯契约以接口的形式存在，只有实现了规定接口的类型对象才能被主框架认可^[16]。所以，原有系统资源的利用必须经过适当改造，使其建立在统一接口的基础上，才能够实现主框架的共享，进而实现专业模块的复用。

图 7

图 7. 专业模块复用模型 Fig 7. Professional module reuse model

综上所述，无论是针对具体农业气象业务系统还是气象行业系统，该设计模式在应对技术共享、业务变化和技术更新采取了4个方面的措施：① 在系统低层，公开的通用组件接口，保证在软件重组中能共享原开发成果，提供开发进程和开发质量；② 在系统高层，接口管理使各类专业模块能够在系统框架下进行重新裁剪、组合 (即插件式系统框架)，在二进制基础上集成软件，减少软件重新编译，简化发布过程，满足不同业务需要；③ 开放的功能接口能够使软件模块实行分工开发，加快系统开发进程，实现专业模块的即插即用，提高系统的扩展能力；④ 因技术进步或变化引起的系统改进被缩小到某个专业模块内部，软件整体影响很小，提高了软件的可系统维护性。

应用ArcGIS Engine开发技术，采用VB.Net语言开发，在原有的国家级农业气象评价业务系统基础上进行整合，以模块化结构研发为农业气象评价组件 (AgMDAS.DLL)，通过引用ICommand接口嵌入到ArcMap平台上，实现了在GIS平台上的全国主要作物生长状况的监测、主要农业气象灾害监测评估、土壤水分监测与墒情对比分析，以及旬 (月) 基本气象要素空间分析等的业务，图 8a，8b所示分别为嵌入ArcMap的农业气象评价系统和一季稻发育期专题图产品。该组件从2008年投入国家级业务以来，运行稳定，数据处理与空间分析速度较快，制作效果较好。

图 8

图 8. 嵌入式农业气象评价系统 (a) 作物属性信息分析模块, (b) 一季稻发育期专题图制作 Fig 8. Embedded assessment system of agrometeorology (a) the crop growth and development of information analysis, (b) the rice developmental stages of thematic maps

采用动态链接库组件进行ArcGIS插件式开发，实现程序的模块化；系统由相对独立的组件组成，降低了软件结构复杂度；程序的加载速度更快，而且模块只在相应的功能被请求时才加载，可以更为容易地将更新应用于各个模块，从而提高了模块的复用度，松耦合度也更加合理。但动态链接库 (DLL) 的一个潜在缺点是应用程序不独立，发行时需要相关的组件包支持；此外，在处理Geodatabase (地理空间数据模型) 数据时，会占用大量内存空间，数据量太大容易造成ArcMap崩溃，但通过ArcMap桌面版本的升级、优化，可以处理较大的数据量，当然，也可以采取空间数据分割的方法，将较大的数据块分成若干个小数据块后处理，以降低对内存的消耗。

遵循气象行业数据标准与规范，借助Oracle9i专业数据库平台，结合ArcGIS SDE空间引擎技术，以及运用数据组件封装的Dabase对象，构建了包含农业气象科研和服务所需的行业属性数据和空间数据的农业气象综合数据库；采用VB.Net语言与C/S结构，研发了拥有了计算机软件著作权的农业气象数据库应用系统 (AgMEDBAS V1.0)，初步实现了数据管理、查询、检索、统计、对比分析及特定功能 (高温热害、干热风、寒露风等灾害) 查询，为业务系统调用公共气象数据及业务人员快速访问数据库提供支持 (图 9)。

图 9

图 9. 基于Oracle的农业气象数据库应用系统查询界面 Fig 9. Query interface of agrometeorology database applications system based on Oracle

由于Dabase对象仅考虑常用的Oracle9i, SQL2000数据库，以及ArcGIS SDE9.1 for Oracle9i空间数据引擎，在此环境下可以实现快速调用，但尚未在Oracle10g以及ArcGIS SDE9.3平台下测试、运行，仍需调整参数，进一步完善。

1) 该文重点讨论了总体框架模型、数据控制模型、数据组件封装模型、专业模块插件模型，解决了松散耦合式系统集成、数据兼容性扩展、软件复用和升级、系统适应性，较好地解决了系统的兼容性和扩展性。

2) 软件设计模式在系统开发中占有重要地位，一个实用的软件设计模式可以重复使用，来解决行业内的特定问题，并且在实践中不断发展和完善。实用的行业系统设计模式不只一种，相同的应用领域也可能存在多种实用模式。设计模式选择要根据信息技术的发展与业务需求的变化以及实际应用的效果而制定。

在标准化的数据库及框架开发技术支持下，借助GIS组件开发技术，插件式的专业化模块技术已基本实现，业务应用效果较好，在气象监测与灾害预警工程项目“国家级农业气象灾害服务保障系统”的开发中得到了充分应用。但更为复杂的专业模块设计需要进一步研究，且业务流程与业务功能需求的变化也需要在后续的研发中逐步加以完善。