CN103186374B - 一种软件系统功能划分及组合的方法 - Google Patents

Abstract

本发明是一种软件系统功能划分及组合的方法，该软件系统具有一配置且具有至少一功能，该功能用以完成软件系统的至少一需求。该软件系统功能划分及组合的方法包括以下步骤：将该功能定义为至少一功能点；该配置记录每一功能点；根据所述的至少一需求，将该功能点组合成至少一功能包；以及该配置记录每一功能包。本发明不仅通过功能包划分及相互扩展，使系统功能的层次结构的复杂度减小，而且通过配置的方法以增加或移除公用功能包，使功能包具有高度的灵活性。此外，采用解释器模式，使功能点与系统之间的耦合更加松散，功能点更易于管理。

Description

一种软件系统功能划分及组合的方法

技术领域

本发明涉及软件系统领域，尤其涉及一种企业资源规划系统中软件系统功能划分及组合的方法。

背景技术

软件产品的开发目标是满足需求，需求又分为功能性需求和非功能性需求。在软件设计时，通过建模的方式将抽象的功能性需求转变为实际的功能模型并进一步加以实现。

对功能性需求建模的过程实际就是一种结构化功能网络的过程。功能模型需要具有充分的描述性，可以说明某个功能是如何满足需求的，某个功能是如何在系统中应用和工作的，以及各个功能之间是如何交互的。功能模型是否准确、可扩展，都将影响最终的软件质量。

在一个软件系统中通常会有许多公用功能，面向对象的设计方法通过封装、继承和多态来建立对象间的层次结构，面向组件的设计方式和面向服务的设计方式通常定义接口作为公用行为的契约。这三种建模的方式是需要通过接口、继承等方式将对象或是组件耦合在一起，以约定或定义公用功能，使得系统复杂度高，可扩展性差。

发明内容

本发明的目的在于解决上述的问题，提供一种软件系统功能划分及组合的方法。该方法不仅通过功能包的类别划分及相互扩展，使系统功能的层次结构的复杂度减小，而且通过配置的方法在功能包中增加或移除公用功能包以及增加、移除或改变功能点，使功能包具有高度的灵活性。此外，采用解释器模式，使功能点与系统之间的耦合更加松散，功能点更易于管理。

为实现上述的目的，本发明采用下述技术方案：

一种软件系统功能划分及组合的方法，所述的软件系统具有一配置且具有至少一功能，所述的功能用以完成软件系统的至少一需求，包括以下步骤：

(a)将所述的功能定义为至少一功能点(functionpoint)；

(b)所述的配置记录每一功能点；

(c)根据所述至少一需求，将所述的功能点组合成至少一功能包(functionpackage)；以及

(d)所述的配置记录每一功能包。

进一步，所述的功能包选自于一公用功能包和一独立功能包中任意一种。

进一步，所述的功能点为公用功能点和独立功能点中任意一种。

进一步，所述的公用功能包是由至少一公用的功能点所组成。进一步，所述的独立功能包是由独立功能点和公用功能包所组成。进一步，每一所述的功能点具有一类型。

进一步，在每一所述的功能包中允许删除或新增或修改一功能点。

进一步，允许由一功能包继承至另一功能包。

进一步，所述的配置是一可扩展标记语言文件(XML)。

进一步，所述的配置是可集成于所述软件系统的程序集动态链接库（DynamicallyLinkedLibrary，简称DLL）中。

进一步，所述的软件系统是一企业资源规划系统（ERP）。

本发明的优点在于：

(1)功能包的类别划分与互相扩展（功能包承载功能包）构成的系统功能的层次结构，与传统的通过代码扩展方式相比，减少了系统的复杂度；

(2)高度的灵活性，在各个独立功能包中可以将公用功能包中的功能与特有功能点进行组合，还可以通过配置的方式以移除或增加公用功能包中的功能点；

(3)可扩展性强，采用组合（功能包承载功能包）而非单根继承的方式来组织和重用业务功能，可以实现多根继承的效果；

