ARTICLE · 1256762
ArcHIGH水文水动力模型软件—架构
这是 ArcHIGH 架构系列的第一篇。后面几篇继续深入：模型怎么和 GIS 揉成一体（架构 1）、接口图层渲染器怎么设计（架构 2）、一个模型怎么真正跑起来。
一、整体软件框架
接下来的几篇要讲的就是ArcHIGH软件设计的事 —— 怎么让水文模型和 GIS 的数据结构揉成一体，接口、图层、渲染器怎么设计，以及一个模型从无到有跑起来的完整流程。这些都比较偏软件架构设计，理解起来可能比较费劲，但这是整个 ArcHIGH 架构的地基，也是后面所有能力的地基，值得仔细记录下思路，怎么使用这个软件我打算稍后再放。
软件框架是一个系统工程，在没有高级架构师帮我设计的情况下，学习GIS软件王者ArcGIS软件自身的架构设计是一个好办法。在系统学习了ArcGIS软件架构的相关文档后，实现了它类似的界面插件机制，并且扩展出了模型插件机制，也实现了类似的GIS核心组件代码，甚至连组件的名字都和ArcGIS差不多，这也是软件为什么以Arc开头的原因，当然我写的这套GIS组件远没有ArcGIS Engine强大，但对于ArcHIGH够用了。
本软件从根上分成两半：界面插件容器和模型插件容器。
这张图自上而下看：
最上面是 ArcHIGH 系统，它做两件事：统一装载、统一调度。所有的插件——界面的、模型的——都由它管。
中间是两个容器，上下排列。 上面是界面插件容器，底下是各模型的 UI 插件；下面是模型插件容器，底下是各计算模型。两个容器是并列关系，一个管"长什么样"，一个管"算什么"。虚线框的表示后续可以继续扩充。
最下面是「构建及修改模型」，靠两条竖直通道和上面两个容器相连。 右侧绿色通道向下，标着「↓ 调模型计算」；左侧蓝色通道向上，标着「↑ 交结果去显示」。
方向正好相反，这不是画着玩的 —— 模型和 UI 全程不直接说话，只跟这条链路打交道。 这就是"界面与计算分离"的落地处。
分这么开，是因为界面和模型本来就是两件事：界面要处理交互与布局，模型要处理数值稳定与效率。界面怎么变不影响模型，模型怎么换不用改界面。
二、插件式框架：界面模型均是插件
容器是逻辑上的概念，那它靠什么落地？插件式框架。插件式框架就有宿主和插件两个东西，宿主是插件这套机制运转起来的管理器和调度器，你可以把它理解成一块电脑主板，插件是接电的CPU、内存等元件，他们相互之间通过主板上的电路线实现功能交互。
ArcHIGH采用的是类似 ArcGIS 的插件架构 —— 按钮和界面本身都是插件。宿主程序不预置任何具体界面，只提供一个空壳：按钮、工具、面板这些"槽位"，以及装载和调度插件的能力。
插件是个什么东西
想加能力就插一个，想换能力就换一个 —— 宿主不用改一行代码。
实际长什么样
下面是 ArcHIGH 软件的代码树，采用Visual Studio 2022版本编写，左边是各专业模型，右边是系统框架核心：
插件都是成对的
仔细看命名规律会发现，所有模型都是一对出现的 —— 模型名加上 UI 后缀，就是它对应的界面：
| 城市洪水 | dbsCityFlood | dbsCityFloodUI | |
| 地下水 | dbsGroundWater | dbsGroundWaterUI | |
| 平原 | dbsPlain | dbsPlainUI | |
| 水动力 | dbsRiverModel | dbsRiverModelUI | |
| 水文 | dbsHydrology | dbsHydrologyUI | |
| 框架核心 | dbsFramework | dbsFrameworkUI | |
| 主程序 | dbsSystem | dbsSystemUI |
左边是计算逻辑，右边是它对应的界面，一个模型配一个 UI。再回头看上面那张代码树，会发现它们是上下挨着排的 —— dbsCityFlood 下面紧跟着 dbsCityFloodUI，一对一对地出现。
所以模型和界面是两个独立的编译单元，各自有独立的生命周期，谁也不包含谁。
这个"成对"的设计带来了一个很实际的好处：换模型不用换界面。 界面那一侧是固定的，它只认"调用模型"这一件事，具体调的是新安江还是别的算法，界面完全不知道。
除了模型，还有两类插件
插件树右半部分"模型系统应用"里，还有几个不是专业模型的：
dbsFramework/dbsFrameworkUI—— 建模框架，负责模型怎么组织、怎么构建 dbsIntegrate/dbsIntegrateUI、 dbsPython/dbsPythonUI—— 集成与脚本能力ModDLL、PDFAF这类 IFX 接口组件 —— 提供通用的底层能力
"主程序应用"那一组则是另一层：ArcHIGH（主程序本体）、dbsSystem / dbsSystemUI（系统设置主控）、dbsSetup、dbsControls、dbsGeneralBase 这些，管的是软件自己的事。
这么分的优势是：专业模型是"可替换的"，框架和基础组件是"可复用的"。 换个专业模型只动前者，后者原样留着。
三、插件框架怎么管起来
宿主不是简单地把插件"放进去"就完事，得有一套管理流程。
图上已经标清了，只说那两条橙色的箭头：
装载和注册阶段，界面与模型是分别声明的。 界面插件说清楚自己的按钮放在哪，模型插件说清楚自己的参数和输入输出，宿主只做归集不管业务。
调用阶段，界面向下只交参数，模型向上只回结果。 两条橙色箭头就是全部往来 —— 至于模型内部是新安江还是别的算法，界面完全不知道。所以这个循环可以重复任意多次，模型之间互不感知。
另外，ArcGIS 是菜单工具栏式的界面，我这里的插件按照当前 word 软件类似的 Ribbon 风格设计，更直观一些：
四、这套框架带来了什么
第三方可以扩充。 扩充一个新的模型，只要写一个模型插件；想给它配一套自己的操作界面，再写一个界面插件。宿主不用改一行代码。
跨语言。 COM 组件与具体编程语言无关，C++、C#、VB、Java、Python 都能写插件。
自主可控。 界面和计算逻辑都在自己手里，不依赖任何平台的私有扩展机制。
后面几篇要讲的就是模型容器里的事 —— 怎么让水文模型和 GIS 的数据结构揉成一体，接口、图层、渲染器怎么设计，以及一个模型从无到有跑起来的完整流程。
关于试用的事情统一回复：我正在写各个案例的使用手册，会公开软件给大家试用，近期即可完成。
ArcHIGH 是河海大学水文水资源学院水文预报所团队的水循环模拟软件，自主可控。这里记录它的设计思路、应用案例和一点使用心得。联系人：向小华，邮箱：<xxhxiang@hhu.edu.cn> QQ群：1129879018
