内容


IBM Industry Models 和 ILOG 业务规则管理系统,第 1 部分

使用 IBM Industry Models 定义业务规则

业务规则的分析和设计

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM Industry Models 和 ILOG 业务规则管理系统,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM Industry Models 和 ILOG 业务规则管理系统,第 1 部分

敬请期待该系列的后续内容。

什么是 IBM Industry Models?

IBM Industry Models 是一组相互相关的模型,它描述了应用程序、数据存储或特定业务领域的集成解决方案的分析与设计的不同方面。这些模型由一组基础模型组成,这些基本模型反过来又支持一组细化的模型,这些细化的模型解决一个特定的问题或建模域。

基础模型帮助定义项目范围,并帮助识别不同项目之间可能被忽视的差别。此外,基础模型还为构建所有其他 Industry Model 产品提供基础,并提供一个标准业务术语词典,以确保整个模型集的一致性。由此派生的模型分别通过过程、UML 服务和 ER 模型满足过程、服务和数据域的需求。

Industry Models 的目的是提供详细的业务内容。每个模型都是全球多个组织为构建大型企业模型而进行多年的开发的结果,然后通过这些大型企业模型凝聚项目开发的力量。在这些项目计划中,允许定制和扩展这些模型,这需要定制和治理模型的专门方法。

每个行业都有一组基础模型,以确保整套模型的一致性,并提供了模型的一个业务入口点。这些模型由一组业务定义组成,它们主要是细化与整个模型集相关的业务概念功能和操作。

从这些基础模型可派生出一组特定于问题的模型,这些模型将这些业务定义扩展为过程、服务和仓库域。下面的图 1 突出显示了本文将讨论的那些模型:

图 1. IBM Industry Models
IBM Industry Models
IBM Industry Models

为什么业务规则很重要?

在这个模型集中,业务规则出现在很多不同的位置,尤其是流程分析。有些形式的规则在模型中的业务类型定义中是隐式的,它们出现在被建模领域的业务类型的 UML 和实体关系(ER)模型中。有些形式的规则详细列出这些业务类型中允许的更改,它们以服务定义和状态转换模型中的约束出现。我们还将遇到一些可影响业务逻辑的流控制规则。这些规则通常出现在过程和服务分析模型中的过程或服务流控制中。

图 2. Industry Models 中规则的位置
Industry Models 中规则的位置
Industry Models 中规则的位置

这就形成了一组既定的规则组织模式;规则出现在 Industry Models 中的这些地方,并且需要规范说明:

  • 与业务流程或活动相关的规则:这些规则与业务流程模型中的流控制逻辑相关,它们影响分支和业务任务序列的流控制。这种规则往往出现在流程模型中的分析时,并且需要规范化,以驱动软编码的过程流(例如 BPEL)或应用程序逻辑。
  • 与服务相关的规则:这些规则与服务逻辑的执行相关,它们和与业务流程和活动相关的规则关系紧密。因此,这些规则常常也是在流程分析期间出现;但是,在将其规范化为 IDM 中的服务规范的一部分之前,它们还需要作为业务对象模型的一部分进行分析。
  • 与信息相关的规则:这些规则与信息、信息之间的关系以及允许的信息状态相关。这种规则出现在信息分析阶段,可能作为业务对象模型的一部分,也可能作为逻辑数据建模的一部分。这些规则可在服务规范中进行规范化,以控制信息结构,或者在信息平台本身中进行规范化。

必须以结构化的方式识别、分析和设计所有这些规则,以维护它们与所在的模型工件以及所引用或操作的模型工件的关系。这需要一个已定义的方法来支持业务规则的分析和设计。此外,还需要一组已定义格式以捕捉这些规则,以及这些规则与其他模型工件之间的规范化关系。捕捉和管理这些规则很重要,因为无论这些规则最终是被具体化到一个规则引擎中,还是硬编码到软件中,或者是通过人力过程去实现,它们都是需求定义中不可或缺的一部分。这些规则遵从 Industry Models 的数据结构、过程和服务,从而可以完整地表达业务需求。

