CN104657142A - 一种基于OSGi技术的CCFD系统 - Google Patents

Abstract

本发明公开了一种基于OSGi技术的CCFD系统，该系统包括：插件引擎和系统应用插件，其中，所述插件引擎负责所述系统应用插件的安装、卸载及依赖关系验证；所述系统应用插件内部由组件实现，所述组件提供并使用服务；所述系统包括组件管理器，通过解析所述组件的配置文件发现组件发布的服务，并将组件提供的服务注入给申请服务的组件。通过本发明的技术方案，可以实现对CCFD系统的非侵入式灰盒扩展。

Description

一种基于OSGi技术的CCFD系统

技术领域

本发明涉及流体力学计算领域，尤其涉及一种基于OSGi技术的CCFD系统。

背景技术

计算流体力学(Computational fluid dynamics,简称CFD)技术已被广泛使用在各种流体工程领域，如航空、航天、船舶、动力、水利等，而且在逐渐向化工、核能、冶金、建筑、环境等相关领域扩展。目前国内飞机设计领域使用的CFD产品以国外的商业软件为主。这些软件存在着精度有限、并行规模受限等缺点。

国内具有自主知识产权的万核量级的飞机气动分析应用软件(China Computational fluid dynamics，简称CCFD)是一个国家863计划下的重要项目。万核量级的飞机气动分析应用软件需要逐步地将每个阶段实现的功能模块无缝集成并且可以快速、低成本的实行。万核量级的飞机气动分析应用软件需要具有开放的特征，即支持用户集成第三方的工具和模块，具有可扩展架构的设计是软件的必要条件。

现有技术采用基于Java Swing的MVC架构，以用户接口为中心实现系统功能。在系统设计时，以用户界面为设计首要，通过对Java Swing组件的继承扩展实现软件功能。MVC架构的软件在结构上形成组件树，整个软件位于同一个可见范围内，对于任一个功能模块提供的功能，其他模块都可以通过遍历组件树的方式查找使用。由于模块可见性没有限制，软件的众多模块之间形成了一张隐式的引用网。该隐式引用方式通常会造成软件扩展上的障碍，增加软件的复杂性。由于模块的全局可见性及链式调用方式导致模块之间引用的随意性及混乱。

MVC架构对扩展场景的分析且结合系统的架构，实现扩展需要对方案菜单组件、内联窗口组件(含向导管理功能的内联窗口组件，简称向导管理组件)进行重构。在对必须组件进行重构前，首先需要从基本数据中删除原有的相关数据结构，增加新的相关数据结构；然后，在方案菜单组件及向导管理组件中重写部分代码实现方案类型的删除及增加，并且，删除虚拟桌面组件下与方案类型相关的控制文件向导组件；最后，检查软件整体代码确保被删除数据结构的代码未被其他地方引用。由上可见，此种扩展是一种侵入式的开放式扩展。

发明内容

本发明的目的是为了解决现有技术存在的上述不足，提供一种可以实现对CCFD的非侵入式灰盒扩展的系统。

为实现上述目的，一方面，本发明提供了一种基于OSGi技术的CCFD系统所述系统包括：插件引擎和系统应用插件，其中，所述插件引擎负责所述系统应用插件的安装、卸载及依赖关系验证；所述系统应用插件内部由组件实现，所述组件提供并使用服务；所述系统包括组件管理器，通过解析所述组件的配置文件发现组件发布的服务，并将组件提供的服务注入给申请服务的组件。

优选地，该系统将OSGi框架作为所述插件引擎，所述OSGi框架中的DS服务作为系统的组件管理器，管理系统中组件的生命周期及其提供的服务。

优选地，所述系统应用插件以元数据的方式描述插件的基本信息，同时，元数据中也显式的描述了插件之间的依赖关系。

优选地，所述系统应用插件之间的依赖关系建立在粗粒度的源码包级别上。

优选地，所述系统应用插件以JAR文件形式独立地发布，所述JAR文件形式包括元数据文件；所述插件引擎通过所述元数据文件判断所述系统应用 插件的依赖关系是否满足。

优选地，所述插件引擎为功能模块插件提供依赖，具体包括：插件部署到系统后，所述插件引擎通过解析插件元数据获取插件的依赖关系，并将功能模块插件安装到系统中。

