CN102722368A

CN102722368A - 一种基于文档树和消息泵的插件式软件设计方法

Info

Publication number: CN102722368A
Application number: CN2012101589527A
Authority: CN
Inventors: 余佳; 张智慧; 张�浩; 王建忠; 张保乾; 齐敏; 冀建伟
Original assignee: China General Nuclear Power Corp; China Techenergy Co Ltd
Current assignee: China General Nuclear Power Corp; China Techenergy Co Ltd
Priority date: 2012-05-21
Filing date: 2012-05-21
Publication date: 2012-10-10
Anticipated expiration: 2032-05-21
Also published as: CN102722368B

Abstract

本发明公开一种基于文档树和消息泵的插件式软件设计方法，按功能将软件拆分成多个插件，一个插件对应着一个或多个功能模块，每个插件分为模型层、视图层和控制层，将所有插件中模型层里的数据和文档抽取出来构成一个树形结构的管理文档。本方案加快和简化了模块间通信的速度，提高了系统的扩展性和可维护性。在插件视图管理方面，采用框架容器统一管理视图，本方法使得新插件的文档数据只要派生于同一基类，那么就可以将此文档连接到文档树上，极易于软件功能扩展。

Description

一种基于文档树和消息泵的插件式软件设计方法

技术领域

本发明涉及计算机软件设计领域，具体涉及一种对计算机上软件复用的一种强化管理方法。

背景技术

软件的工业化使得软件复用已经从通用类库进化到了面向领域的应用框架。应用框架强调的是软件的设计重用性和系统的可扩展性，以缩短大型应用软件系统的开发周期，提高开发质量。面对这种发展趋势，呼之欲出的便是一种全新的、开放性的、高扩展性的架构体系，即插件式软件设计，按功能块的方式划分软件。

交互软件通常在软件架构设计上，采用MVC即Model（模型）-View（视图）-Controller（控制器）的分层方式，Event（事件）导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Model的数据或者属性，所有依赖Model的View都会自动更新。类似的，只要Controller改变了View，View会从依赖的Model中获取数据来刷新自己。结合插件式设计，可以将插件按照业务逻辑分为模型、视图和控制器。在此技术背景下，文档管理、模块间通信和视图管理就成为设计的重点和难点。

以现有技术中的SharpDevelop为例：SharpDevelop是一个用于制作C#或者VB.NET的项目而设计的一个编辑器，其自身是一个开源的使用C#语言实现的IDE(集成开发环境)，其设计思想被用户广泛的使用。在SharpDevelop软件的3.2.0.5777版本的开源代码中，文档数据管理、模块间通信和视图管理使用如下解决方法。

如图1所示，每类文档对应一个文档类，通过建立一个三级扁平化的文档树来管理各类文档对象。树的根节点是Solution，根节点有SolutionItem(及派生类)和SolutionFolder等孩子节点，其中SolutionItem(及派生类)为叶子节点，SolutionFolders(即为project文件夹)节点有Projectltem(及派生类)叶子节点，如图2所示的类关系图中，模块间通信是通过接口调用来处理和解决插件间模块的通信，通过事件(Event)的订阅来处理插件内部的模块间通信。文档视图管理是由统一的平台(Default Work bench)管理两种视图，两种视图分别是面板视图容器和文档视图容器。一个或者多个文档对应一个文档视图或者面板类，文档视图或者面板类都由实现了IViewContent接口的类对象来管理，如某个.cs文件视图由TextEditorDisplayBindingWrapper来管理和操作，在打开cs文件时，系统将新建一个TextEditorDisplayBindingWrapper对象，该对象由DefaultWorkbench的文档视图容器管理。

虽然SharpDevelop是一个极优秀的开源软件，但是在解决文档管理、模块间通信和视图管理难题上还有一点瑕疵，具体如下：

一、在文档管理上存在以下问题：

1、采用扁平化管理文档，固然有一些优点，但是对具体类的依赖太大，不容易抽象出统一的文档接口，可扩展性差；比如在上例中，某软件的根节点不是Solution而是其他的，那么就需要大量的改动软件；

2、没有将文档管理和文档数据(如名字、描述信息)分离，违背软件的单一职责原则(SRP)；

3、对于有层级关系的数据(如工程中有文件夹，文件夹中又有文件夹)，无法在数据结构中体现出来；

4、此扁平化管理不便于文件在加载时拆分和保存时合并；

5、树形结构局部遍历时效率较低。

二、在模块间通信方面存在如下问题：

