插件框架

插件框架（精选3篇）

插件框架 篇1

摘要：分析了当前软件开发过程中常见的两个问题,讨论了解决问题的插件技术的四种常用框架,分析了它们的优缺点,最后利用C#提供的接口和反射机制,设计和实现了一个轻便灵活的DLL插件框架。

关键词：插件,接口,反射,C#

0 引 言

随着业务的增长以及市场的快速变化,近年来软件开发领域面临两个重要的问题,一个问题是如何迅速实施软件应用,占领市场先机,另一个问题是如何应对多变的需求。传统的软件开发方法和软件架构往往不能敏捷应对市场的需要,在开发一个应用的时候会花费大量的时间,使得开发出来的软件有“过时”的危险。另一方面,需求的变化也会对软件设计和重构带来沉重的打击。例如在软件开发后期,用户需要一个新的功能,哪怕这个功能很小,都会引起一连串连锁的修改扩散反应,并给测试和集成带来压力。而当软件已经部署在用户的应用环境中后,因为政策变化或新的业务需要,用户要增加新的功能,在确定了用户的需求后,却发现原有的软件架构已经无法胜任新增任务的需求,这时需要重新设计这个应用。但即使又用了一个开发周期完成了用户需要的应用,却仍不能保证用户的需求不会再次变更,也就是说,需求蔓延的可能性依然存在。

插件技术能够较好地解决上述软件过程问题。所谓插件技术,就是通过在程序设计过程中把整个应用程序分成宿主程序和插件程序两个部分,宿主程序和插件能够相互通信,并且在宿主程序不变的情况下,可以通过增减插件或修改插件来调整应用程序的功能[1,5]。首先,当设计完一个插件框架后,后续的工作都是依赖这个框架进行的,各个部件只要符合框架的要求,都能够进行整合,这样带来的好处是不同的功能可以并行地进行设计开发和测试,大大缩短软件开发时间。其次,在插件框架下,用户的需求变更只会引起一个小局部的修改,通过设计新的插件或者修改现成的插件就可以满足用户的要求,而不需要对整个软件进行编译。再次,一个设计良好的插件框架具有很强的适应性,往往可以做到一次设计,多次应用的重用效果,因为插件框架中完全可以将所有的功能模块都做成插件,当面临一个新的应用领域的时候只需要设计新的功能模块即可。

1 插件框架分析

在目前的软件设计中,常见的插件框架主要有下面几种:

(1) 脚本式插件框架 这种方式使用某种语言,例如python、XML,把插件的程序逻辑写成脚本代码[4]。插件设计很灵活,只要定义好一组通信语法即可,甚至可以自行设计一种脚本语言来配合程序的特殊需要。但是这种方法实现的插件必须要加密,否者用户很容易通过修改脚本来破坏程序的逻辑,而且需要设计脚本解释器来解释插件。MS Office中的宏、漏洞扫描工具Nessus都是使用这种插件方式。

(2) 二进制调用方式的插件框架 二进制调用方式将插件功能直接编译为EXE 。宿主程序具有自己的基本功能,同时还负责调度这些“插件”,通过调用外部的插件程序来完成扩展功能。这种方式使得插件运行在独立的进程空间中,提高了插件的效率和安全性。其缺点就是使插件与插件之间、主程序与插件之间的信息交流困难了许多,在各部件通信方式设计上难度较大。

(3) 基于COM组件的插件框架 COM,即组件对象模型,COM提供了组件之间的交互规范和环境,基于COM组件的插件框架需要做的只是实现程序定义的接口[6]。插件对于主程序来说是完全透明的,宿主程序不需要知道插件怎样实现预定的功能,它只需要通过接口访问插件,这样一来,主程序与各插件之间的信息交流就变得非常简单。这种方式的主要缺点就是设计过程中涉及到大量的COM技术以及原理,不够轻便,影响了开发的速度[2]。