优选地，所述组件管理器对所述系统应用插件中的所有组件配置文件进行解析，将服务动态注入到申请服务的组件，获取到服务后，服务实例被扩展，实现系统的扩展。

优选地，扩展以插件为扩展实体实现，具体包括：被扩展的功能模块由插件实现，插件内部由提供真实服务的组件组成，组件可以使用其他插件提供的服务。

优选地，所述系统应用插件包括：图形界面插件，用于为系统提供图形化支持；方案管理器插件，用于提供系统方案类型维护、存在方案管理；作业管理器插件，用于管理系统已存在作业；前后处理管理器插件，用于管理系统支持的前后处理功能。

优选地，所述系统还包括：向导编辑器插件，用于为用户提供图形化编辑参数文件提供便利；日志插件，用于为系统调试及运行监视提供一种重要方式，方便系统的开发和维护。

另一方面，本发明还提供一种基于OSGi技术的CCFD系统，包括：插件引擎，负责系统中插件的安装、卸载及依赖关系验证；图形界面插件，用于为系统提供图形化支持；方案管理器插件，用于提供系统方案类型维护、存在方案管理；作业管理器插件，用于管理系统已存在作业；前后处理管理器插件，用于管理系统支持的前后处理功能。

优选地，所述插件内部由组件实现，组件提供并使用服务；所述系统包括组件管理器，通过解析组件的配置文件发现组件发布的服务，并将组件提供的服务注入给申请服务的组件。

优选地，所述插件以元数据的方式描述插件的基本信息，同时，元数据 中也显式的描述了插件之间的依赖关系。

本发明的模块化机制使得系统模块化方面存在天然的优势，对于系统的扩展只需掌握扩展功能相关的局部即可，且可以以非侵入式的完成功能的扩展，不需对已有系统进行修改。在系统中基于插件引擎可以在软件运行过程中增加、删除及更新插件的方式实现功能的增加、删除及更新。

本发明将功能模块采用插件形式实现，缺省情况下插件对外部为不可见的，模块之间的引用采用显式的在插件元数据中声明。这种模块机制及显式引用方式简化了软件扩展的实现过程，降低了模块间的耦合度，降低了软件的复杂性。其插件引擎管理系统存在的所有插件，组件管理器负责细粒度的组件单元，对软件的扩展表现为向系统中增加新的插件。

在本发明中，任意一种方案类型被实现为一个方案插件，方案插件实现了与该方案类型相关的所有功能，方案插件被独立的部署在系统中。当需要从系统中删除方案类型时，只需要将与方案类型相关的插件文件从软件插件目录下删除即可；当向系统增加方案类型时，只需要按方案类型接口实现方案插件，将插件放置在软件插件目录下即可实现。通过以上描述步骤可见，新系统的扩展是一种非侵入式的灰盒扩展。

附图说明

图1为本发明实施例提供的一种基于OSGi技术的CCFD系统的结构示意图；

图2为本发明实施例提供的另一种基于OSGi技术的CCFD系统结构示意图；

图3为本发明实施例提供的又一种基于OSGi技术的CCFD系统结构示意图；

图4为本发明实施例提供的基于OSGi技术的CCFD工作台软件架构图；

图5为本发明实施例提供的系统插件工程列表的示意图；

图6为本发明实施例提供的基于OSGi技术的CCFD工作台部署图；

图7为本发明实施例提供的系统各插件及其相互间依赖关系的示意图；

图8为本发明实施例提供的CCFD_EC求解器元数据文件描述的示意图；

图9为本发明实施例提供的CCFD_EC求解器插件提供的解决方案组件的示意图；

图10为本发明实施例提供的CCFD_EC求解器插件提供的图形界面参数设置向导组件的示意图；

图11为本发明实施例提供的和如图8所示的CCFD_EC求解器插件提供的前后处理组件的示意图；

图12为本发明实施例提供的CCFD_EC添加效果的示意图。

具体实施方式

为使本发明实施例的技术方案以及优点表达的更清楚，下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

图1为本发明实施例提供的一种基于OSGi技术的CCFD系统的结构示意图。如图1所示，该系统包括：插件引擎11和系统应用插件12，形成了“微内核+插件”的体系结构。

其中，所述插件引擎11负责所述系统应用插件的安装、卸载及依赖关系验证。

