[0001] 本发明属于插件平台技术领域， 具体涉及一种用于药物设计系统的插件系统及 其生成方法和更新方法。 背景技术

[0002] 插件是一种遵循一定规范的应用程序接口编写 出来的程序， 其只能运行在程序 规定的系统平台下 （可能同时支持多个平台） ， 而不能脱离指定的平台单独运 行。 因为插件需要调用原纯净系统提供的函数库或 者数据。

[0003] 在现有的网络环境中， 很多软件都有插件， 而插件也有无数种。 计算机辅助药 物设计是化学、 生物学、 数学、 物理学以及计算机科学交叉的产物， 其也需要 用到插件。 目前来说药物设计软件的插件主要有：

[0004] 原生桌面软件， 原生应用更接近系统， 是传统的 C/S架构， 市面上大多数药物 设计软件都基于该技术构建桌面应用。 原生桌面软件的原生应用更接近系统， 性能是其最大的优势， 但其需要在各平台提供提定制开发， 需要耗费过多人力 、 时间和资金， 长期维护更新还需要耗费更多的精力； 总结其存在以下缺点： 1 .只能处理一些功能单一的多系统； 2.由于需要安装客户端， 安装部署困难， 所 以不易扩展； 3.若客户端使用的系统不同， 就要针对这些系统分别编写程序； 4 .客户端界面缺乏通用性， 且当业务更改时就需要更改界面；

[0005] 基于 web技术构建的基础桌面应用， 使用 Electron构建桌面应用， 可以方便的 在一次编写代码后构建 windows、 mac和 linux平台的桌面应用。 使用 web技术构 建桌面应用， 可以很方便的构建桌面应用， 一次构建应用可以在多个平台运行 ; 但也存在一定的维护缺陷， 例如同时维护多个桌面应用， 每个应用都会由多 个可复用的组件构成， 新功能组件的更新需要应用再次构建、 发布、 用户更新 版本才能体验最新功能的繁琐操作， 其流程图如图 1所示。

[0006] 综上所述， 药物设计软件在药物设计中起着至关重要的作 用， 但其不易于快速 开发迭代与版本更新的问题一直得不到很好的 解决。 桌面端应用避免不了反复 的构建发布与更新， 导致桌面应用维护困难而且用户不能及时体验 最新功能。 [0007] 因此， 怎样才能够提供一种实现简单， 易于快速开发迭代和版本更新的一种用 于药物设计系统的插件系统及其生成方法和更 新方法， 成为本领域技术人员有 待解决的技术问题。 发明概 述 技术问题 问题的解 决方案 技术解决方案

[0008] 针对上述现有技术的不足， 本发明所要解决的技术问题是： 怎样才能够提供一 种实现简单， 易于快速开发迭代和版本更新的一种用于药物 设计系统的插件系 统及其生成方法和更新方法。

[0009] 为了解决上述技术问题， 本发明采用了如下的技术方案：

[0010] 一种用于药物设计系统的插件系统， 包括：

[0011] 基线管理模块： 基线版本按照一个季度或固定时间点更新；

[0012] 配置表： 所述配置表用于配置表示一个场景所有信息的 描述， 其中， 所述配置 表描述了如何将多个插件 Panel组合为一个场景。

[0013] 进一步地， 所述的配置表中有以下关键字段：

[0014] 名称， 场景的唯一标识；

[0015] 描述， 场景的描述；

[0016] 版本， 场景的更新依据；

[0017] 插件， 场景所需要的插件列表；

[0018] 布局， 场景需要使用插件进行布局绘制的依据。

[0019] 进一步地， 所述插件系统向外暴露多个 panel、 cell和 lib， 其中， panel、 cel 1和 lib分别采用插件系统提供的接口进行交互； 其中， 所述插件系统将根据配 置表描述的 Panel组合布局进行绘制；

[0020] 更进一步地， 所述的 Panel由插件系统注入到指定 panel区域， 由插件系统控制 灵活布局； [0021] 其中， 一个 Panel中包含多个 Cell， 由插件开发者指定 Cell占位， 由插件系统 加载具体插件；

[0022] 其中， Lib只暴露方法而没有可视化界面的类型。

[0023] 本申请另外提供了一种用于药物设计系统的插 件系统的生成方法， 用于生成所 述的用于药物设计系统的插件系统， 所述的插件生成方法的步骤为：

[0024] 步骤 S101: 编写一个或多个单独维护的插件， 启动药物设计系统时， 读取插件 声明定义；

