CN102054047B - 一种服务可配置业务规则的提取方法 - Google Patents

Abstract

本发明公开了一种服务可配置业务规则的方法，本发明采用的技术方案主要包括以下步骤：步骤1：根据量化分析后的业务规则交互关系创建业务规则交互权重矩阵；步骤2：调整矩阵中业务规则之间的关系权重；步骤3：根据经过步骤1和步骤2形成的带权重矩阵进行业务规则的提取；步骤4：对提取后的业务规则进行相应的服务配置。并且在进行步骤1之前要先获取业务规则，业务规则包括约束规则、派生规则和行为规则。在完成步骤1和步骤2后进行步骤3之前，要先确定业务规则的提取原则。本发明解决了现有方法与业务模型UML标记标准不匹配、无法适应每个用户的实际需要、重复建模、系统成本过高、系统响应时间较长等技术问题。

Description

一种服务可配置业务规则的提取方法

技术领域

本发明涉及Software-as-a-service领域，更具体的是涉及服务可配置的业务规则提取方法，而不同于一般基于业务流程建模的业务规则提取方法。

背景技术

近年来随着网络信息技术的发展，尤其是应用软件技术的快速发展，应用软件服务（Software-as-a-service,SaaS）模式已经成为一种新型的软件应用模式。SaaS模式按定购服务的多少和时间长短向厂商支付费用，同时提供软件的离线操作和本地数据存储，以方便客户随时随地使用其定购的软件和服务。在该模式下要满足业务需求各异的不同用户,必须提供灵活的业务规则分类机制，以便让用户在共享实例的基础上构建专属于自己的业务流程。

业务规则是对业务定义和约束的描述，用于维持业务结构或控制和影响业务的行为。业务规则技术的基本思想就是将系统处理的业务逻辑从程序代码中抽取出来，将其转变为简单的业务规则，以结构化的业务规则数据来表示业务行为，业务规则由业务人员创建、实时更新和调试，由于业务规则之间存在着复杂逻辑关系，所以需要将业务规则单独提取出来，使得业务人员能够轻松的对业务规则进行修改、删除和查询等操作。

目前大部分的SaaS平台只能提供功能需求的选择搭配，这些功能是软件供应商进行抽象整理后的模板化的产品，不能保证适应每个用户的实际需要，用户只能在使用或者不使用之间进行选择，而对业务规则抽取的方法多是采用业务流程的方法，该方法多是采用自上而下或一种自下而上的服务识别方法，但该方法不能适用于当前业务模型UML标记标准。另外，基于实体交互模型的业务规则提取方法要求首先定义业务领域相关实体，然后将原模型中的交互规范化，形成有向图，最后根据有向图的关键节点来发现和抽取服务，但是该方法在可操作性上有所不足，对实体之间的每个交互都需要建模，SaaS服务数据的颗粒度越细，系统开销越大，同时增加响应时间，导致同步问题。

发明内容

为解决现有方法与业务模型UML标记标准不匹配、无法适应每个用户的实际需要、重复建模、系统成本过高、系统响应时间较长等技术问题，本发明提出了一种服务可配置的业务规则提取方法，该方法首先对业务规则进行语义规则约束，规定用户必须在既定的范围内进行一定的操作以减少出错率，然后使用一个定量的提取标准，分别从业务规则的相关性方面和业务规则间的交互进行衡量，以业务规则的重用度为度量标准实现业务提取，并通过设计程序加以实现。

为达到上述目的，本发明采用的技术方案主要包括以下步骤：

步骤1：根据量化分析后的业务规则交互关系创建业务规则交互权重矩阵；

步骤2：调整矩阵中业务规则之间的关系权重；

步骤3：根据经过步骤1和步骤2形成的带权重矩阵进行业务规则的提取；

步骤4：对提取后的业务规则进行相应的服务配置。

并且在进行步骤1之前要先获取业务规则，业务规则包括约束规则、派生规则和行为规则。在完成步骤1和步骤2后进行步骤3之前，要先确定业务规则的提取原则，即满足以下三个原则：

（1）每个原子规则必须属于某个特定的业务规则类型；

（2）每个原子规则必须只能属于一个特定的业务规则类型；

（3）为便于专家和用户之间的沟通，提取模式应该非常的直观，能够在在自然语言和机器语言之间找到一个平衡点。