所述系统应用插件12内部由组件实现，所述组件提供并使用服务。所述系统包括组件管理器，通过解析所述组件的配置文件发现组件发布的服务，并将组件提供的服务注入给申请服务的组件。

本发明实施例提供的基于OSGi技术的CCFD系统利用“微内核+插件”的架构，将功能模块采用插件形式实现。其插件引擎管理系统存在的所有插件，组件管理器负责细粒度的组件单元，对软件的扩展表现为向系统中增加新的插件。这种模块机制及显式引用方式简化了软件扩展的实现过程，降低了模 块间的耦合度，降低了软件的复杂性。

图2为本发明实施例提供的另一种基于OSGi技术的CCFD系统结构示意图。如图2所示，该系统包括插件引擎11和系统应用插件12，其中，系统应用插件12包括：图形界面插件21，方案管理器插件22，作业管理器插件23，前后处理管理器插件24。

图形界面插件21用于为系统提供图形化支持。

方案管理器插件22用于提供系统方案类型维护、存在方案管理。

作业管理器插件23用于管理系统已存在作业。

前后处理管理器插件24用于管理系统支持的前后处理功能。

图3为本发明实施例提供的又一种基于OSGi技术的CCFD系统结构示意图。如图3所示，该系统包括插件引擎11和系统应用插件12，其中，系统应用插件12包括：图形界面插件21，方案管理器插件22，作业管理器插件23，前后处理管理器插件24、向导编辑器插件31和日志插件32。

图形界面插件21用于为系统提供图形化支持。

方案管理器插件22用于提供系统方案类型维护、存在方案管理。

作业管理器插件23用于管理系统已存在作业。

前后处理管理器插件24用于管理系统支持的前后处理功能。

向导编辑器插件31，用于为用户提供图形化编辑参数文件提供便利。

日志插件32，用于为系统调试及运行监视提供一种重要方式，方便系统的开发和维护。

本发明实施例提供的基于OSGi技术的CCFD系统利用开放的、标准化的严格遵守OSGi规范的纯插件式架构，将软件功能以插件的形式模块化的集成到系统中，使系统的扩展只需掌握扩展功能相关的局部即可，且可以以非侵入式的完成功能的扩展，不需对已有的系统进行修改。在系统中基于插件引擎可以在软件运行过程中增加、删除及更新插件的方式实现功能的增加、删除及更新。

图4为本发明实施例提供的基于OSGi技术的CCFD工作台软件架构图。本发明提供的一种基于OSGi技术的CCFD系统，所述系统采用了开放的、标准化的严格遵守OSGi规范的纯插件式架构。软件功能以插件的形式模块化的集成到系统中。如图4所示，系统分为插件引擎和系统应用插件两大部分，形成了“微内核+插件”的体系结构。OSGi作为系统的插件引擎，负责系统中插件的安装、卸载及依赖关系验证等。系统的应用插件包括图形界面插件、方案管理器、作业管理器、前后处理管理器、向导编辑器、日志等。其中图形界面插件为系统提供图形化支持。方案管理器是提供了用于系统方案类型维护、存在方案管理的插件。作业管理器是用于管理系统已存在作业的插件。前后处理管理器是用于管理系统支持的前后处理功能的插件。向导编辑器为用户提供图形化编辑参数文件提供便利。日志插件为系统调试及运行监视提供了一种重要方式，方便系统的开发和维护。

基于OSGi技术的CCFD系统实现了“微内核+插件”的软件架构，系统实现为插件的集合。OSGi作为系统的微内核，其本身也由插件实现，微内核作为系统的插件引擎管理除内核之外的其余插件。系统功能均以插件的形式实现并部署到系统中。遵循面向服务的组件模型，插件内部由组件实现，组件提供并使用服务。OSGi规范中的Declarative Services(简称DS)作为系统的组件管理容器，管理系统中组件的生命周期及其提供的服务。基于OSGi技术的CCFD系统共实现了图5所示的11个插件。

a.插件的实现 

在基于OSGi技术的CCFD系统中，一个插件由一个插件工程实现，插件工程与传统的Java工程没有太大的区别，只是插件工程增加了一些插件相关元数据，且可以得到Eclipse集成开发环境的特殊支持。插件的实现主要涉及到插件功能实现的方式以及插件依赖关系的建立。

