CN101051267A - 一种可扩展文档模型及管理文档模型的方法 - Google Patents

Abstract

本发明涉及电信领域集成开发环境文档编辑器开发过程中一种可扩展文档模型及管理文档模型的方法。所述可扩展文档模型中包括具有通知机制的文档模型，还包括：扩展部件安装模块，用于根据扩展需求在可扩展文档模型中安装扩展部件；扩展部件卸载模块，用于卸载所述可扩展文档模型中的扩展部件；模型修改通知中转装置，用于监听并收集所述文档模型各个节点的改变事件，并将所述改变事件转发到各相应的扩展部件中。本发明实现了对具有通知机制的文档模型进行扩展的模式化，通过使用标识实现了对扩展部件进行索引管理，使扩展管理和引用更便捷。同时本发明有效地解决了模型修改后，扩展部件数据同步的问题。

Description

一种可扩展文档模型及管理文档模型的方法

技术领域

本发明涉及通讯技术领域，尤其涉及集成开发环境中，开发文档编辑器过程中使用到的一种可扩展文档模型及管理文档模型的方法。

背景技术

在IDE(集成开发环境)的文档编辑器开发过程中，需要建立一个保存文档数据结构的文档模型。文档模型一般只具有简单的文档数据存取能力，为了便于对模型进行处理，需要缓存一些从模型中提取出的数据、扩展一些模型联动的操作或者一些附加的相关数据等等。

例如：当编辑一个UML(统一建模语言)的类图时，当前的模型是参考UML规范建立基本模型，只是用树的节点独立地保存类和类之间的关系。如果增加一个通过名称快速某个类的功能，则需要在模型上扩展一个类名称到类的位置的映射表；如果需要快速展示类的继承树，则需要扩展一个类到其子类的映射表；如果要实现将一个类删除时同时删除其子类的功能，则可以扩展一种联动的模型操作；如果要将类生成C++代码，并且能配置哪些类生成到哪个文件的信息，则需要扩展一些额外的配置数据等等。

为了便于文档模型改变时对文档视图进行更新，文档模型需要具有修改通知的机制。原始的模型修改事件一般都分别在每个模型上的节点上发出。模型上某一节点发生修改时，扩展部件需要根据模型修改的事件，进行一些数据同步操作，或是触发其它一些处理过程。比如上面例子中，如果将两个类之间增加一个继承关系，类到其子类的映射表则需要更新。

同时，当模型修改时，可能会新增、删除或更换了一些模型节点，这些扩展装置可能需要关注新的节点上的修改事件。这是这一类具有通知机制模型的扩展部件所共有的特性。

为了满足当前软件开发的需要，需要对所述扩展部件进行统一的管理，实现扩展部件与模型信息的实时同步。

发明内容

本发明的目的在于提供一种可扩展文档模型及管理文档模型的方法。

本发明的目的是通过以下技术方案实现的：

一种可扩展文档模型，包括具有通知机制的文档模型，还包括：

扩展部件安装模块，用于根据扩展需求在可扩展文档模型中安装扩展部件；

扩展部件卸载模块，用于卸载所述可扩展文档模型中的扩展部件；

模型修改通知中转装置，用于监听并收集所述文档模型各个节点的改变事件，并将所述改变事件转发到各相应的扩展部件中。

所述扩展部件安装模块所安装的扩展部件具有唯一的标识，利用该标识可以索引到唯一的扩展部件。

所述模型修改通知中转装置中设置有监听器列表，用于保存一个基本模型中所安装的所有扩展部件信息。

所述模型修改通知中转装置中设置有扩展部件索引表，用于对扩展部件进行索引管理。

一种对具有通知机制的文档模型进行管理的方法，由可扩展文档模型管理具有通知机制的文档模型，按照所述文档模型的扩展需求对相应的扩展部件执行相关操作。

所述对扩展部件执行的操作包括：安装和卸载。

所述安装扩展部件的操作进一步包括：

在安装有依赖关系的扩展部件时，首先安装被依赖的扩展部件。

所述扩展部件具有唯一标识，利用该标识可以索引到唯一的扩展部件。

在文档模型节点发生改变时，可扩展文档模型将修改信息转发到所有的扩展部件。