什么是业务规则?

业务规则是对业务的某个方面进行定义或约束的语句。业务规则的目的是通过结构的强制实施来控制或影响业务的某个方面。

业务规则的形式

术语业务规则(business rule)非常宽泛,需要进一步分类。对于本文,我们将面对四种不同形式的业务规则:

  • 业务术语业务术语(business term)是最基本形式的业务规则。定义一个术语的同时,也就是在规范化地描述相关者如何传达一个概念。术语一般是通过业务术语表或作为一个模型(例如 ER 模型)中的概念来捕捉的。业务术语的一个例子是客户(customer),我们将其定义为 “将从建模的组织或它的一个组织单位接收服务或产品的一方所扮演的角色,或者些服务或产品的潜在接收者”。
  • 事实:业务的结构可以用术语事实(fact)来描述,事实将业务术语彼此联系起来。事实可以采用自然语言语句的形式,也可以作为一个规范模型中的属性、关系或概要。事实的一个例子是 “一个客户有一个地址”。
  • 派生派生(Derivations)描述如何通过推理或数学计算将一种形式的信息转换成另一种形式的信息。推理通过使用逻辑归纳或演绎产生一个派生的事实。数学计算则根据指定的数学算法产生一个派生的事实。派生的例子有 “具有相同地址、名字、姓氏和出生日期的两个客户是同一个客户”(推理),或者 “平均客户利润率等于所有客户利润率的总和除以客户利润率数量”(数学计算)。
  • 约束:事实描述业务领域中不同类型之间的关系,而约束(constraints)则描述那个领域中的限制。约束通过相应的规则(通常是一个事实)作用于业务术语(一个主体)。相应规则是实现约束的规则。约束的一个例子是 “一个客户有且只有一个合法地址”。这个约束的主体是客户。相应规则(事实)是 “客户有地址”。

规范化的程度

在定义了业务规则的这 4 种形式之后,我们来讨论一下 “规则” 的意义以及规则之间的关系。但是,需求-分析-设计周期中的不同参与者是以不同程度的规范化和结构来表达规则的。

业务用户往往以非规范化的方式表达规则,通常使用自然语言,并且将多个规则组合到一个语句中(例如 “……潜在客户必须经过信用检查和验证……”)。在此,我们将这些非规范化定义称作业务规则语句(Business Rule Statements)。业务用户还常常通过业务策略(Business Policy)来进行表达,例如 “我们只处理经过信用检查和验证的客户”。虽然策略和规则紧密相关,但它们具有不同的结构。业务策略将不同的业务规则语句组织在一起,作为一个通用的指南或规则上下文。

分析人员会将规则分解成原子规则元素 —— 尽可能分解且不丢失业务信息的规则定义。一个给定的业务规则语句通常可产生多个相关的原子业务规则。虽然原子业务规则仍然是以自然语言的形式表达,但是它们更加规范化和精确,并且规范化规则定义,消除相关规则语句之间的重叠。

然后,规则设计者可以使用这些原子规则,以特定于目标环境的格式表达它们。如果使用了规则引擎,那么这种格式通常特定于该规则引擎。注意,一个原子业务规则可能以多个规范化规则语句的形式出现,每个规范化规则语句具有不同的规范化表达类型。这种表达不一定与具体化的规则执行环境或规则引擎相关联,规则可以 “硬编码” 到应用程序逻辑中,也可以由组织中的雇员亲自执行。

图 3. 业务规则的规范化程度
业务规则的规范化程度
业务规则的规范化程度

当使用 Industry Models 时,为了满足业务目标,组织在构造解决方案时需要经历计划、需求收集、分析和设计等阶段。为了将这些阶段规范化,除了模型之外,还需定义一个蓝图,其中包含一组方法原则。例如,在 SOA 中,这个蓝图指导组织在开发周期中识别项目边界、分析业务流程、识别服务等(蓝图包含在 Industry Models 中)。

图 4. 定制 Industry Models
定制 Industry Models
定制 Industry Models