插件功能实现方式与传统面向对象系统没有本质的区别，系统的各种功能由许许多多的不同对象协作完成。在遵循传统面向对象系统的实现方式的 同时，CCFD工作台系统还借鉴了面向接口编程的思想。在插件内部，耦合性比较高的对象之间采用传统的对象直接调用的方式，而耦合性比较弱及需要与其他插件产生依赖的部分则通过接口的方式降低系统的耦合度。在实现功能时，将接口定义与功能实现分离，且放置在不同的源码包中，插件之间的依赖建立在粗粒度的源码包级别上。具体的，将定义接口的源码包导出供其他插件使用，这样插件之间依赖于接口而不是具体实现。

插件以元数据的方式描述插件的标识、名称、版本号等基本信息。同时，元数据中也显式的描述了插件之间的依赖关系。CCFD工作台系统中插件的元数据信息被一致的记录在元数据文件META-INF/MANIFEST.MF中，表1是CCFD工作台系统UI插件的元数据文件内容。其中Imort-Package描述了UI插件依赖于其他插件提供的包org.osgi.framework。同理，Export-Package声明了UI插件导出的源码包，其他插件可以导入，使用这些包提供的功能代码，从而产生插件间的静态依赖关系。

表1 插件元数据

插件独立地发布且以JAR文件的形式包括了图标等资源文件、编译后的 类文件及元数据文件。OSGi插件引擎通过元数据文件判断插件的依赖关系是否满足，至此，插件的生命周期交由插件引擎管理。

b.组件的实现 

插件是CCFD工作台系统的一级模块化概念，而组件则是真正提供服务的功能单元。组件位于插件中，一个组件可以暴露出多个服务，同时也可依赖于多个服务。在CCFD工作台系统中，组件被实现为普通Java类，服务被实现为接口Interface、Java类,实现了某个接口则Java类代表的组件提供了Interface代表的服务，一个Java类可以实现多个Interface，所以一个组件可以提供多个服务。一个Java类可以使用多个Java类提供的功能，而这些类可能实现了某些接口，从而一个组件可以依赖于多个服务。组件以显式声明的方式发布服务、申请服务，只有发布的服务才可以被其他组件使用，只有申请了服务，服务才会被注入到组件中。每个组件使用一个遵守XML协议的文件描述组件配置信息，包括如组件的类型、组件的提供的服务以及申请的服务等。

表2是图形界面插件中Desktop组件的配置文件，该组件在系统中唯一的名称是sccas.ccfd.ui.mainzone.desktop，service标签中描述了Desktop组件提供了IDesktop服务，implementation标签描述了实现该服务的一个Java类sccas.ccfd.ui.mainzone.desktop.Desktop，同时该组件引用了服务sccas.ccfd.ui.Mainframe和sccas.ccfd.ui.mainzone.desktop.service.IFrameFactory，引用服务通过reference标签描述。

在插件工程中，组件配置文件被统一管理，放置在插件工程目录中的OSGI-INF目录下，并在Manifest文件中增加组件定义文件路径。

表2 Desktop组件配置文件 

c.动态化的实现 

CCFD工作台系统采用了声明式服务，由组件管理器管理系统存在的组件，在提供的服务和申请的服务之间建立动态依赖关系。系统使用了OSGi的Declarative Services作为其组件管理器，DS通过解析组件的配置文件发现组件发布的服务，并将其动态的注入给申请服务的组件。服务的注入通过DS调用组件提供的服务设置方法实现。

表3菜单栏组件注入、移除接口

具体地，申请服务的组件定义了一组服务设置方法，方法以申请服务的Interface为参数，且方法在组件配置文件中描述，当系统中出现新组件且提供Interface时，DS就调用服务设置方法，并以新组件作为参数，这样就实现了服务的准确注入。同理，组件需要定义一组服务移除方法，在服务消失时DS可以调用该方法将服务从组件中动态移除。在实际应用中，服务的注入还存在属性过滤、版本过滤等内容。表3展示了菜单栏组件的注入、移除服务方法，表4展示了绑定关系在组件配置文件中的描述。