插件间的模块通信，不是将消息分类而是直接通过接口调用，不满足软件的开放-封闭性原则(OCP)。

三、在文档视图管理方面存在如下问题：

1、视图分为两类，由统一的平台(DefaultWorkbench)管理，难以扩展面板和文档视图之外的特殊视图，不满足开放-封闭性原则(OCP)；

2、框架和文档的粘合在一起，不易于软件维护和扩展。

发明内容

在现有技术的基础上，本发明需要解决如下三个问题：

1、文档管理：由文档管理模块的主要数据，插件间数据管理即文档间数据管理，包括文档组织结构、生命和遍历等，在软件复用的工作方式下如何更好的管理文档是软件设计中必须解决的难题。

2、模块间通信：在通常的基于插件式设计、MVC架构的软件中，需要通信的有视图与模型层、模型层之间及模型层与控制层之间。一个优秀的软件，应满足软件遵循开放——封闭原则(OCP)，因此，在建立一种方案来完成插件间的数据通信时，通信双方应不依赖具体类(或者对象)。

3、文档视图管理：交互软件中有文档视图，包括单文档多视图和多文档多视图。在功能上，视图将文档数据显示出来，通过操作视图来完成文档数据的更新，因此，在基于上文描述的技术背景中，软件设计者应提供一套管理视图的技术方案，包括视图的组织结构、生命和遍历等。

针对上述问题本方案提供一种利用各插件中模型层的数据组成文档树，以树形结构来管理文档的内容，来克服上述问题，具体方案如下：一种基于文档树和消息泵的插件式软件设计方法，按功能将软件拆分成多个插件和内核，一个插件对应着一个或多个功能模块，每个插件分为模型层、视图层和控制层，其特征在于，将所有插件中模型层里的数据和文档抽取出来构成一个树形结构的管理文档，其中：

步骤1、将构成文档树根节点的文档所对应的插件作为主插件；

步骤2、由挂接在根节点文档下的文档所对应的插件为非主插件，并形成根节点的子节点，其中子节点包括受根节点管理的子节点及受其自身管理的下一级子节点。

为方便挂接子节点：所述管理文档建立一套主插件和非主插件的挂接标准，此文档树内的所有文档都遵循此挂接标准。

为扩展方便：所述子节点是根据管理关系而挂接在受其管理的节点下，此时上一级的管理节点成为其父节点。

为方便双方消息传递：两个相互连接的父节点和子节点之间通过相互注册事件建立双向链接。

为提高管理效效率：在加载文件时，管理文档对有实体文件的文档直接解析并根据文件信息创建文档，对没有独立实体文件的文档，其信息在对应XML格式文件的一个节点上，在保存模型数据时，对有实体文件的文档，直接保存为XML格式的文件，对没有实体文件的文档，将此文件实例成一个XML格式的节点，由其父节点接管此XML格式的节点并保存。为使消息传递到每个节点：在文档树中包括两个由消息链组成的消息泵，一个消息泵为自上而下，此时由发生事件改变的节点作为消息泵的消息源，接到事件消息后，由此节点开始一直将事件消息向下发送到所有的子节点；另一个消息泵为自下而上，此时管理文档的某个子节点接到事件消息后，即向其父节点发送该事件消息，直到发送到根节点为止，根节点对此事件消息进行处理后，再将此事件消息发送给挂接在其下的每个子节点。

为方便各层之间管理数据：根据软件中每类文档所对应的框架，相应的文档树中每个文档也都对应此框架，框架用于文档管理和视图管理，框架对象在组件加载时由组件创建，框架创建视图对象和回收视图对象。

本发明通过抽象类Document（即每个文档的基类）和DocumentFolder建立文档树形的管理文档，在文档树内按功能模块而不是实体文件来划分文档类，简化保存和加载插件时对文件的拆分和合并，在建立文档树时通过父子节点间相互订阅事件的方式来建立消息链，此方式隔离了模块间的直接通信，而是将消息进行分类，消息的发送方和接收方仅知道消息类别而不用知道消息双方的具体类。加快和简化了模块间通信的速度，提高了系统的扩展性和可维护性。在插件视图管理方面，采用框架容器统一管理视图，插件在被加载时再注册框架对象和文档类型，在插件内部形成框架视图和文档一一对应的关系。

本方法使得新插件的文档数据只要派生于同一基类，那么就可以将此文档连接到文档树上，极易于软件功能扩展。

建立统一的插件视图管理容器，又有可扩充的插件框架，极易于开发人员对插件视图的功能扩展，满足开放-封闭性原则(OCP)，而且框架和文档的分离，也便于软件维护和扩展。