所述方法进一步包括：

扩展部件根据接收的模型节点修改通知进行数据同步操作。

所述同步的方法包括：实时同步和延迟同步。

由上述本发明提供的技术方案可以看出，本发明通过提供可扩展文档模型，对具有通知机制的基本文档模型进行包装，有利于基本文档模型的稳定和独立，便于对模型动态增加扩展功能，实现了对功能扩展模式化。通过使用标识实现了对扩展部件进行索引管理，使扩展引用更便捷。同时本发明通过对模型节点修改通知的转发机制，有效地解决了模型修改后，扩展部件数据同步的问题。

附图说明

图1为本发明所述可扩展文档模型一种实施例结构示意图；

图2为本发明所述方法安装扩展部件一种实施例流程；

图3为本发明所述方法模型修改通知中转装置转发修改通知一种实施例流程；

图4为本发明所述方法实时同步一种实施例操作流程；

图5为本发明所述方法延迟同步接收修改通知一种实施例操作流程；

图6为本发明所述方法延迟同步接受数据请求处理一种实施例操作流程；

图7为本发明所述方法卸载扩展部件一种实施例操作流程。

具体实施方式

本发明的核心思想是提供了一种可扩展文档模型及管理文档模型的方法，可以对具有通知机制的文档模型进行动态扩展，使符合一定接口的扩展部件可以任意安装、卸载，并在模型修改后以统一的模式处理该模型所有扩展部件的同步。

本发明提供了一种可扩展文档模型，所述装置一种实施例结构框图如图1所示，本发明是在文档模型的基础上包装的一个可扩展文档模型。

所述可扩展文档模型包括一个基本的文档模型、模型修改通知中转装置、多个扩展部件、扩展部件安装模块、及扩展部件卸载模块。

所述基本的文档模型为具有通知机制的文档模型，且该文档模型所有节点上都能发出修改属性、增加子节点、删除子节点等修改事件的通知如图1中的粗箭头指示，基本文档模型上报模型节点修改通知，所述通知信息中包括有属性修改前后的值、新增的节点、删除的节点等内容。

该文档模型对于可扩展文档模型是透明的，即用户可以通过可扩展文档模型获得一个基本的文档模型的所有信息。例如，可扩展文档模型使用一个Java类ExtensibleModel实现，则ExtensibleModel类存在一个getRawModel()方法来获取被包装的具有通知机制的文档模型。

所述模型修改通知中转装置，用于监听所有节点的修改事件，并将其转发到所有安装的扩展部件上，即监听器列表中所有的监听器上。也就是具有通知机制的文档模型的任何节点发生修改时，都会向中转装置发出模型修改通知。如图1中细箭头表示所述模型修改通知中转装置上报整个模型修改通知给所有扩展部件。所述模型修改通知中转装置中设置有监听器列表，该列表用于保存一个基本模型中所安装的所有扩展部件。每一扩展部件包括一个唯一的标识。根据所述标识对扩展部件进行索引管理，所述索引保存在扩展部件索引表中。

所述可扩展文档模型中设置的扩展部件安装模块，用于在文档模型有扩展需求时，在可扩展文档模型中安装扩展部件。在安装一个扩展部件时，将扩展部件做为一个模型修改的监听器加入到模型修改通知中转装置的监听器列表中，此后模型发生修改时，由模型修改通知中转装置将修改通知转发到新安装的扩展部件上。

所安装的扩展部件具有公开的唯一的标识，供可扩展文档模型进行索引管理，实现按照标识获取或卸载相应的扩展部件。

所述可扩展文档模型中设置的扩展部件卸载模块用于卸载不需要的扩展部件。在卸载一个扩展部件时，将此扩展部件从模型修改通知中转装置的监听器列表中将该扩展部件，也就是一个监听器，从监听器列表中删除。

本发明提供了一种对具有通知机制的文档模型进行管理的方法，所述扩展操作包括：安装扩展部件和卸载扩展部件操作；下面以一个文档模型从安装扩展部件到卸载所述扩展部件的过程为例对本发明进行说明。