虽然这个蓝图也为项目小组提供使用模型的通用指南,但它的重点在于解决与可重用服务的识别、分析和设计相关的挑战。显然,这并不是分析和设计中惟一需要考虑的因素。此外还必须考虑其他部分的分析和设计,例如用户界面,人的行为,以及业务规则。

图 5. 分析和设计的各个方面
分析和设计的各个方面
分析和设计的各个方面

本文的目的是在 IBM Industry Models 的上下文中描述业务规则的分析和设计的相关方面。

我们在实践中发现,除非一个项目是完全空白的,否则,除了进行自上而下的分析外,还需对预先存在的代码和业务逻辑进行自下而上的分析。代码、电子表格、数据库表等都需要检查,并由此生成原子业务规则,甚至还可能生成全新的数据结构。然后,将这种分析与自上而下分析的结果相结合,形成更完整的描述。

规则服务

将业务规则公布为服务,可以消除规则表达语法的多样性和特定于规则引擎的支持导致的复杂性。识别可重用服务定义,以封装原子规则,让那些规则可以公布为以 WSDL 表达的 Web 服务,从而将规则的客户与实现规则的复杂性分离开来。因此,本文中描述的方法保留了原子规则和生成它们的业务模型之间的密切联系。很多业务规则都可以映射到业务活动,后者又可以驱动业务服务的定义。

图 6. 定义规则服务
定义规则服务
定义规则服务

保留这种联系便于分析和定义服务,这种服务以独立于定义本身的方式封装规则。此外,规则操作派生于 IDM 的可重用业务对象,而不是允许每个规则操作特定于它本身的数据集和特定于平台的表示。建立一组用以调用规则的一致的 WSDL 接口之后,便可以使用多种不同的技术实现规则,而不必强迫规则的客户适应各种不同的技术。

业务策略

业务策略是业务指令的非规范化表达,用于指导整个业务,通常由业务用户制定。这些策略定义常常出现在分析设计周期的早期,在业务流程分析期间一般作为附加细节。策略本身很少以业务规则的形式出现;它们往往充当指导原则,作为表达规则的基础。

图 7. 业务策略示例
业务策略示例
业务策略示例

业务规则语句

业务规则语句提供强制实施业务策略所需的附加细节。它们也是由业务相关者直接表达的非规范化、非结构化的语句。业务规则语句通常包含多个紧密关联的不同的指令,将业务规则语句分解成原子业务规则是很必要的。

业务规则语句通常与一个业务流程中的活动紧密相关,它可以识别与一组业务规则语句相关的一个流程中的活动。这样做有助于确保业务流程中的这种活动与最终支持它所需的业务规则之间的清晰的联系。虽然业务规则与调用它们的业务活动之间存在这样的关系,但是这些规则实际上是通过业务服务调用的。Industry Models Customization Roadmap 告诉我们,大多数业务活动都有有可能成为服务。对于业务规则也不例外 —— 包含规则语句的一个业务活动将分解为一个业务服务。该服务实际上是那些规则的实现,它通常在一个规则引擎中。通过服务使流程与规则分离,意味着封装规则的服务不操作流程的数据结构。就像其他服务一样,这些服务具有输入和输出数据结构。流程与规则之间的通信通过服务的接口进行。

图 8. 规则语句示例
规则语句示例
规则语句示例

规则表达式

原子业务规则是以自然语言表达的规范化规则语句,它独立于任何特定的规则语法。将这些原子规则转换成特定的规则语法,就可以得到规则表达式。注意,每组规则表达式只是一组特定业务规则的一种表达方式,它依赖于用于表达它们的语法。可以合理地假设,一个特定的规则可能在不同的地方以不同的格式表达,并且可以同时使用多个规则表达式类型。规则表达式中使用的语法高度依赖于目标执行环境。这里的选择范围很广 —— 从编译语言到动态规则引擎。本文接下来的章节只探索其中的一小部分。

图 9. 规则表达式示例
规则表达式示例
规则表达式示例

捕捉策略和规则语句