将文档管理和插件数据(如名字、描述信息)分离，满足了软件的单一职责原则(SRP)，便于实体文件在加载时拆分及拆分后保存时的合并，按功能模块划分文件树，使得树形结构遍历简便。

附图说明

图1现有技术中三级扁平化文档管理结构示意图。

图2现有技术中文档管理的类关系图。

图3本发明的文档树结构示意图。

图4图3文档树结构下的实例。

图5消息链自上而下传送示意图。

图6消息链自下而上传送示意图。

图7文档视图管理结构示意图。

具体实施方式

根据本发明公开的方法建立的是一个交互式软件，采用内核-插件式开发技术，基于MVC(模型、视图和控制)的软件体系结构，创新的运用了文档树、消息泵和框架管理等技术，解决了文档管理、模块间通信和视图管理的设计难题。

本方案将软件按照功能模块拆分成多个插件，每个插件划分为模型层、视图层、控制层，在通常情况下，一个插件包括一个或者多个子功能模块，将各个子功能模块的数据管理部分抽取出来，作为该插件的管理文档。

本发明以文档树的方式处理管理文档中的内容，将软件中各个插件的子功能模块的数据管理部分抽取出来，作为该功能模块被管理文档管理的依据，管理文档采用XML文件格式保存每个插件的数据，其中管理文档的具体结构如下：首先按功能将软件拆分成多个插件和内核，一个插件对应着一个或多个功能模块，每个插件分为模型层、视图层和控制层，将所有插件中模型层里的数据和文档抽取出来构成一个管理文档，此管理文档为树形结构的文档树，其中将构成文档树根节点的文档所对应的插件作为主插件，由挂接在根节点文档下的文档所对应的插件为非主插件，并形成根节点的子节点，其中子节点包括受根节点管理的子节点及受其自身管理的下一级子节点。

如图3、4所示，建立文档树结构，其中主插件的文档为树的根节点，非主插件通过向管理文档中的管理它的对象（相当于父节点）注册，将文档挂接到管理对象文档上形成其子节点，如project由solution管理，那么project文档挂接到solution文档上，此管理对象成为该文档的父节点，父节点和子节点之间通过相互注册事件的方式，在文档树的对象间建立“双向消息链”，按此方式组织和管理各个插件中的数据模型。

本方案利用文档树来管理文档，这棵树可以沿叶子节点方向无限扩展，树的根节点可以由开发人员自己定义(只要派生于同一基类即可)，不仅如此，本发明将模型层中的数据抽象出来，作为树的叶子节点，由文档values链表管理，以免和模型层中的文档管理混淆。

结合图3的文档树，下面结合图4给出一个实例，假设管理文档的根节点为Solution，Solution管理着多个Project，每个Project又管理多个Folder和cs文件，而Folder又管理多个cs文件。图4中省略了Values、DocumentFolders和Documents。

如图4所示，本方案将文档的基类设定为Document类，其中SolutionDoc、ProjectDoc和TextEditorDoc类均派生于Document类，Solution、Project和TextEditor均实现了IModel接口。本方案采用面向对象方法，将软件中所有插件的文档抽象于一个文档基类(Document)，基类(Document)提供添加子文档和文件夹、删除子文档和文件夹等的方法，在子文档和文件夹被操作的同时，父子文档(或者文件夹)之间将自动注册事件，建立起“双向消息链”。文件拆分和合并方面，本方案并不是所有的文档对都维护一个独立的实体文件，那么对于没有实体文件的对象，文档将维护一个XML节点，在保存模型层中的数据时，文档向父节点提供一个XML节点对象(XMLNode)，在加载模型层的数据时，父节点将为它提供一个XML节点对象。具体文档树的建立方式如下：由于采用了树形结构

此时约定节点关键字Folder为Folder文档(管理文件夹数据的文档)，此实体文件对应的文档是project文件，那么project文档在加载数据时，将创建Folder文档，并将xml中Folder节点的子节点信息(如elements)和属性信息（如id、extensions）赋值到Folder文档中。

本方案中文件的拆分和合并极其简便。对于派生于Document类而没有实体文件的文档，它在加载和保存时维护一个XML节点对象(XMLNode)，在保存时，将它的信息生成一个XML对象，并提交各父节点，在加载数据时，由父节点给它赋值一个XML节点对象(XMLNode)，此节点将解析XML节点对象(XMLNode)。