(4)采用解释器模式，使得功能点与系统之间的耦合更加松散，使功能点更易于管理。此外，功能点的加载逻辑被包装在解释器中，使得新增功能点类型更容易实现，新增一个功能点类型对原有系统基本没有影响，功能点与系统的耦合关系被包装在解释器的应用逻辑中。

附图说明

图1是本发明所述软件系统的结构示意图；

图2是功能包定义设置的示意图；

图3是功能包变更或扩展的示意图；

图4是功能包和功能点相关的各元件的运作过程示意图；

图5是本发明所述软件系统功能划分及组合的方法的具体实施步骤流程图。

具体实施方式

下面结合附图对本发明软件系统功能划分及组合的方法的具体实施方式做详细说明。

图1是本发明所述软件系统的结构示意图,主要包括配置层M10、功能层M20和框架层M30。所述配置层M10还包括配置M11和配置系统M12。所述功能层M20包括至少一功能包M22和多个解释器M23，其中所述至少一功能包M22还包括多个功能点M21用于对应所述多个解释器M23。所述框架层M30为底层框架层,所述底层框架层包括各型底层框架M31，例如实体框架、服务框架和其他框架等。于优选实施例中，本发明的软件系统功能划分及组合的方法是运行但不限定在视窗Windows操作系统下，且本发明的软件系统是一种企业资源规划(ERP)系统。于其它实施例中，本发明的软件系统功能划分及组合的方法可以适用于其它类型的操作系统及开发环境中。

图1的多个功能点M21用于分别实现软件系统中具有不同特点或不同复用程度的各类型功能，以满足软件系统开发的各种需求。由于功能种类不同，特性也不同，功能的应用方式和复用程度也不尽相同，通过如图1的其中一个功能点M21或多个功能点M21即可实现每一个功能，换句话说，每一功能点M21就是一功能的定义，且上述多个功能点M21为公用功能点和独立功能点的任意一种。

图1的功能包M22是用于组合上述多个功能点M21，作为组织功能的一个容器，也就是说功能包M22划分的最小粒度是功能点M21。虽然图1仅绘示了一个功能包M22，然而在应用上，可依软件系统的实际需要，设置多个功能包M22(如图2)，功能包M22还分为公用功能包和独立功能包，其中公用功能包可以由至少一公用功能点如其中一上述功能点M21组成，包含了软件系统中一些公用功能的集合，所述公用功能包的复用级别较高，可以进行扩展，以提高软件系统的可维护性和可扩展性。独立功能包可以由独立功能点如另一上述功能点M21和公用功能包组成，用于满足一个独立的完整需求所定义的功能集合，每一业务所特有的独立功能包是不会被扩展的。公用功能包和独立功能包两者仅在逻辑上有所区分。例如在单据处理的业务中，公用功能包可以包括保存、删除和检查等功能，但这些功能本身在定义之后与单据处理业务无直接关系，但可以通过创建一独立功能包以实现单据处理业务的需求。该独立功能包复用了该公用功能包已定义好的功能，并按需求再增加单据处理的特别功能，以实现单据处理业务的功能需求。以图2为例，进一步具体说明图1的功能包M22的定义设置过程如下：图2中第一功能包和第二功能包为公用功能包，第三功能包为独立功能包。第一功能包（公用(Common)功能包）的基础包（BaseItems）中无复用功能包节点，而在代表功能点集合项（Items）的节点下，定义了各个具体的功能点节点，其中有创建（Create）、编辑（Edit）、删除（Delete）、保存（Save）、读取（Read）、查询（Query）、验证（Validate）和版本管理（VersionManagement）功能点。第二功能包（基本数据（BaseData）功能包）包含了一些可复用的业务需求，该功能包的基础包（BaseItems）节点下，通过复用功能包节点定义了扩展所述第一功能包（公用功能包），所述第一功能包（公用功能包）的所有功能点会应用至所述第二功能包（基本数据功能包）中；在所述第二功能包（基本数据功能包）中代表功能点集合项（Items）的节点下，定义了审批状态管理（ApproveStatusManagement）新功能点。第三功能包(Unit功能包)基础包的节点下，通过复用功能包节点定义了扩展所述第二功能包（基本数据功能包）的节点,在代表功能点集合项（Items）下，通过增加标注为Delete的版本管理功能点节点，删除了版本管理（VersionManagement）功能点,所述第一功能包（公用功能包）中除版本管理外的所有功能点以及第二功能包中定义的审批状态管理功能点会应用至所述第三功能包（Unit功能包）中。这样功能包完成了定义设置。