存在动态机制的系统实现出的系统不一定就是动态的，比如跨平台的Java语言构建出的系统不一定绝对是跨平台的。在实现系统时，系统的动态特性被特别关注，组件被实现为：(1)服务可以在任何时刻被注入组件；(2)服务缺失的情况下，不会出现异常；(3)服务的注入和移除不会造成系统崩溃。

表4 绑定关系描述

d.可扩展的实现 

CCFD工作台系统的扩展以插件为扩展实体实现。被扩展的功能模块被设计为插件，插件内部由提供真实服务的组件组成，组件可以使用其他插件提供的服务。插件部署到系统中后，OSGi插件引擎通过解析插件元数据获取其依赖关系，如果依赖关系满足则将其安装到系统中。DS对插件中的所有组件配置文件进行解析，将配置文件中提供的服务及申请的服务发布到系统中，并对可能产生的服务依赖建立绑定，即将服务动态的注入到申请服务的组件。申请服务的组件动态的获取到服务后，其可使用的服务实例被扩展，这样实现了系统的扩展。以下将介绍系统中目前存在的4类扩展问题的详细实现。

(1)菜单扩展

一个功能扩展的实现包括三方面：服务定义，服务使用者，服务提供者。下面将从这三方面分别介绍菜单功能扩展的实现。

在CCFD工作台系统中，菜单服务被定义为IMenu接口，IMenu接口中定义了服务提供的信息：(1)菜单树实现，(2)扩展位置描述信息。菜单树的实现使用Java Swing的JMenu控件实现，且可以形成树状。扩展位置的描述采用了URI协议错误！未找到引用源。但对其进行了语义化定制。URI常见的使用方法如下所示：