本方案通过消息泵处理模型层间通信。基于MVC的技术中，不管是通过视图层或者控制层来改变模型层，还是模型层自身发生改变，最终都是模型层发生变更，再由模型层通知视图层，刷新视图，文档是模型层的主要载体，因此，只要解决了文档树间的通信，那么模型层间通信就迎刃而解。文档树有两个消息泵，即自上到下和自下到上。两种方式都由消息链组成，消息链是建立在文档树的基础上，在往某节点对象(Document或者DocumentFolder)添加子节点时，两节点将相互订阅事件(Event)，形成双向消息链。

如图5所示，自上到下，文档树的根节点是泵的消息源，事件触发是泵的动力，一直沿子节点方向广播发送。不妨以“保存事件”为例说明。文档树根节点将捕获到的“保存事件”发给所有的子节点，子节点收到事件消息后，不仅保存自己数据，还将消息发送给它的子节点，此消息一直到子节点的终点才停止发送。

其中Doc、Docs、Folder和Folders分别为Document、Documents、DocumentFolder和DocumentFolders的缩写。

如图6所示，自下到上，文档树的某节点(不一定是叶子节点)是泵的消息源，事件触发是泵的动力，一直沿父节点方向发送。不妨以“属性修改事件”为例说明。如某个对象模型捕获到“属性修改事件”，那么它将向父节点发送该消息，父节点再向自己的父节点发送该消息，最终文档树的根节点将接收到此消息，根节点处理完消息后，再将此事件消息发送给每个插件的框架对象，框架对象将此消息发送给各自的视图对象，视图对象根据需要处理消息。

如图7所示，本方案的文档视图管理是，每个文档都分别对应一个框架，由框架管理文档和视图，其中框架对象在插件被加载时即创建，在打开文档时，使用者将找到文档对应的框架，由框架创建视图对象，显示文档内容，在关闭文档时，也由框架回收此视图对象。

在插件被加载时，插件为每种视图创建一个框架对象，并将框架对象与文档类型注册到文档视图管理容器中。在用户点击打开某个实体文件C时，那么点击事件将从文档视图容器中查找文档，C对应的框架C，再由框架C去创建和管理文档C对应的视图C，并显示视图C。文档管理器适合于各类文档视图，易于扩展。

Claims

1.一种基于文档树和消息泵的插件式软件设计方法，按功能将软件拆分成多个插件和内核，一个插件对应着一个或多个功能模块，每个插件分为模型层、视图层和控制层，其特征在于，将所有插件中模型层里的数据和文档抽取出来构成一个管理文档，此管理文档为树形结构的文档树，其中：

2.如权利要求1所述的一种基于文档树和消息泵的插件式软件设计方法，其特征在于，所述管理文档建立一套主插件和非主插件的挂接标准，此文档树内的所有文档都遵循此挂接标准。

3.如权利要求1所述的一种基于文档树和消息泵的插件式软件设计方法，其特征在于，所述子节点是根据管理关系而挂接在受其管理的节点下，此时上一级的管理节点成为其父节点。

4.如权利要求3所述的一种基于文档树和消息泵的插件式软件设计方法，其特征在于，两个相互连接的父节点和子节点之间通过相互注册事件建立双向链接。

5.如权利要求1所述的一种基于文档树和消息泵的插件式软件设计方法，其特征在于，在加载文件时，管理文档对有实体文件的文档直接解析并根据文件信息创建文档，对没有独立实体文件的文档，其信息在对应XML格式文件的一个节点上，在保存模型数据时，对有实体文件的文档，直接保存为XML格式的文件，对没有实体文件的文档，将此文件实例成一个XML格式的节点，由其父节点接管此XML格式的节点并保存。

6.如权利要求1所述的一种基于文档树和消息泵的插件式软件设计方法，其特征在于，在文档树中包括两个由消息链组成的消息泵，一个消息泵为自上而下，此时由发生事件改变的节点作为消息泵的消息源，接到事件消息后，由此节点开始一直将事件消息向下发送到所有的子节点；另一个消息泵为自下而上，此时文档树的某个子节点接到事件消息后，即向其父节点发送该事件消息，直到发送到根节点为止，根节点对此事件消息进行处理后，再将此事件消息发送给挂接在其下的每个子节点。

7.如权利要求1所述的一种基于文档树和消息泵的插件式软件设计方法，其特征在于，根据软件中每类文档所对应的框架，相应的文档树中每个文档也都对应此框架，框架用于文档管理和视图管理，框架对象在组件加载时由组件创建，框架创建视图对象和回收视图对象。