此外，在软件系统开发的应用上，图1中所述功能包M22是可以扩展的，且不仅仅是扩展功能包M22中的一个单个功能，而且可以是扩展一整个功能包M22的所有功能，与传统的通过模块的继承方式相比，功能包M22更具灵活性，耦合性也较低。独立功能包是不能被扩展的，而且功能包之间不能循环扩展，即若第二功能包扩展了第一功能包，则第一功能包不能同时扩展第二功能包。功能包M22之间相互扩展是通过配置文件以达到组合效果。此外，传统技术在使用继承时一般不允许多根继承，而本发明所述功能包的组合却可以继承多个功能包M22中的所有功能。以图3为例，进一步说明图1的功能包M22的变更或扩展过程:在开发软件过程中，会遇到需求变更或扩展，可以通过在独立功能包或者公用功能包中添加、删除或修改功能点以完成需求变更或扩展的动作，而不必修改原有系统的代码或者是重新编译原有系统，这样保证了系统的原有功能和系统结构的稳定，同时增强了系统的可扩展性。修改独立功能包会改变单个应用领域中系统功能和行为，修改公用功能包会改变部分或者整个系统的功能和行为。在图3中，矩形表示功能包，小椭圆表示功能点，空心箭头表示功能包之间的扩展关系，大椭圆表示独立功能包应用的业务领域，功能包A、B、C、E为公用功能包，功能包D、F为在不同业务领域的独立功能包。功能点带撇号表示功能点被修改。由图3可见,公用功能包是可以扩展的。例如，功能包B首先是通过在配置文件中的复用功能包节点定义了扩展功能包A，然后所述功能包B在配置文件中又定义一标注为Delete的功能点节点以删除功能点C，再在配置文件中定义一功能点节点（功能点节点默认为Add，也可以显式标注为Add）以添加功能点D，这样完成了功能包B的定义。

在图1中，功能包M22若使用在独立的业务领域中，功能包M22中的基础包用于描述对公用功能包的扩展，即包含了公用功能包中所有功能点，例如在基础包中添加了两个公用功能包节点，即增加了两个公用功能包所包括的所有功能点的集合。项用于描述对功能点的添加，例如在项中新增一个功能点节点，即增加了其对应的功能点。若在项中删除一个功能点节点，即删除了其对应的功能点。与之相比，在传统技术中，一个个功能通过编译源代码后包装于程序集中，若要修改某一功能，则需要将与该功能相关的源代码重新编译才完成修改动作。一般情况下，传统技术是通过声明一功能模块，并通过修改该功能模块的代码或者通过功能模块的类进行继承，修改其行为，再重新进行编译。而在本发明的功能包和功能点的组合中，功能点是相对独立，在代码中无集合结构，只是在配置中呈现集合。