以编辑一个UML的类图为例，如果增加一个通过名称快速某个类的功能，只需要在可扩展模型上安装类名称到类的位置的映射表扩展部件；如果需要快速展示类的继承树，则只需要在可扩展模型上安装类到其子类的映射表扩展部件；如果要实现将一个类删除时同时删除其子类的功能，则只需要在可扩展模型上安装删除一个类及其子类操作的扩展部件；如果要将类生成C++代码，并且能配置哪些类生成到哪个文件的信息，则只需要在可扩展模型上安装类对应的C++文件配置信息的扩展部件。

当一个具有通知机制的文档模型需要扩展时，由扩展部件安装模块安装相应的扩展部件，一种安装扩展部件的实施例如图2所示，包括如下步骤：

首先，判断与要安装的扩展部件存在依赖关系的扩展部件是否存在；

扩展部件之间如果存在依赖关系，则在安装所述扩展部件时，如果某个依赖的扩展部件不存在，则该扩展部件初始化失败，也就是这个扩展部件将无法安装到可扩展的文档模型上。这样，就要求用户先安装被依赖的扩展部件，才能安装依赖的扩展部件。

例如编辑UML类图，“删除一个类及其子类操作的扩展部件”依赖于“类到其子类的映射表扩展部件”，这就必须后者在前者安装之前才能安装。

其次，处理扩展部件初始化过程；

如果初始化成功，则将其置于扩展容器中进行统一管理，安装成功。否则，可扩展的文档模型将不管理这个扩展部件，安装失败。如果安装某个部件时发现有相同标识的部件己安装，则待安装的扩展部件会安装失败。

如果新增其它功能时，还需要增加一些扩展，可以同样安装上来。再次，将扩展部件作为监听器加入模型修改通知中转装置的监听器列表中。最后，对扩展部件进行按标识索引，加入可扩展文档模型的扩展部件索引表中。则安装扩展部件的过程完成。

模型修改通知中转装置监听所有节点的修改事件，并转发到所有安装的扩展部件上的过程如下所述：

当文档模型节点新增、删除或更换时，模型修改通知中转装置增加对新增节点的监听，取消对删除节点的监听；

当基本模型上任何节点上发生新增、修改或更换的事件时，模型修改通知中转装置通过节点的事件通知中的新增节点信息，增加对新增节点的事件的监听；通过事件通知中的删除节点信息，取消对删除节点的跟踪；在更换节点时，通知中新增和删除节点都存在，一般先处理删除节点，后处理新增节点。

增加或取消对一个节点事件的监听时，如果该节点存在子节点，则递归地处理所有其中的子节点。新增、删除、更换子节点的事件，模型修改中转装置同样会将其同步到各个扩展部件。

所述修改通知的转发过程一种实施例如图3所示，首先，模型修改通知中转装置判断扩展部件列表是否为空，即，监听器列表中是否存在扩展部件；若为空，则结束通知操作；若不为空，则取得列表中的第一个扩展部件，转发修改通知给所述扩展部件；再判断所述扩展部件是否为列表中最后一项，若是，则结束操作；若不是，则取得列表中下一个扩展部件。重复所述操作，直到将所述通知转发到所有安装的扩展部件中。

所述修改消息的同步的方法包括：实时同步和延迟同步。

所述实时同步，就是在模型修改通知中转装置接收到一扩展部件关注的任何模型事件通知时，都根据事件通知的信息进行增量式同步处理。这种同步方式适合关注事件发生不频繁、便于增量式同步处理、应用场景广泛或是需要实时触发的扩展部件。实时同步会使扩展部件的效率提高，但是模型修改的效率则有所下降；

例如“类名称到类的位置的映射表扩展部件”其应用场景比较广泛，并且易于增量式同步，则可以采用实时同步方式。其实时同步过程的一种实施例如图4所示，扩展部件首先根据本身的功能及存储的数据判断所接收到的通知消息是否为本扩展部件关注的修改，如果不是，则不进行修改；如果是，则根据修改消息通知更新当前的数据。

所述的延迟同步，则是在模型修改通知中转装置接收到模型事件通知时，不立即实施同步，而只是将扩展部件的状态设置为不同步，待该部件的某个功能方法被引用后才进行重建式的同步操作。这种同步方式适合关注事件发生很频繁、不便于增量同步处理、应用场景不是很广泛、不需要实时触发的扩展部件。延迟同步模型修改的效率较高，但是会使模型修改后的第一次引用扩展功能的效率有所下降。