(4) 动态函数库DLL插件框架 动态函数库DLL插件框架是一种实用、灵活、开发速度快的开发方式。这种方式的插件功能以动态库函数的形式存在。在设计上类似COM的插件方式,宿主程序通过某种渠道(事先确定的一组规范)获得插件 DLL 中的函数签名,然后在合适的地方调用它们。它相比于COM组件的插件框架的优点是可以自定义一个简单明了的接口,在开发设计上较为轻便。许多常用的软件,例如Matlab、Firefox使用了这种类型的插件。

C# 是面向对象的程序设计语言。它提供了 interface 关键字来直接定义接口。同时,System.Reflection 命名空间也提供了访问外部程序集的一系列相关对象。所以,使用C#能够很容易地设计出基于DLL的插件框架。

2 使用C#设计插件框架

插件框架的思路是这样的:整个框架以接口为中心,宿主程序和插件程序都符合特定的接口并通过接口相互通信,实现功能的灵活扩展。插件封装成C#的类库(即是DLL文件),宿主程序则是一个插件的骨架,在程序启动的时候扫描插件所在的位置,通过匹配每一个DLL文件是否符合接口规范来判别一个DLL文件是否是正确的插件,并将正确的插件导入程序中。一个最简单的宿主程序就仅仅有插件的扫描导入功能,而其余的所有功能全部通过插件来扩展实现。

2.1 接口的设计

在整个插件框架的设计中,接口的设计是最重要的,也是最基础的。只有宿主和插件都符合接口的要求才能整合。插件框架主要涉及到两个接口,一个是宿主程序的接口,一个是插件的接口。接口描述如下:

IPlugin是插件的接口,其中声明了插件的宿主、名字、描述、作者、版本等信息,以及UI、工具栏、菜单等资源,在接口的设计过程中可以根据需要添加或者删减。

IPluginHost是宿主程序的接口,在这里向插件提供必要的宿主函数或者资源,如文件对象、数据库的连接对象等等。这样,每一个插件都可以通过Host参数来访问宿主程序的资源或者函数。

设计完接口后,可以进行插件和宿主程序的并行开发,插件只需要继承IPlugin接口,实现里面所有的定义即可。而宿主程序除了要继承IPluginHost接口之外,还要具备发现插件、载入插件等功能。

2.2 发现插件

宿主程序在运行的时候会扫描插件目录,将找到的每一个DLL文件与IPlugin接口相匹配,如果符合,则将插件放入到插件集合中。在许多文献中,并没有提到如何匹配插件,匹配插件是一个动态检查程序集(这里是封装成DLL的类库)是否符合IPlugin定义的过程,需要对一个编译好的DLL动态分析,而C#中的反射机制正好满足这一点。

反射机制代表在执行期的一个程序集类型元数据的使用[3],允许程序开发人员在程序执行期间查看程序集的元数据、探索类内容、进行后期绑定、动态创建类型等操作[7]。在这里可以将DLL类库映射成为程序集,然后通过System.Reflection空间下的GetInterface()函数来匹配接口。其主要流程如图1所示。

关键的匹配插件函数如下:

MatchPlugin函数首先为要匹配的DLL文件建立一个Assembly对象pluginAssembly,pluginAssembly反射了这个DLL,然后使用GetTypes()函数获取这个Assembly对象中的所有类型,通过遍历pluginAssembly中的每一个公有非抽象类型,使用GetInterface(″IPlugin″,true)来检验每一个类型是否符合IPlugin接口的定义,如果该类继承于IPlugin接口,则认定为一个正确的插件,并建立这个插件的实例,将其插入到插件集合中。否则得到null的结果。通过这个过程,能够很容易判别一个DLL文件是否是正确的插件,保证了程序的安全可靠。

若想有选择地添加插件,可以在匹配函数上添加过滤的条件,例如可以对DLL的名称和插件的名称、作者、描述等进行过滤,这样可以实现整体功能的裁剪。

2.3 载入插件

通过扫描匹配,可以得到一个插件集合,当一个插件实例添加到插件集合的时候,这个插件的功能函数已经可以使用了,但插件的用户界面、工具条、菜单等资源并没有载入到指定的位置,用户无法控制这个插件,所以必须将插件的资源添加到预先定义好的位置,将插件的功能提供给用户使用。加载插件资源的过程是“判断资源是否存在→在预定义的位置加载对应的资源”。载入资源的示例语句如下:

2.4 插件程序与宿主程序的通信

在这个插件框架中,插件与宿主的通信是非常方便的,因为IPlugin接口中有一个子对象IPluginHost Host,所以在插件载入过程中可以将Host设置为宿主程序,那么插件可以通过Host来访问宿主接口提供的函数或者资源。例如在IPluginHost接口中提供了一个test()函数和一个SQLiteConnection类型的数据库连接dbcon,则在插件中可以通过Host.test()来调用宿主提供的函数,也可以通过Host.dbcon来使用宿主提供的数据库连接资源。由于子对象带来的充分灵活性,甚至可以在程序运行过程中动态更改插件的宿主,也可以将一个插件作为另一个插件的宿主,更能形成一个插件链,使得这个框架具有非常好的灵活性和扩展性。如图2所示。

另一方面,因为插件的匹配和载入过程都是在宿主程序中完成,所以插件的实例都存储在宿主程序的插件集合中,也即是说,宿主可以直接访问插件集合中的每一个插件。

由此可见,插件和宿主之间的通信是非常简单快捷的。而插件与插件之间的通信必须严格依赖于宿主定义的接口来进行。这样能够保证插件之间的独立性,体现了低耦合的原则,在设计、开发、测试、维护等一系列过程中,能够始终将工作集中在宿主与插件的关系上,而不是在大量的插件之间。

3 结 论

在软件开发过程中使用插件框架能够很好地应对开发速度、需求变更、维护等问题,它能分解复杂的应用,能够使开发并行进行,各个部件之间非常灵活,也能够减少维护和升级的工作量。一些主流的软件开发商在开发应用的过程中都会选择插件的结构,如Photoshop、IE、Firefox、winamp等等。

C#提供的反射机制使得程序能够动态地分析程序集,判断一个DLL文件是否满足接口的要求,并动态生成一个插件的实例,这给插件框架的设计带来了很大的方便。同时,在设计过程中使用了接口,使得插件的发现(匹配)、载入、通信都非常简单。整个插件框架比较灵活,有较好的适用性。

参考文献

[1]姜昌华.插件技术及其应用[J].计算机应用与软件,2003,20(10).

[2]陈方明,陈奇.基于插件思想的可重用软件设计与实现[J].计算机工程与设计,2005,26(1).

[3]Patrick S Practical.NET2 and C#2[M].Paradoxal Press,2006.

[4]王帮进,张宏,等.基于插件的房产GIS集成研究[J].微计算机信息,2007,23(2).

[5]李俊娥,周洞汝.“平台/插件”软件体系结构风格[J].小型微型计算机系统,2007,5(5).

[6]潘爱民.COM原理与应用[M].北京:清华大学出版社,2000.

[7]Mark M.Essential C#2.0[M].Addison Wesley Professional,2006.

插件框架 篇2

电网水电站水库群调度[1]系统包括水文预报、发电调度、防洪调度、风险分析、考核评价等应用功能，该系统对于优化水能资源利用发挥了重大的作用。电网水电站水库调度工作的复杂性、需求的可变性，因此，开发出满足多模型、可配置、高可用、易扩展、易维护等要求的应用软件成为业内的技术挑战。

当前，国内外众多学者已经开展了有益的探索。文献[2]提出了基于电站编号排序的单向链表结构来描述水电站群的网络拓扑关系，可满足电站插入、删除、查找等基本运算；文献[3]运用领域工程理论，合理划分水库调度软件系统的稳定部分和易变部分；文献[4]初步提出水库调度应用中构件实现框架。

本文结合工程实践，将设计模式[5]引入到电网水电站水库群调度中，遵循软件设计的开闭原则实现了一套插件式应用框架。一方面，开发出电网标准组件（调度对象、调度模型、表现界面），并预留有扩展公共接口；另一方面，开发人员通过二次开发可以扩展调度模型、调度算法、人机交互界面，满足不同工程的应用需求。