[0025] 步骤 S102: 根据插件声明定义， 将药物设计系统中的控件转换为通用控件对像 ; 编写一个场景配置描述用插件如何布局；

[0026] 步骤 S103: 插件根据配置表加载并渲染插件；

[0027] 步骤 S104: 插件提供自由布局自由改变 Panel面板位置；

[0028] 步骤 S105: 回到步骤 S101， 为插件添加新功能并修改版本号；

[0029] 步骤 S106: 检测插件存在新版本， 下载使用新插件。

[0030] 进一步地， 上述的用于药物设计系统的插件系统的生成方 法， 是通过以下的插 件生成系统来实现， 所述的插件生成系统包括：

[0031] 读取模块， 所述读取模块在启动药物设计系统时， 用于读取插件的声明定义； [0032] 渲染插件模块， 所述渲染插件模块能够根据配置表加载并渲染 插件；

[0033] 布局模块， 所述布局模块能够自由布局以实现自由改变 Panel面板位置；

[0034] 添加模块， 所述添加模块用于为插件添加新功能并修改版 本号；

[0035] 下载模块， 所述下载模块用于检测插件是否存在新版本， 当插件存在新版本时 ， 该下载模块启动下载程序来下载新插件， 然后使用新插件。

[0036] 进一步地， 还包括： 优化模块， 该优化模块用于将所述插件中的冗余数据和无 效数据进行删除。

[0037] 本申请还提供了一种用于药物设计系统的插件 系统的更新方法， 包括以下步骤

[0038] (A)、 插件平台被启动后， 获取本地的核心插件对应的更新策略， 检查基线是 否更新；

[0039] (B)、 检测出基线有新版本， 则说明当前为可更新状态， 立即检查配置表版本 [0040] (C)、 判断配置表是否存在版本， 如果是， 则下载最新配置表；

[0041] (D)、 读取最新配置表， 检查插件列表；

[0042] (E)、 插件存在新版本， 更新插件。

[0043] 进一步地， 上述的用于药物设计系统的插件系统的更新方 法， 是通过以下的插 件更新规则来实现， 所述插件更新规则包括下列至少之一：

[0044] 规则一： 当前已安装插件是否位于可安装的最低版本与 最高版本间范围；

[0045] 规则二： 当前已安装插件是否属于可安装的随机版本号 ；

[0046] 规则三： 当前已安装插件是否属于可安装的忽略版本号 。

[0047] 进一步地， 上述的用于药物设计系统的插件系统的更新方 法， 是通过以下的更 新系统来实现的， 所述的更新系统应用于插件宿主， 更新系统包括：

[0048] 确定模块， 确定待加载的插件的进程， 检查基线是否更新；

[0049] 判断模块， 判断配置表是否存在版本， 如果是， 则下载最新配置表；

[0050] 读取模块， 读取最新配置表， 检查插件列表；

[0051] 运行模块， 插件存在新版本， 更新插件。 发明的 有益效果 有益效果

[0052] 与现有技术相比， 本发明具有如下优点：

[0053] 1 ) 本申请所述的插件平台可以理解为一种宿主程 序， 提供可被插件调用的接 口。 从一种角度来理解插件平台， 插件平台可以是一种应用程序， 其可以提供 某种应用服务。 从另一种角度来理解插件平台， 插件平台可以是一种客户端程 序， 其可与服务端程序或后台进行交互。

[0054] 2) 本发明所提供的插件只需要负责开发小部分业 务， 这将有效为药物设计软 件提供快速开发的能力， 用户可以更便捷地体验到新功能， 插件系统作为软件 宿主动态加载本地插件需要具备一些插件管理 能力。 对附图 的简要说 明 附图说明

[0055] 图 1为根据本发明中的应用于插件宿主的插件生� �方法的流程图； [0056] 图 2为根据本发明中的应用于插件宿主的插件生� �方法的代码示意图；

[0057] 图 3为根据本发明中的应用于插件宿主的插件生� �方法的流程图；

[0058] 图 4为根据本发明中的应用于插件宿主的插件更� �方法的流程图；

[0059] 图 5为根据本发明中的应用于安装插件后插件视� �在实际工程中的截图；

[0060] 图 6为根据本发明中的设计截图；

[0061] 图 7为根据本发明中的 package, j son文件示例；

[0062] 图 8为现有技术的流程图。 发明实施 例 本发明的实施方 式

[0063] 下面将结合附图及实施例对本发明作进一步说 明。

[0064] 实施例 1: 如图 1所示， 一种用于药物设计系统的插件系统， 包括：