在图1中，所述配置层M10中的配置M11用于记录每一功能点M21，并产生配置文件。当软件系统执行的时候，系统读取配置M11，也就是说，系统读取了设置在配置M11中的功能点M21。这样，系统可通过所述功能点M21的应用实现相应的功能。同样，所述的配置M11也记录每一功能包M22。功能包M22是定义于配置文件中。配置文件为可扩展标记语言文件(XML)，由配置系统M12读取配置文件中的内容。其中包含了功能点M21以及功能包M22定义。功能包M22的承载方式，除了可以是基于配置文件外，也可以是集成在程序集的DLL中。配置文件打包在程序集中，不易被篡改，因此一般会将重要功能的配置文件存放在程序集中，若对程序集修改需重新编译。一般会将相对容易改变或修改的功能记录在独立的配置文件中，当进行二次开发的时候直接修改配置文件即可完成。例如，实现两个不同类型的单据，一张为订单，一张为售货单，在订单功能包中有审核功能。为了实现在售货单功能中也要有审核功能，在售货单功能包的配置文件中添加订单功能包中的审核功能（功能点），这样，经过售货单配置文件的修改及加载也可实现售货单的审核功能。又例如：在实现订单功能包的配置过程中，首先将保存功能（功能点）添加至该订单功能包中，用于完成保存的需求，然后根据订单功能包所需完成的需求，如审核需求，查询需求，或其他需求，依照需求列表将相关功能添加至该订单功能包中，这样，该订单功能包具有完整的订单的功能，再将每一功能点记录于配置中，此配置即为订单功能包的配置。

在图1中，所述功能层M20中的解释器M23用于解释所述功能点M21。由于每种类型的功能点的目的、功能和应用方式都不同，因此不同类型的功能点M21需由相应的解释器M23予以解释。功能点的解释器M23写在代码中。一个解释器M23对应多个同一类型的功能点M21。若要新置一种类型的功能点M21即要新定义一个解释器M23，通过编写代码来实现，在系统启动过程中，将代码新定义的解释器添加到解释器容器中，从而实现后续新置功能点M21的应用。功能点类型，即软件系统中有很多不同类型的功能，不同类型的功能点的作用不同，应用到软件系统的方式也不同，因此可通过不同的解释器M23将不同类型的功能应用到系统中，实现功能的作用。在本发明方法中已实现的功能点类型包括：实体注册、特性实体、切片、脚本函数导入、数据转换、菜单资源、自动执行、校验和缓存。举例而言，图4给出一个应用的例子说明功能包M22和功能点M21相关的各元件的运作过程：在实现时，首先考虑新增的功能点的功能点类别，如果属于系统中已提供的功能点类别，则在代码中实现功能点时标记该新增的功能点的类别为某一系统中已提供的功能点类别。在代码中实现功能点对应的功能之后，在功能包配置文件中加入该新增功能点节点。在运行时，首先配置系统读取功能包配置，根据功能包配置获取功能点，根据功能点类型的标记，比如为实体类型，该功能点就会由实体类型的解释器进行解释，通过解释器的应用方法，将功能点应用到系统中。这样就完成了功能包及功能点的运作过程。

在图1中，所述框架层M30用于在解释器M23完成解释之后，将所述功能点M21应用至框架层M30中。例如在软件系统中有很多类型的服务，服务一般通过服务容器进行管理。通过本专利方法为服务定义一功能点，通过服务类型的解释器完成服务注册，将该服务加入到服务容器中。

本发明有益效果在于，通过定义功能包和功能点的集合，与传统面向服务(Service-Orientedarchitecture,简称SOA)组合相比，第一，在组合结构上，本发明更灵活方便，功能包将离散的功能点组合在一起，并不在功能包中定义功能包内各个功能点之间的业务关联，因此功能包定义便捷且易于扩展；而SOA服务组合在构建服务组合时根据业务需求将各个服务顺序连接起来，即定义了实现每个细粒度功能的服务调用顺序，复杂度较高。第二，在应用方式上，本发明使用了功能包和功能点，使整个系统处于就绪状态，根据不同的请求可作出不同的响应，执行流程不定义在功能包中，而是耦合在功能点对应的实现代码中（即功能点逻辑写于代码中）。例如单据保存动作，在本专利中定义保存和检查两个动作为两个不同的功能点，在执行保存功能点的时候会先触发检查功能点，所谓的流程动作记录于功能点的定义中。而在SOA系统中，有一单据处理的流程，在定义服务组合的业务流程时定义为先调用检查服务，如果检查通过再调用保存服务。第三，在扩展方式中，本发明利用功能包的扩展性，且独立功能包和公用功能包可相互扩展。而在SOA服务中，定义一服务组合在流程中完成不同的功能，流程的扩展虽然可以进行拼接，但无法实现流程的融合。第四，本专利方法将功能包区分为公用功能包和独立功能包，公用功能包中定义了可复用的功能点，独立功能包在扩展公用功能包的基础上为了实现独立的业务需求加入独立的功能点，如此公用功能包和独立功能包构成了系统功能的层次结构；而SOA服务组合中没有这种功能的层次结构，也没有类似公用的服务组合及独立的服务组合这样的概念。