[scheme:][//authority][path][？query]

在IMenu服务中约定scheme描述对哪种类型的菜单扩展，支持的类型有主菜单、上下文菜单等，authority用于描述对哪个顶级菜单扩展，path描述了在顶级菜单下被扩展菜单的路径，query描述了在被扩展菜单的孩子节点中的准确位置。例如，“menubar://文件/导入？after＝导入文件”描述了在主菜单menubar的‘文件’顶级菜单下扩展，扩展路径为‘导入’，即在‘导 入’菜单下扩展，而“after＝导入文件”则描述了在‘导入’菜单的子菜单中的准确位置，即在‘导入文件’菜单之后。通过这种方式，扩展位置信息得到了准确描述。

表5展示了IMenu接口的实现代码，其中getMenuItem提供了菜单实现，getMenuURI提供了菜单位置描述信息。

表5 菜单服务接口

CCFD工作台UI插件的Menubar组件为系统提供菜单功能，其是菜单服务的使用者。Menubar组件定义了IMenu服务设置方法、移除方法，且以IMenu作为参数。IMenu服务被注入时，服务设置方法被调用服务。首先，根据IMenu提供的位置信息遍历系统菜单树确定扩展位置，然后按照Java Swing规范将 IMenu提供的子菜单树增加到扩展位置。同理，服务消失时，服务移除方法被调用，子菜单树被从扩展位置移除。

CCFD工作台系统中已存在多个菜单扩展实例，例如，方案管理插件提供了方案菜单服务，作业管理插件提供了作业菜单服务。菜单管理插件中的方案菜单组件实现了IMenu接口，并按照接口规范实现了菜单扩展位置并提供了菜单树实现。作业管理插件的作业菜单组件实现了IMenu接口，提供了作业菜单管理服务。

(2)方案类型扩展 

方案类型的扩展与菜单扩展相似，都涉及三方面，但实现方式存在着一定差异。在方案类型扩展中，服务使用者是方案管理器插件，方案插件则是服务的提供者。

方案类型扩展通过方案工厂服务的扩展实现。方案工厂用于创建方案实例，一个方案工厂与一种方案类型一一对应，即一个方案工厂能且只能创建一种类型方案的实例。在CCFD工作台系统中，所有方案都需要遵守方案接口定义的规范，因此方案管理器通过方案接口、方案工厂服务实现对系统存在方案、支持的方案类型的管理。方案管理器维护了方案工厂服务实例，且支持对新方案工厂服务的增加和减少。

虽然方案类型扩展由方案工厂服务的扩展实现，但是首先必须定义新的方案类型，方案工厂服务才可以提供新类型方案的创建服务。方案类型定义接口由ISolution给定，新的方案类型必须实现该接口，表6是该接口的定义详情，主要定义了方案关键文件获取/设置方法、关键属性获取方法及方案就绪判断。

新的方案类型被定义后，即可构建该类型方案的工厂用于创建新方案。表7是方案工厂服务的接口定义，主要有方案创建方法、方案类型求解器路径及方案有效性判断方法。

方案插件中的方案组件实现ISolution接口且方案工厂组件实现 ISolutionFactory接口，便可提供新方案类型服务。

表6 方案服务接口

表7 方案工厂接口

(3)前后处理扩展 

在前后处理扩展中，服务使用者是前后处理管理器插件，前/后处理插件则是服务的提供者。前后处理管理器插件维护处理服务的实例，且支持对处理服务的增加和减少。以下主要介绍处理服务接口的定义。

由于计算流体力学应用中前/后处理的数据量可能比较大，导致需要较长的时间处理，为了不影响用户使用UI的响应性，需要将处理过程放置在后台运行，即由后台线程执行。鉴于此，处理服务的接口定义如表8所示。 表8处理服务接口

IHandle中明确定义了后台处理线程的标准输出流和标准错误流应该被导出，当然如果IHandle使用者不需要这两个流，则可以使用process函数直接启动处理过程。

在实际使用中，前后处理器并没有将IHandle直接导出，而是定义了两个接口IPreHandle和IPostHandle且都继承IHandle，用于区分前处理功能和后处理功能，如表9所示。

表9 前后处理接口

(4)编辑器扩展 

编辑器扩展与方案类型扩展的方式类似，都是通过工厂服务实现扩展，这是因为在系统中可以存在一个方案类型的多个实例及一个编辑器类型的多个实例。工作台UI插件的Desktop组件是编辑器工厂服务的使用者，Desktop组件通过编辑器服务创建编辑器并打开文件进行编辑。与方案类型及方案工厂被实现在方案插件中不同的是编辑器及编辑器工厂服务并没有在单独的插 件中实现，而是被嵌入相关的方案插件中。这是因为CCFD工作台的编辑器都是为方案的控制文件提供定制服务的，因此，编辑器实现及编辑器工厂组件均被放置在了对应的方案插件中，当然放置在独立的插件中实现也是被系统支持的。

如表10所示，IFrame是编辑器接口定义，其中定义了编辑器关闭时的缺省动作，可见性操作，打开、重命名、保存文件等。编辑器可以在Desktop虚拟桌面中显示文件内容并进行编辑。

表10编辑器接口

表11中IFrameFactory定义了编辑器工厂服务，Desktop通过IFrameFactory创建编辑器，且Desktop支持的IFrameFactory可以被动态增加或删除。

表11编辑器工厂接口

本发明实施例提供的基于OSGi技术的CCFD系统利用对插件之间通过显式声明方式约束模块间的引用，降低了软件模块之间的耦合性。在扩展新功能时，对于扩展过程中需要重构的组件则需要保证其链式引用关系不被破坏；模块化机制的采用使得系统模块化方面存在天然的优势，对于系统的扩展只需掌握扩展功能相关的局部即可，且可以以非侵入式的完成功能的扩展，不需对已有系统进行修改。

在本发明中，任意一种方案类型被实现为一个方案插件，方案插件实现了与该方案类型相关的所有功能，方案插件被独立的部署在系统中。当需要从系统中删除方案类型时，只需要将与方案类型相关的插件文件从软件插件目录下删除即可；当向系统增加方案类型时，只需要按方案类型接口实现方案插件，将插件放置在软件插件目录下即可实现。通过以上描述步骤可见，新系统的扩展是一种非侵入式的灰盒扩展。

图6为本发明实施例提供的基于OSGi技术的CCFD工作台部署图。CCFD 工作台系统被实现为一组插件的集合，包括OSGi引擎插件和CCFD工作台应用插件。如图6所示，configuration目录存放软件的配置信息，jre目录放置了Java运行环境，plugins目录放置了软件的插件，ccfd.log目录存放软件运行日志，tools目录存放了基于OSGi技术的可扩展计算流体力学软件的求解器及相关工具。图6右下角详细展示了基于OSGi技术的可扩展计算流体力学软件plugins目录内容，其中以sccas.ccfd为前缀的插件为基于OSGi技术的可扩展计算流体力学软件的应用插件，实现了软件要求的功能。

CCFD软件基于OSGi原理，采用“微内核+插件”的体系结构。OSGi规范的核心是它提供了一个通用的、安全的和可扩展的Java框架。OSGi框架支持可动态部署和下载应用程序的Bundle，并且可以在未使用时删除。这个框架以一种动态的、可升级的方式在一个OSGi环境中管理Bundle的安装和更新。为到达这个目的，它细致的管理了Bundle和服务间的依赖关系。框架为Bundle开发人员提供了利用Java平台独立和动态代码加载需要的资源，使得能够更加容易地在小内存设备上开发服务且能够大规模部署。

图7为本发明实施例提供的系统各插件及其相互间依赖关系的示意图。如图7所示，显示了系统包括的所有插件及其相互依赖关系，其中CCFD_求解器插件为CCFD七个求解器插件集的总称，CCFD_MO为优化模块。插件以元数据的方式描述插件的标识、名称、版本号等基本信息。同时，元数据中也显式的描述了插件之间的依赖关系。工作台系统中插件的元数据信息被一致的记录在元数据文件META-INF/MANIFEST.MF中，此处已CCFD_EC求解器为例来介绍新应用插件的增加，CCFD_EC求解器元数据文件的描述如图8所示。

插件是工作台系统的一级模块化概念，而组件则是真正提供服务的功能单元。组件位于插件中，一个组件可以暴露出多个服务，同时也可依赖于多个服务。在CCFD工作台系统中，组件被实现为普通Java类，服务被实现为接口Interface、Java类，实现了某个接口则Java类代表的组件提供了Interface代表的服务，一个Java类可以实现多个Interface，所以一个组 件可以提供多个服务。CCFD_EC求解器插件提供的服务包括以下三个，分别为CCFD_EC求解器插件提供的解决方案组件(如图9所示)、CCFD_EC求解器插件提供的图形界面参数设置向导组件(如图10所示)和CCFD_EC求解器插件提供的前后处理组件(如图11所示)。

从图9、图10和图11可以看出，当系统需要增加新的功能时候，只需按照OSGi规范，开发相应的应用插件，并且在插件中实现向外提供服务的组件就可以完成系统的功能的添加(如图12所示)。

CCFD系统的设计，在软件扩展性本质研究的基础上，结合CCFD软件需求设计了一个“微内核+插件”的体系结构。设计内容主要包括：模块化框架，设计了软件的标准化模块机制，保证模块的独立性、模块间的低耦合性、模块生命周期的易管理性及依赖关系的明确性；面向服务组件模型，给出了软件中插件、组件、服务三要素的一体化模型；动态化框架，则为软件提供了运行时的扩展能力；可扩展框架，在模块化框架、面向服务组件模型和动态化框架的基础上设计了一个开放的非侵入式的动态化扩展机制。综上所述，本发明技术方案带来的有益效果如下：

第一，面向大型飞机气动设计，能够解决飞机研制过程中的实际问题。

CCFD软件及其所包含的各核心模块，在设计之初就直接面向大型飞机气动设计的需要，瞄准若干前沿设计领域。针对大型飞机气动设计中的多个问题，例如为了得到更高精度的模拟结果和更精细的流场模型，CCFD-EC求解器采用了高阶保单调差分、加权群速度控制、优化WENO等格式的高分辨率数值方法；为解决超大规模网格的生成需要海量内存的问题，采用了网格分区计算、分区自适应生成及最终装配的技术，有效地利用了高效能计算机上的分布式内存来满足内存需求瓶颈。

第二，具有丰富的解决方案，增强软件的实用价值。

如系统各层概述中所阐述，基于OSGi技术的可扩展计算流体力学软件目前共集成了CCFD-UG、CCFD-Hoam、CCFD-MB、CCFD-EC、CCFD-LB、CCFD-SEC、 CCFD-MGMB七个核心求解模块和一个优化设计模块CCFD-MO，用户可根据所求解数值问题的特点选择不同的求解模块，以满足不同的需求。

第三，用户友好的GUI，提高用户体验。

为了较好地契合飞机设计人员的工作习惯，基于OSGi技术的可扩展计算流体力学软件系统提供了批处理作业、双模式控制参数设置、计算过程监控、命令行控制台等功能插件，能够无缝衔接前/后处理模块，有效地减轻了工程设计人员的负担，从而推动大飞机设计研制的进程。

第四，支持大规模并行计算，充分利用高效能计算的优势

为了能够适应大规模并行计算，基于OSGi技术的可扩展计算流体力学软件系统各求解模块在并行编程模型、计算负载均衡、计算与通信重叠、高效率并行计算、多级并行实现方法与基于容量调节的告诉缓存命中率优化等方面开展了大量的研究，取得了丰硕的成果，为支持大规模并行计算奠定了坚实的基础。

显而易见，在不偏离本发明的真实精神和范围的前提下，在此描述的本发明可以有许多变化。因此，所有对于本领域技术人员来说显而易见的改变，都应包括在本权利要求书所涵盖的范围之内。本发明所要求保护的范围仅由所述的权利要求书进行限定。

Claims (13)

1.一种基于OSGi技术的CCFD系统，其特征在于，包括：插件引擎和系统应用插件，其中，所述插件引擎负责所述系统应用插件的安装、卸载及依赖关系验证；所述系统应用插件内部由组件实现，所述组件提供并使用服务；所述系统包括组件管理器，通过解析所述组件的配置文件发现组件发布的服务，并将组件提供的服务注入给申请服务的组件。

2.根据权利要求1所述的系统，其特征在于，该系统将OSGi框架作为所述插件引擎，所述OSGi框架中的DS服务作为系统的组件管理器，管理系统中组件的生命周期及其提供的服务。

3.根据权利要求1所述的系统，其特征在于，所述系统应用插件以元数据的方式描述插件的基本信息，同时，元数据中也显式的描述了插件之间的依赖关系。

4.根据权利要求1所述的系统，其特征在于，所述系统应用插件之间的依赖关系建立在粗粒度的源码包级别上。

5.根据权利要求1所述的系统，其特征在于，所述系统应用插件以JAR文件形式独立地发布，所述JAR文件形式包括元数据文件，所述插件引擎通过所述元数据文件判断所述系统应用插件的依赖关系是否满足。

6.根据权利要求1所述的系统，其特征在于，所述插件引擎为功能模块插件提供依赖，具体包括：插件部署到系统后，所述插件引擎通过解析插件元数据获取插件的依赖关系，并将功能模块插件安装到系统中。

7.根据权利要求1所述的系统，其特征在于，所述组件管理器对所述系统应用插件中的所有组件配置文件进行解析，将服务动态注入到申请服务的组件，获取到服务后，服务实例被扩展，实现系统的扩展。

8.根据权利要求1所述的系统，其特征在于，扩展以插件为扩展实体实现，具体包括：被扩展的功能模块由插件实现，插件内部由提供真实服务的组件组成，组件可以使用其他插件提供的服务。

9.根据权利要求1所述的系统，其特征在于，所述系统应用插件包括：

图形界面插件，用于为系统提供图形化支持；

方案管理器插件，用于提供系统方案类型维护、存在方案管理；

作业管理器插件，用于管理系统已存在作业；

前后处理管理器插件，用于管理系统支持的前后处理功能。

10.根据权利要求9所述的系统，其特征在于，所述系统应用插件还包括：

向导编辑器插件，用于为用户提供图形化编辑参数文件提供便利；

日志插件，用于为系统调试及运行监视提供一种重要方式，方便系统的开发和维护。

11.一种基于OSGi技术的CCFD系统，其特征在于，所述系统包括：

插件引擎，负责系统中插件的安装、卸载及依赖关系验证；

图形界面插件，用于为系统提供图形化支持；

方案管理器插件，用于提供系统方案类型维护、存在方案管理；

作业管理器插件，用于管理系统已存在作业；

前后处理管理器插件，用于管理系统支持的前后处理功能。

12.根据权利要求11所述的系统，其特征在于，所述插件内部由组件实现，组件提供并使用服务；所述系统包括组件管理器，通过解析组件的配置文件发现组件发布的服务，并将组件提供的服务注入给申请服务的组件。

13.根据权利要求11所述的系统，其特征在于，所述插件以元数据的方式描述插件的基本信息，同时，元数据中也显式的描述了插件之间的依赖关系。