例如：“类到其子类的映射表扩展部件”只在用户需要浏览继承树时才会用到，使用场景不很广泛，可以采用延迟同步方式。

其延迟同步过程的一种实施例如图5及图6所示，扩展部件接收到通知消息后首先根据本身的功能及存储的数据判断是否为本扩展部件关注的修改，如果不是，则不进行修改；如果是，则当前仅设置脏标志为真。如图6中，扩展部件若接收到数据请求时，则需要更新/重建数据。首先判断所述脏标志是否为真，当脏标志为真时，执行更新/重建操作，之后获取待请求的数据，返回所述待请求数据。

所述两种同步方式也可以混合使用，例如“类到其子类的映射表扩展部件”可以在用户打开继承树视图时设置为实时同步，用户关闭该视图后设置为延迟同步。

最后，当一个文档模型中存在不需要的扩展部件时，由扩展部件卸载模块卸载所述扩展部件。所述卸载扩展部件操作一种实施例流程如图7所示，首先，判断待删除的扩展部件是否存在依赖的扩展部件，如果存在则不能卸载，即卸载失败；如果不存在与其具有依赖关系的扩展部件，则从可扩展文档模型扩展部件索引表中按其标识删除扩展部件。如果所述索引表中不存在此标识的扩展部件，则卸载失败。最后，从模型修改通知中转装置的监听器列表中删除此扩展部件，执行扩展部件的终结操作，卸载扩展部件的操作成功。

综上所述，本发明实现了对具有通知机制的文档模型进行动态扩展及管理，增强了模型的扩展功能，并有效实行了扩展部件的集中管理。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (11)

1、一种可扩展文档模型，包括具有通知机制的文档模型，其特征在于，还包括：

扩展部件安装模块，用于根据扩展需求在可扩展文档模型中安装扩展部件；

扩展部件卸载模块，用于卸载所述可扩展文档模型中的扩展部件；

模型修改通知中转装置，用于监听并收集所述文档模型各个节点的改变事件，并将所述改变事件转发到各相应的扩展部件中。

2、如权利要求1所述的一种可扩展文档模型，其特征在于，所述扩展部件安装模块所安装的扩展部件具有唯一的标识，利用该标识可以索引到唯一的扩展部件。

3、如权利要求1所述的一种可扩展文档模型，其特征在于，所述模型修改通知中转装置中设置有监听器列表，用于保存一个基本模型中所安装的所有扩展部件信息。

4、如权利要求1所述的一种可扩展文档模型，其特征在于，所述模型修改通知中转装置中设置有扩展部件索引表，用于对扩展部件进行索引管理。

5、一种对具有通知机制的文档模型进行管理的方法，其特征在于，由可扩展文档模型管理具有通知机制的文档模型，按照所述文档模型的扩展需求对相应的扩展部件执行相关操作。

6、如权利要求5所述的一种对具有通知机制的文档模型进行扩展的方法，其特征在于，所述对扩展部件执行的操作包括：安装和卸载。

7、如权利要求6所述的一种对具有通知机制的文档模型进行扩展的方法，其特征在于，所述安装扩展部件的操作进一步包括：

在安装有依赖关系的扩展部件时，首先安装被依赖的扩展部件。

8、如权利要求6所述的一种对具有通知机制的文档模型进行扩展的方法，其特征在于，所述扩展部件具有唯一标识，利用该标识可以索引到唯一的扩展部件。

9、如权利要求8所述的一种对具有通知机制的文档模型进行扩展的方法，其特征在于，在文档模型节点发生改变时，可扩展文档模型将修改信息转发到所有的扩展部件。

10、如权利要求9所述的一种对具有通知机制的文档模型进行扩展的方法，其特征在于，所述方法进一步包括：

扩展部件根据接收的模型节点修改通知进行数据同步操作。

11、如权利要求10所述的一种对具有通知机制的文档模型进行扩展的方法，其特征在于，所述同步的方法包括：实时同步和延迟同步。

Images