本发明的有益效果在于，能够适用于当前业务模型UML标记标准，能保证适应每个用户的实际需要。另外，采用该方法，对实体之间的每个交互不需要用户重复建模，同时能降低系统成本，减少系统响应时间，解决同步问题。

附图说明

图1为本发明方法的整体框架图。

图2为本发明方法中业务规则的服务配置框架图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步详细的说明。

本发明提供一种服务可配置的业务规则提取方法，对业务规则能够进行合理的分类，每一类业务规则的表示形式给出相应的一个或几个模板，以便能够对业务规则进行修改、删除和查询等操作，同时能够被计算机识别并实现，最后对业务规则进行服务配置。图1为本发明方法的整体框架图。事先从约束规则、派生规则和行为规则中获取相应的业务规则后，本发明方法主要分以下四个步骤来完成。

步骤1：根据量化后的业务规则交互关系创建业务规则的交互权重矩阵；

对业务规则进行提取过程中首先需要将其以某种方式进行量化，将业务规则的相关性定量表示。在对业务规则特性的量化分析中，一方面要考虑业务规则中本身具有的逻辑关系，另一方面也要考虑到业务规则间的交互关系，具体做法是：将n个业务规则集合{f₁,f₂,...,f_n}转化成一个带权重的n*n的矩阵R(f_i,f_j)，且i，j=1,2,...,n，其中规则f_i和自己的关系用权重最大值5表示，每个业务规则表现为一个结点，业务规则间的相连关系通过不同的权重值来体现业务规则间关系的相关度。

步骤2：调整矩阵中业务规则之间的关系权重；

根据业务规则间的相似度和层次影响关系来调整矩阵的权重，得到可体现规则间联系的带权矩阵。矩阵中的权重表示将直接影响到业务规则提取，因此所述权重必须能够表示出业务规则间的关系紧密程度，关系越紧密的规则间连线的权重应该越大，根据这一原则，对权重作出如下定义：

业务规则之间的交互有着多种不同的方式，这些方式决定了各个业务规则的交互依赖程度，本发明将依赖程度通过赋予不同权重的方式体现在业务规则关联矩阵中，并按照依赖程度的强弱依次赋予不同的权重，其中i,j=1,2,...,n且i≠j，矩阵的权重调整具体如下：

（1）若规则f_i的输入依赖于规则f_j的输出，则权值设定为4；

（2）若规则f_i与规则f_j协同，则设定权值为3；

（3）若规则f_i与规则f_j同属于一个流程，但不存在（1），（2）所描述的关系，则设定两者的权值为2；

（4）若规则f_i与规则f_j同属于不同流程，但流程间存在顺序关系，则设定两者的权值为1；

（5）若规则f_i与规则f_j同属于不同流程且不存在任何关系，则设定两者的权值为0。

不过仅仅考虑业务规则间的交互关系还不够，业务规则本身也存在一定的关系，该关系可以用业务规则的相似性进行描述，由于一个业务规则有可能是一个部门完成，也可能是多个部门协同完成，同时由于业务规则模型是至上而下的业务分解模型，业务规则间的层次关系也体现业务间的相似性，所以需要业务规则间的相似性来调整不同业务规则间的权重值。

所述业务规则间相似度体现在两个方面业务规则涉及的部门和业务规则所在的层数，并将m个部门集合P={p₁,p₂,...,p_m}和n个业务规则集合F={f₁,f₂,...,f_n}组成一个m*n的矩阵R_(p,f)，其中R_pf表示部门p使用业务规则f，如果使用了则将其值设为1，否则设为0；且规则f_i和规则f_j之间的业务逻辑相似度如公式（1）所示：

sim(f_i,f_j)＝|P_i∩P_j|           (1)

其中|P_i∩P_j|表示需要同时用到业务规则f_i和业务规则f_j的部门数；

采用两个规则的共同祖先结点的层次数L来表示所述业务规则的层次影响，若L值越大，则两个业务规则的层次关系较大，反之，则两个业务规则的层次关系联系不大；如果规则f_i和规则f_j两者的权值为0，则根据规则f_i和规则f_j的相似度进行设置，设定业务层次的深度为t层，规则f_i和规则f_j权值w_ij如公式（2）所示：

$w_{\mathrm{ij}}=\mathrm{\λ}\·\frac{\mathrm{sim}(f_i,f_j)}{m}+(1-\mathrm{\λ})\·\frac{L}{t}---\left(2\right)$