1 电网水电调度复杂性

1.1 调度对象复杂性

电网水电调度对象包括水库、机组、闸门、上下游河道等；复杂性体现在对象结构、水库拓扑关系等。水电站水库存在调节性能差异，可划分为多年调节、年调节、季调节、日调节和径流式等类型。考虑各水库之间的水力联系，在特定的时间点下，水库群的规模和结构是确定的；但是在更大的时间范围内，水电站水库的规模是变化的，将导致水库拓扑关系重建。

1.2 调度任务复杂性

水库综合利用是水资源规划的重要任务，需要兼顾国民经济的发展、地区开发、自然环境、社会福利等各个方面，需要统筹兼顾、合理安排。电网中水电站水库根据综合利用要求需要同时承担灌溉调度、发电调度、防洪调度、航运调度、生态调度等任务。在不同类型水库兴利调度中，发电调度、灌溉调度及供水调度一般是主要兴利调度对象，汛期侧重于防洪调度；而航运调度、供水调度、泥沙调度等通过设定为兴利调度约束条件来实现。

1.3 方案研制复杂性

以发电调度为例，方案研制可划分为水文预报、长期发电调度、中期发电调度、短期发电调度、实时调度、调度分析和考核评价等过程。每个节点的实现又涉及边界约束设置、数学建模、算法选择、成果展示等要求，但是各模型之间仍存在共性，也为后续工作奠定了基础。图1显示了电网水电站水库群调度的复杂性影响因素。

2 调度插件框架设计

2.1 插件式框架总体结构

电网水电站水库群调度系统属于典型的人机交互决策系统，通过合理的分工可以可靠、高效地发挥作用。电网水电站水库群作为研究对象，按照系统论的“结构-行为-表现”思想方法，需要分析水电调度对象，调度任务和人机交互界面。本文按照“框架+插件”的结构将系统划分为基础框架部分、插件部分，将业务中变化的部分（拓扑结构、模型算法、人机界面表现等）进行松耦合处理，可以增强系统对环境的适应能力。

框架和插件之间通过一组接口协议进行通信，本系统中框架部分通过抽象基类提供接口，插件是指一类扩展类库。为了更好地管理插件，系统采用工厂方法模式，提供统一的应用接口来访问扩展类，相关逻辑结构如图3所示。

2.2 水电调度对象框架

水电调度对象包括水库、水电站、泄洪设施、其他取水设施等，在水调决策支持系统设计中具有不变性。例如水电站之间的差异主要表现在机组名牌出力、NHQ曲线、预想出力曲线等具体数据上，而电站和机组之间的这种结构关系是确定的。图4为水电调度对象类图。

在全面分析水电调度对象数据结构的基础上，运用抽象、聚类、分解等信息建模方法，可以将调度对象划分为：水库类、水库调度图类、水电站类、机组类、泄洪设施类、溢洪道类、抽象曲线类。由于调度对象被所有的调度对象模型所共享，在设计上宜采用单例模式。

水库类：基本属性包括库容系数、调节性能、校核洪水位、设计洪水位、正常蓄水位、死水位等，由于水库间的连接是连续的单向链接，没有跳跃也没有回落，而且水流只有汇流没有分叉。可用指针数组存在上游水库对象，用指针变量存放下游水库对象，可以方便地建立电站拓扑结构。

水电站类：基本属性包括电站装机容量、保证出力、设计水头、最小技术出力、电站集合等，可以实现机组的插入、删除、查找等运算。抽象曲线类：建立二维曲线抽象类和三维曲线抽象类，通过继承可以支持水库库容曲线、NHQ曲线、预想出力曲线、水位流量曲线的扩展应用。

2.3 调度模型与算法框架

水电调度模型是对水电调度任务的数学描述，具有可变性的特点。可扩展的水电调度模型算法框架体现在调度输入输出、多种调度模型、多种模型算法三个环节。图5显示的是调度模型与算法类图。