[0065] 基线管理模块： 基线版本按照一个季度或固定时间点更新， 由管理者管理基线 ， 保证当前基线内插件间依赖绝对可用；

[0066] 配置表： 所述配置表用于配置表示一个场景所有信息的 描述， 其中， 所述配置 表描述了如何将多个插件 Panel组合为一个场景。 其中， 如图 2所示， 所述的配 置表中有以下关键字段： Name （名称） ：场景的唯一标识； Description （描述 ） : 场景的描述； Version （版本） ： 场景的更新依据； Plugins （插件） ： 场 景所需要的插件列表； Layout （布局） ： 场景需要使用插件进行布局绘制的依 据。

[0067] 实施例 2: 如图 3所示， 一个插件可以理解为一个包， 其向外暴露多个 panel、 c ell和 lib， 插件开发者使用插件系统提供的接口进行交互 ； 系统将根据配置表 描述的 Panel组合布局进行绘制。

[0068] Panel （可视区域）

[0069] 由插件系统注入到指定 panel区域， 由插件系统控制灵活布局。

[0070] Cell （可视区域）

[0071] 一个 Panel中可包含多个 Cell， 由插件开发者指定 Cell占位， 由插件系统加载 具体插件。

[0072] Lib （非可视区域） [0073] 只暴露方法而没有可视化界面的类型， 一般可用于算法封装或数据处理。 [0074] 实施例 3:

[0075] 插件更新方式， 如图 4所示： 关于插件间版本依赖、 插件依赖宿主接口版本， 这种耦合关系下， 如果被依赖方版本变动 （发生功能逻辑和接口改动） ， 需要 如何兼容保证整体 APP正常运行， 为保证这一点插件只有在基线版本升级后才统 一更新， 更新流程：

[0076] 发起检查动作后首先检查基线是否更新；

[0077] 基线有新版本说明当前为可更新状态， 立即检查配置表版本；

[0078] 配置表存在版本， 立即下载最新配置表；

[0079] 读取最新配置表， 检查插件列表；

[0080] 插件存在新版本， 立即更新插件；

[0081] 安装插件后无需其它操作即可及时使用， 插件将根据配置表的布局描述加载插 件并进行布局绘制， 如图 5所示。

[0082] 本发明以 GUI插件系统的形式避免终端软件开发者维护多 个终端软件开发， 很 好的提升了开发效率。

[0083] 采用本发明的方案， 仅需安装一次 GUI插件系统的宿主应用， 即可增量体验更 多的终端应用， 避免用户安装多个应用， 很好的提升了用户体验。

[0084] 采用本发明的方案的效果对比如表 1所示：

[0085] 表 1 []

[表 1]

[0086]

[0087] 本申请应用在药物设计系统时， 如图 7所示， 将传统的药物设计业务流程拆分 成负责独立模块的插件。 业务模块抽象为插件， 插件生成与运行的具体步骤为

[0088] 第一步： 编写插件具体构成内容， 由视图展示与业务逻辑组成， 在之前的说明 中已经提及插件的构成为Panel/Cell/Lib

[0089] 第二步： 在插件目录下的package, json描述该插件下的Panel/Cell/Lib， 供框 架调用对应模块。

[0090] 第三步： 编写场景配置文件， 描述该场景所依赖的插件 (plugins) 以及使用 插件Panel绘制的默认布局 (layout) 等信息， 场景与插件文件都存放到统一目 录下等待框架使用时加载。

[0091] 第四步： 运行框架时默认读取场景配置， 框架使用插件前， 根据场景配置中的 plugins字段查找需要的插件预加载到内存。

[0092] 第五步： 框架根据场景配置表中的layout描述， 绘制默认的布局， 将插件的Pa nel加载到指定的Panel位置。

[0093] 得益于自由布局， 由panel呈现的业务模块， 可以自由拖动以满足复杂的设计 场景。

[0094] 复杂的算法逻辑可以存放到 1 ib方法库中， 在设计业务中可以便捷调用。

[0095] 插件系统有更新插件的机制， 比较版本 (vision)差异后触发更新机制， 将最新 的插件文件存放到统一目录下， 更新插件以获取最新的功能， 满足设计功能的 快速迭代体验。

[0096] 最后需要说明的是， 以上实施例仅用以说明本发明的技术方案而非 限制技术方 案， 本领域的普通技术人员应当理解， 那些对本发明的技术方案进行修改或者 等同替换， 而不脱离本技术方案的宗旨和范围， 均应涵盖在本发明的权利要求 范围当中。