其中m表示部门集合元素个数，t表示业务层次树的深度，参数λ，且0≤λ≤1，用于调整不同的业务规则模型对业务规则间相似性和业务规则的层次的依赖程度，将规则f_i和规则f_j之间的权重最大值设为4，若w_ij大于4，将w_ij设为4；

如果规则f_i和规则f_j两者的权值原来不为0，则调整后的权值为：

$w_{\mathrm{ij}}=\left\{\begin{array}{cc}{w}_{\mathrm{ij}}^{\&prime;}+\mathrm{\&lambda;}\&CenterDot;\frac{\mathrm{sim}(f_i,f_j)}{m}+(1-\mathrm{\&lambda;})\&CenterDot;\frac{L}{t}& (w_{\mathrm{ij}}<4)\\ 4& (w_{\mathrm{ij}}\&GreaterEqual;4)\end{array}\right.----\left(3\right)$

其中w′_ij为规则f_i和规则f_j的原来的权值。

步骤3：根据经过步骤1和步骤2形成的带权重矩阵进行业务规则的提取；

在完成步骤1和步骤2后进行步骤3之前，要先确定业务规则的提取原则，即满足以下三个原则：

（1）每个原子规则必须属于某个特定的业务规则类型；

（2）每个原子规则必须只能属于一个特定的业务规则类型；

（3）为便于专家和用户之间的沟通，提取模式应该非常的直观，能够在在自然语言和机器语言之间找到一个平衡点。

完成带权重矩阵后，就可开始业务规则提取。一个业务规则可在多个业务流程中被调用，被调用的次数越多就可以认为这是一个复用度较高的规则，以此为基础提炼出的服务同样会具有较高的复用度。在业务规则模型中设置一个阀值n，将被调用超过n次的业务规则设置为一个关键业务规则，并将关键业务规则间的权重设为0，并使任何两个关键业务规则不会被放在同一个服务中。将每个与关键业务规则间权重不为0的规则分配给权重最大的关键业务规则作为初始分类，然后进一步判断非关键业务规则的服务归属问题，判断的原则是：

（1）若规则f_i和规则f_j都是关键规则且相互调用，则规则f_i和规则f_j归属于不同类别；

（2）如果规则f_j只是被规则f_i调用，则规则f_i和规则f_j属于同种类别；

（3）如果规则f_j被规则f_i调用外，还被其他规则调用，则需近一步的判断：

①若调用规则f_j的其他规则与规则f_i同属于一个类别，则规则f_i和规则f_j同属于一个类别；

②若其他规则和规则f_i不同属于一个服务，则系统仅提供一个推荐，将调用规则f_j次数最多的规则并入一个服务中并将该推荐提供给系统分析师，近一步判断规则f_j的归属问题。

步骤4：对提取后的业务规则进行相应的服务配置；

完成对业务规则的提取后就可对业务规则进行服务配置，该方法主要使用业务规则引擎技术来实现。图2为本发明方法中业务规则的服务配置框架图，其中规则引擎是一种嵌入在应用程序中的组件，实现将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。本发明采用的规则引擎是基于Java的ILOG JRules 5.0规则引擎，通过该服务引擎可以进行动态的服务路由配置。

虽然本发明已以较佳实施例公开如上，但实施例和附图并不是用来限定本发明，任何熟悉此技艺者，在不脱离本发明之精神和范围内，自当可作各种变化或润饰，同样属于本发明之保护范围。因此本发明的保护范围应当以本申请的权利要求所界定的为准。

Claims (2)

1.一种适用于业务模型UML标记标准的服务可配置业务模块的提取方法，事先从约束模块、派生模块和行为模块中获取相应的业务模块后，其特征在于，所述方法包括以下四个步骤来完成：

步骤1：根据量化后的业务模块交互关系创建业务模块的交互权重矩阵；

对业务模块进行提取过程中首先需要将其以某种方式进行量化，将业务模块的相关性定量表示；在对业务模块特性的量化分析中，一方面要考虑业务模块中本身具有的逻辑关系，另一方面也要考虑到业务模块间的交互关系，具体做法是：将n个业务模块集合{f₁, f₂, ..., f_n}转化成一个带权重的n*n的矩阵R(f_i, f_j)，且i，j=1,2, ...,n，其中模块f_i和自己的关系用权重最大值5表示，每个业务模块表现为一个结点，业务模块间的相连关系通过不同的权重值来体现业务模块间关系的相关度；

步骤2：调整矩阵中业务模块之间的关系权重；

根据业务模块间的相似度和层次影响关系来调整矩阵的权重，得到可体现模块间联系的带权矩阵；矩阵中的权重表示将直接影响到业务模块提取，因此所述权重必须能够表示出业务模块间的关系紧密程度，关系越紧密的模块间连线的权重应该越大，根据这一原则，对权重作出如下定义：

业务模块之间的交互有着多种不同的方式，这些方式决定了各个业务模块的交互依赖程度，依赖程度通过赋予不同权重的方式体现在业务模块关联矩阵中，并按照依赖程度的强弱依次赋予不同的权重，其中i, j=1,2,...,n且i≠j，矩阵的权重调整具体如下：

（1）若模块f_i的输入依赖于模块f_j的输出，则权值设定为4；

（2）若模块f_i与模块f_j协同，则设定权值为3；

（3）若模块f_i与模块f_j同属于一个流程，但不存在（1），（2）所描述的关系，则设定两者的权值为2；

（4）若模块f_i与模块f_j同属于不同流程，但流程间存在顺序关系，则设定两者的权值为1；

（5）若模块f_i与模块f_j同属于不同流程且不存在任何关系，则设定两者的权值为0；

通过业务模块间的相似性来调整不同业务模块间的权重值，所述业务模块间相似度体现在两个方面业务模块涉及的部门和业务模块所在的层数，并将m个部门集合P={p₁, p₂, ..., p_m}和n个业务模块集合F={f₁, f₂, ..., f_n}组成一个m*n的矩阵R_(p, f)，其中R_pf表示部门p使用业务模块f，如果使用了则将其值设为1，否则设为0；

采用两个模块的共同祖先结点的层次数L来表示所述业务模块的层次影响，若L值越大，则两个业务模块的层次关系较大，反之，则两个业务模块的层次关系联系不大；

步骤3：根据经过步骤1和步骤2形成的带权重矩阵进行业务模块的提取；

在完成步骤1和步骤2后进行步骤3之前，要先确定业务模块的提取原则，即满足以下三个原则：

（1）每个原子模块必须属于某个特定的业务模块类型；

（2）每个原子模块必须只能属于一个特定的业务模块类型；

（3）为便于专家和用户之间的沟通，提取模式应该非常的直观，能够在在自然语言和机器语言之间找到一个平衡点；

完成带权重矩阵后，就可开始业务模块提取：一个业务模块可在多个业务流程中被调用，被调用的次数越多就可以认为这是一个复用度较高的模块，以此为基础提炼出的服务同样会具有较高的复用度；在业务模块模型中设置一个阀值n，将被调用超过n次的业务模块设置为一个关键业务模块，并将关键业务模块间的权重设为0，并使任何两个关键业务模块不会被放在同一个服务中；将每个与关键业务模块间权重不为0的模块分配给权重最大的关键业务模块作为初始分类，然后进一步判断非关键业务模块的服务归属问题，判断的原则是：

（1）若模块f_i和模块f_j都是关键模块且相互调用，则模块f_i和模块f_j归属于不同类别；

（2）如果模块f_j只是被模块f_i调用，则模块f_i和模块f_j属于同种类别；

（3）如果模块f_j被模块f_i调用外，还被其他模块调用，则需近一步的判断：

①若调用模块f_j的其他模块与模块f_i同属于一个类别，则模块f_i和模块f_j同属于一个类别；

②若其他模块和模块f_i不同属于一个服务，则系统仅提供一个推荐，将调用模块f_j次数最多的模块并入一个服务中并将该推荐提供给系统分析师，近一步判断模块f_j的归属问题；

步骤4：对提取后的业务模块进行相应的服务配置；

完成对业务模块的提取后就可对业务模块进行服务配置，使用业务模块引擎技术来实现；所述模块引擎是一种嵌入在应用程序中的组件，实现将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策；所述模块引擎是基于Java的ILOG JRules 5.0模块引擎，通过该服务引擎进行动态的服务路由配置。

2.根据权利要求1所述的服务可配置业务模块的提取方法，其特征在于：所述模块引擎是基于Java的ILOG JRules 5.0模块引擎，通过该服务引擎进行动态的服务路由配置。

Images