调度输入输出：调度参数按照调度电站对象可划分为单站调度参数和库群调度参数，主要是采用生成器模式（Builder Model）将参数集中管理。其中，单站调度参数中集合了调度时间、径流过程、约束条件、输出成果、调度模型等内容，而每个约束条件采用一个类进行描述，所有的约束条件采用数组进行管理解决了约束条件的扩展性。库群调度参数包括调度时间、调度对象、调度模型等进行集中管理，主要反映库群计算控制参数。

多种调度模型：该部分采用策略模式（Strategy Model）进行类库设计。水库调度模型如发电量最大、耗水量最小、期末蓄能最大、保证出力最大等均表现出相同的行为，包括设置约束条件类型、检查调度输入数据是否合理、模型计算、整理输出成果，该模式可以为多种模型算法解决后顾之忧。

多种模型算法：该部分采用模板方法模式（Template Method Model）以方便实现模型的具体算法，如当电站采用发电量最大模型时，算法可以选择DP算法、DDDP算法、POA算法、智能算法等，开发人员可以集中精力解决可变部分，而不必担心外围工作。

2.4 调度交互界面框架

MVC(Model-View-Controller）把一个应用的输入、处理和输出流程按照Model、View、Controller的方式进行分离，在结构上可以实现内容和显示相互分离，支持多视图展示，具有良好的可扩展性和可维护性。

Model即应用程序的数据模型，在水电调度中表现为调度方案。调度方案实现了调度对象、调度模型、调度成果、调度控制等数据的管理。如防洪调度方案可选定特定的调度对象、调度模型选择、调度边界约束条件的交互式设置等。

View是应用程序的界面。用户通过View操作应用程序，完成与数据模型的交互。在电网水电调度中常用的界面有过程线图、表格、控制按钮、选择下拉框、菜单等进行组合显示，并将Model的计算结果反馈给用户。

Controller是应用程序的控制逻辑，如用户制定发电计划时总是按照对象选择、模型选择、边界约束设置、模型计算、结果输出的顺序执行。

3 三峡葛洲坝梯级电站调度中的应用

水电站厂内经济运行是在满足电能生产的安全、可靠、优质的前提下，合理地组织调度电厂的发电生产设备，以获得尽可能大的经济效益，是电力系统经济调度的一个很重要的环节。根据实际情况，三峡电站考虑了电站左右岸母线分、合约束、切机约束、气蚀等影响，葛洲坝按照了大江、二江的分厂计算，模型部分建立了机组投运顺序分配模型、指定投运机组模型、任意机组组合模型，每种模型封装模型输入和模型输出，模型的可扩展性较好。

在界面设计上，按照MVC模式进行设计，支持多视图（表格、图形的）方式进行结果展示，用户既可以看到分层信息，又能获得统计信息。该项目以2010年5月20日实际运行和模拟运行进行比较，在完整相同的出力过程的前提下，三峡电站可节水440万m3，按当日耗水率进行折算则节能98万kWh，约节省9.8万元；葛洲坝电站可节水2 177万m3，按当日耗水率折算则节能111万kWh，约节省11万元。图7为三峡电站厂内经济运行软件界面。

工程应用经验表明：(1)按照“对象、行为、表现”的思维方式可以抓住电网水电调度软件设计的主线，具有思路清晰、结构合理的特点；(2)设计模式的适量引入是合理的，可以提高框架、代码的重用性，过渡设计将导致类的数量增加，开发人员理解难度加大；(3)模式是对特定的业务逻辑的抽象，但是外界环境发生是不断发生变化的，也应该引入新的设计模式以适应环境。

4 结语

由于电网水电站水库群调度工作涉及流程、数据、专业算法、信息展示等各个环节，因此该课题本质上属于运筹决策问题，而不是结构化的业务工作。需求的不确定性、可变性决定了插件式框架机制是电网水电站水库群调度软件开发的必然选择。本文重点研究了电网水电站水库群调度插件式应用框架，开发人员可以在水电调度对象、调度模型与算法、表现层三个层面实现二次开发，可根据用户需求实现扩展，该技术具有一定的应用前景。

参考文献

[1]王建军.电网水电站水库群跨流域补偿调度方法[J].水电自动化与大坝监测,2010,34(6):57-60.

[2]吴迎新,伍永刚.水电站群调度系统的易扩展性和通用性设计[J].华中电力,2002,15(2):12-14.

[3]何振锋,伍永刚.通用型水库调度决策支持系统设计分析[J].水电自动化与大坝监测,2006,30(4):69-72.

[4]施建强.基于构件技术的水库调度系统研究与实现[J].计算机工程与设计,2004,25(2):291-294.

插件框架 篇3

在互联网和可视化技术快速发展的大背景下, 道路工程网络三维可视化技术由于可以突破时间与空间的限制, 为道路工程建设与运营维护领域提供强大的远程信息展示、查询和分析功能, 应用前景广阔, 同时, 使构建道路工程的web3D立体档案管理系统成为可能[1,2,3,4,5]。

道路工程Web3D档案管理系统的构建应解决好以下几个关键问题:第一, 程序框架需要具备完善、便捷的部署和更新机制。第二, 道路工程档案资料数据量庞大, 海量数据的高效组织和管理是实现网络交互式可视化的核心关键。第三, 信息查询是三维可视化的应用核心, 场景交互技术是实现信息查询的基础。

本文提出了MVCPF程序框架, 应用R-Trees创建空间索引, 实现了海量数据的高效管理, 建立了三维场景的拾取和反馈机制, 实现了三维场景中信息的快速查询, 据此研发了道路工程网络三维立体档案管理系统。

1 三维渲染引擎系统框架

1.1 MVCPF框架设计思想

MVC全名是Model View Controller, 是模型 (model) -视图 (view) -控制器 (controller) 的缩写, 是由Trygve Reenskaug在20世纪70年代为编程语言Smalltalk平台开发的程序设计框架, 是经典设计模式的有机组合, 是面向对象思想的综合应用[6]。将应用需求封装在Model、View、Controller三种对象中:Model表示领域信息的对象, 包含除用于用户界面之外的所有数据及其相关行为;View负责与用户交互, 并将改变通知给另外两个对象;Controller负责处理业务逻辑, 最后通过消息响应和数据共享将M、V、C融合成为统一整体[7]。MVC自问世以来在框架设计领域倍受青睐。模块化设计符合人类认识事物和解决问题的基本规律, 由于最大程度上支持代码的复用性, 从而提高程序开发的效率和可维护性。

本文针对道路工程档案管理网络三维引擎的需求, 将MVC模式与模块化程序设计集成, 设计出MVCPF插件框架, 具有两方面优势: (1) 它以DLL作为插件单元, 可完成应用程序层面的封装和解耦; (2) 借助MVC的消息响应机制和数据共享能力, 可以利用最小的耦合代价实现插件之间的关联和通信。因此, 基于MVCPF框架开发的道路工程Web3D渲染引擎可以从根本上解决发布、更新和扩展问题, 满足网络环境对渲染引擎的相关要求[8]。

1.2 基于MVCPF框架实现道路工程网络三维渲染引擎

(1) 道路工程网络三维渲染引擎的模块划分

依据单一职责原则, 道路工程网络三维立体档案管理系统的模块插件划分如下: (1) 数据输入输出 (IO) 插件:数据库读写。 (2) 空间线位计算插件:道路线形空间计算。 (3) 建模插件:道路场景搭建。 (4) 渲染插件:三维场景渲染循环。 (5) 场景交互组件:场景交互。 (6) 其他辅助插件。

上述插件共同构成了功能完整、易于扩展的道路工程网络三维渲染引擎 (图1为渲染引擎设计UML图) 。

所设计的每个插件模块都符合MVC模式的要求。其中, 渲染插件是整个引擎中最重要的组件, 负责三维场景的渲染循环, 现以渲染插件为例说明其MVC结构。

Model由“项目信息代理”“根节点代理”组成, “项目信息代理”存储项目路径及名称等信息;“根节点代理”存储三维场景图的根节点指针, 供其他插件获取;

View包含“视窗中介”, 用以存储三维渲染视窗指针, 并开放相关交互接口;

Controller主要包含“启动与终止渲染”“加载与卸载模型”“设置与变换视点”等命令, 供其他插件调用。

(2) MVCPF框架运行流程

(1) 加载插件:插件主控加载子插件的DLL, 向子插件发送注册消息。子插件生成MVC对象实例, 并将其返回插件主控。

(2) 设置插件依赖关系:依赖关系的表现形式有两种:需要响应对方的消息和需要共享对方的数据。因此依赖关系分为两类, 一类是A插件依赖于B插件, 即A插件需要共享B插件的数据或是需要响应B插件的消息;另一类是B插件依赖于A插件。

道路三维引擎主要插件之间的依赖关系如下:渲染插件与数据输入输出插件均为独立插件, 不需设置依赖关系;.建模插件依赖于渲染插件和空间线位计算插件, 它利用空间线位计算插件计算线位空间坐标以创建道路三维模型, 并利用渲染插件的“加载模型命令”将道路三维模型加入场景图;空间线位计算插件读取线路数据是依赖于数据输入输出插件开放的数据库操作接口。 (渲染引擎运行时序与插件依赖关系如图2。)

(3) 启动消息循环:各子插件协同合作, 响应用户交互、处理业务逻辑、完成数据操作。

(4) 卸载插件:插件主控按需要的顺序向各子插件发送Remove消息。

从上述流程可见, 通过设置插件间的相互依赖关系, 建立了消息响应和数据共享, 使各插件形成表面上彼此独立、本质上相互关联的有机整体。

综上所述, 以MVCPF框架为基础的道路工程网络三维渲染引擎具有如下特点:

(1) 体积小巧, 仅包含c++标准模板库 (STL) , 不包含MFC等重量级类库。预留跨平台移植能力。

(2) 剥离ActiveX控件对第三方库的依赖, 部署时摆脱环境变量约束, 并可以实现应用程序自更新。

(3) 模块化业务逻辑。可根据应用需要对各个功能模块进行选择性发布和针对性更新。

(4) 封装用户交互组件, 提供统一的扩展接口, 可根据用户需求定制个性化场景交互组件。

(5) 健全的消息响应和数据共享机制。三维引擎的生命周期是一个大的消息响应循环, 用户交互也通过发送消息完成, MVCPF健全的插件间消息响应机制保证了渲染引擎对效率的高要求。

2 道路工程档案数据管理

道路工程网络三维立体档案管理系统的数据按其时变特性, 可分为静态数据与动态数据。静态数据是指在场景中不随时间而变化的数据, 如地形、地质、环境等基础地理信息数据, 道路空间线位及桥隧结构物等勘察设计数据。动态数据通常需要根据工程的进度、监控周期的变化而动态更新, 数据种类繁多, 如工程进度、投资、运维、监控等数据, 随着时间的推移, 数据量不断增大, 具有海量特征, 如何实现高效的组织和管理, 快速检索所需的数据, 而不因提取数据而造成场景浏览过程中的停滞是实现道路工程档案信息查询的关键。为此, 本文基于R-Trees为数据创建空间索引。

R-Trees管理空间数据的核心思想是使用最小包围矩形组织和约束相邻的几何体, 把目标区域内位置邻近的空间目标, 按区域相关聚集, 逐渐细化区域范围, 从而建立根节点、中间节点和页节点。图3展示了一个应用R-Trees组织几何体数据的实例。

信息平台采用Oracle数据库为模型提供数据存储, 应用R-Trees对空间数据进行管理, 实现了道路工程档案数据的高效组织与管理。

3 网络环境下道路工程三维场景交互技术

(1) 对象拾取

在场景交互时, 往往需要拾取场景对象, 最常见的做法是利用鼠标选取所要查询对象, 点击鼠标, 此时程序内部进行运算, 将二维的屏幕坐标位置映射到正确的三维场景图形节点上, 并保存节点地址, 完成拾取操作。由二维屏幕坐标转换为三维场景坐标的原理如下:

式中已知参数有: (Xs, Ys, Zs) ———视点的地面坐标;α———水平视角;θ———垂直视角;f———视点距投影面的距离。而 (λx, λy, x0, y0) 可以通过计算机显示屏的值域在绘制立体透视图中确定。

设当前鼠标所在的屏幕坐标为 (xρ, yρ) , 将坐标值代入式 (1) 中, 仅有两个方程, 不足以解 (X, Y, Z) 三个未知数, 可以用以下算法解决: (1) 设当前鼠标位置 (xρ, yρ) 对应的空间点高程近似值为Z0; (2) 由式 (1) , 求出 (X, Y) ; (3) 根据 (X, Y) 利用数字地面模型或设计线模型内插出高程Z1; (4) 以Z1为初值, 重复 (1) ~ (3) , 直到|Z1-Z0|< (限差ΔZ) 为止; (5) 输出计算结果 (X, Y, Z) 。

(2) 根据解算出来的三维场景坐标后, 根据R-Tree建立的空间索引, 检索出所选对象的工程名称, 标识选中物体。

(3) 对于选中的物体, 如果用户申请查询档案信息, 则根据模型名称在所绘制的对象中进行比对, 以获取其基本信息, 然后由这些基本信息组成数据库的查询条件。

(4) 将查询条件提交到数据库, 以ToolTip或二维图表的方式反馈查询结果。

基于以上原理, 信息平台实现了各类道路工程档案信息的查询。

4 应用实例

本研究开发的道路工程网络三维立体档案资料管理系统实现了道路工程勘察设计、建设管理、运营维护管理信息的数字化, 建立了B/S架构下远程交互式可视化的工程档案信息查询、分析、展示的平台, 实现了上述信息的集成与共享, 能够满足道路工程档案资料管理的客观需求。道路工程建设与运维管理人员可突破时空限制、直观生动地查询、分析道路工程三维立体档案信息, 提高了管理效率与水平, 具有良好的社会经济效益。

针对高速公路运营管理方提出的机电设备信息查询服务需求, 开发的机电设备档案管理系统充分发挥了三维平台的信息集成优势, 使管理人员能全面、及时、直观地获取机电设备档案信息, 为设备安装维护、保障运营安全提供了技术支持 (如图6、图7) 。

摘要：为实现道路工程档案管理的数字化与可视化, 将MVC模式和模块化程序设计理念相结合, 提出MVCPF插件框架。该框架依据单一职责原则将应用程序划分为若干功能插件, 其中各子插件遵循MVC设计模式要求, 借助MVC的消息响应和数据共享能力彼此建立通信机制, 形成表面上相互独立、本质上彼此关联的统一整体。以此框架为基础, 应用R-Trees创建空间索引, 实现海量数据的高效管理, 建立三维场景的拾取和反馈机制, 实现三维场景中信息的快速查询, 据此研发道路工程网络三维立体档案管理系统, 具有结构清晰、体积小、扩展性强等特点, 实现道路工程档案信息的网络三维可视化与实时查询。

关键词：网络三维,MVC设计模式,插件框架,道路工程

参考文献

[1]符锌砂.公路实时三维可视化系统构架[J].中国公路学报, 2007, 20 (6) :31~36.

[2]符锌砂, 王彦军.道路三维可视化设计系统的系统分析[J].中外公路, 2006, 26 (1) :1~4.

[3]朱庆, 吴波, 钟正.三维GIS与公路CAD的集成[J].中国公路学报, 2006, 19 (4) :1~6.

[4]宋占峰, 詹振炎, 蒲浩.道路整体三维模型构建方法的研究[J].中国铁道科学, 2003, 24 (4) :107~110.

[5]朱江, 蒲浩.基于WebGIS与ASP.Net的公路工程施工形象进度网上展示系统构建方法[J].交通与计算机, 2007, 25 (5) :81~84.

[6]Gamma E, Helm R, Johnson R, Vlissides J.Design patterns:Elements of reusable object-oriented software[M].Boston:Addison Wesley, 1995.

[7]Fowler M.Patterns of enterprise application architecture[M].New Jersey:Pearson Education, 2002.