现有的行业模型客户都熟悉 Industry Models Customization Roadmap 的建议,它突出了在流程分析期间捕捉原文需求定义的优点。其中提供了用于这些需求的一个例子模板,下面的表 1 显示了其中的一个子集。(该模板包含在 Industry Models 中)。

表 1. 活动描述文档
业务规则与这个活动的任何特定规则相关的一个定义。它们通常表示为编号列表(bulleted list),或描述活动如何执行的 “if...then” 条件语句。
关键成功因素必须存在使活动能够成功执行的前提或成功因素的定义。它们通常以编号列表的形式出现。这可能包括在新流程中以不同方式实现的创新部分的描述。
约束流程上任何已知的限制或约束的定义。这可能包括法律或规章制度需求,只要它们与这个活动相关。
依赖这个活动的操作依赖的任何逻辑单元或其他过程的定义。这包括为实施该活动而作出的策略更改和组织决策。
非功能性需求没有与该活动的业务定义直接相关的支持需求的定义,但这些需求仍然影响活动是否成功。例如关键性能指标和业务的系统支持需求的定义。

这种模板的作用是鼓励以半结构化的方式捕捉原文需求,以便分析师人员以后能够使用它们。除了规范化模型以外,还可能创建和管理基于这些模板的文档,以提供驱动分析和设计思路所需的需求输入。

RequisitePro 中基于规则的需求

对这些半结构化需求的管理可以在很多环境中完成,但是,IBM Rational® RequisitePro 提供了很多有用的功能。RequisitePro 可以作为 IBM WebSphere® Business Modeler(WBM)或 Rational Software Architect(RSA)工具集中基于 Eclipse 的插件,以便将结构化需求文档映射到模型元素。这样,业务策略和规则语句信息可以以原文的形式捕捉,并直接映射到相关的业务活动和 UML 结构。

图 10. RequisitePro 中的策略和规则语句
RequisitePro 中的策略和规则语句
RequisitePro 中的策略和规则语句

这些需求类型之间也可以建立关系。例如,业务策略可以与支持它的业务规则语句建立关系,如下面的图 11 所示:

图 11. 在 RequisitePro 中将策略与规则语句相关联
在 RequisitePro 中将策略与规则语句相关联
在 RequisitePro 中将策略与规则语句相关联

这些需求类型除了彼此之间的关联外,还可以与相关的业务模型元素建立关联。例如,在银行上下文中,业务策略 “我们只处理经过信用检查和验证的客户……” 可以表达为一个需求文档,这个需求文档可映射到业务流程 “Provide Banking Product Arrangement Offer”,后者以一组编入文档的客户需求为输入,并产生满足那些需求的一个产品。同样,业务规则语句 “……潜在客户必须经过信用检查和验证……” 可映射到同一个业务流程中的活动 Analyze Customer Relationship。这里提供的方式不仅可以捕捉简化的例子,还可以捕捉复杂的策略和规则语句。在 RequisitePro 中定义定制的模板很简单,可根据组织的需要添加属性,以更好地捕捉他们的规则需求和对规则的管理。但是,从 Industry Models Activity Description Documents 开始可以提供有用的指南。

注意,使用 RequisitePro 管理业务策略和业务规则语句符合 Industry Models 的当前工具建议。例如,现在已有一些文档过程。它们可以管理业务范围,以及与使用 Requisite Pro 的模型相关的功能性和非功能性需求。通过这些建议和以上对策略和规则语句的管理,可以在 Rational Software Architect(RSA)和 WebSphere Business Modeler(WBM)中将这些元素与特定的项目计划和业务目标关联起来。

结束语

本文首先讨论了业务规则的特性及其与 IBM Industry Models 的关系。然后讨论了捕捉基于规则的需求的技巧,以及这些需求的规范化程度。本系列的下一篇文章以此为基础,讨论这些规则结构在 ILOG BRMS 中的使用,以完全指定在业务流程或应用程序执行期间调用的规则集。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, Rational
ArticleID=365140
ArticleTitle=IBM Industry Models 和 ILOG 业务规则管理系统,第 1 部分: 使用 IBM Industry Models 定义业务规则
publish-date=01192009