参见图5和图1，一种软件系统功能划分及组合的方法，基于所述软件系统，其具体实施步骤如下：

步骤S501：将所述功能定义为功能点；

步骤S502：在代码中设置所述功能点的类别标记；

步骤S503：将功能点配置在功能包的配置文件中；

步骤S504：当系统执行时，系统通过配置系统读取配置；

步骤S505：系统根据功能包配置生成功能包对象，功能包对象中包含该功能包中的功能点的集合以及该功能包扩展的功能包对象；

步骤S506：根据功能包对象获取该功能包中的功能点集合；

步骤S507：遍历解释器容器，依据解释器对应的功能点类型，在该功能包的功能点集合中确认每个类型的解释器将要应用的功能点；

步骤S508：通过反射获取每种类型的功能点解释器的应用逻辑；

步骤S509：依次使用所述功能点解释器的应用逻辑将每一该功能点解释器对应的功能点应用到软件系统的底层框架中，完成了所述功能包与功能点的应用过程。

系统一般会预设置解释器。但系统若要设置新的解释器，也可在步骤S501前执行预设置新增的解释器。另外，步骤S501-步骤S503属于定义步骤，是由开发设计人员完成。而步骤S504-步骤S509属于应用步骤，是由系统完成。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (12)

1.一种软件系统功能划分及组合的方法，所述的软件系统具有一配置且具有至少一功能，所述的功能用以完成软件系统的至少一需求，其特征在于，包括以下步骤：

(a)将所述的功能定义为至少一功能点；

(b)所述的配置记录每一功能点；

(c)根据所述至少一需求，将所述的功能点组合成至少一功能包；以及

(d)所述的配置记录每一功能包；

其中，所述软件系统包括配置层、功能层和框架层；所述功能层包括至少一功能包和多个解释器，且每一所述解释器对应多个同一类型的功能点，所述解释器用于解释功能点。

2.如权利要求1所述的软件系统功能划分及组合的方法，其中所述的功能包选自于一公用功能包和一独立功能包中任意一种。

3.如权利要求1所述的软件系统功能划分及组合的方法，其中所述的功能点为公用功能点和独立功能点中任意一种。

4.如权利要求2所述的软件系统功能划分及组合的方法，其中所述的公用功能包是由至少一公用功能点所组成。

5.如权利要求3所述的软件系统功能划分及组合的方法，其中所述功能包为一公用功能包，所述公用功能包是由至少一所述公用功能点所组成。

6.如权利要求2所述的软件系统功能划分及组合的方法，其中所述的独立功能包是由独立功能点和所述公用功能包所组成。

7.如权利要求3所述的软件系统功能划分及组合的方法，其中所述功能包为一独立功能包，所述独立功能包是由所述独立功能点和公用功能包所组成。

8.如权利要求1所述的软件系统功能划分及组合的方法，其中在每一所述的功能包中允许删除或新增或修改一功能点。

9.如权利要求1所述的软件系统功能划分及组合的方法，其中允许由一功能包继承至另一功能包。

10.如权利要求1所述的软件系统功能划分及组合的方法，其中所述的配置是一可扩展标记语言文件。

11.如权利要求1所述的软件系统功能划分及组合的方法，其中所述的配置可集成于所述的软件系统的程序集中。

12.如权利要求1所述的软件系统功能划分及组合的方法，其中所述的软件系统是一企业资源规划系统。