使用 IBM Operational Decision Management 建模业务规则

本文介绍实现成功的 IBM ODM 业务规则项目所必要的 3 种模型:领域概念和逻辑模型、可执行对象模型 (XOM) 和业务对象模型 (BOM),以及它们在开发 IBM ODM 业务规则解决方案过程中发挥的作用。文中将描述用于创建模型的 IBM 工具和分析流程,还提供了一些示例。

分析流程在很大程度上利用了 Ronald Ross 的 业务规则方法原则 中描述的 Term–Fact 分析流程和统一建模语言 (UML)。IBM ODM Rule Designer 和 Decision Center 组件方便了业务规则词汇表和语法、业务对象模型 (BOM)、规则项目组织和实际业务规则的创建。规则测试和模拟环境 Decision Validation Services (DVS) 在一种 Microsoft® Excel® 格式中反映了业务用户用于测试他们定义的规则的 XOM。 本文来自于 IBM Business Process Management Journal 中文版

Oscar Chappel, ODM Competency 负责人 , IBM

Oscar Chappel 在设计和开发各行各业中基于规则的解决方案方面拥有超过 25 年的经验,这些行业包括医疗、国防、运输、酒店、保险、金融服务和物流。Oscar 在使用多种建模概念建模业务领域方面拥有近 16 年经验,在统一建模语言 (UML) 的应用上登峰造极。他是一位 Object Management Group Certified UML Professional,是 ILOG Professional Services 在 2004 年雇佣的第一名分析师。Oscar 从那时起开始致力于 JRules 和 ODM 建模。



2014 年 1 月 27 日

简介

业务规则技术(包括 IBM 运营决策管理 (ODM) 规则)在过去 20 年来越来越受到欢迎。业务规则有增强业务敏捷性的潜力,使业务用户能够管理已从业务应用程序源代码外部化的业务规则。业务用户规则管理包括维护一个为了执行业务操作策略而开发的规则存储库。使用业务规则管理系统 (BRMS) 所提供的工具、ODM 规则的组件,业务用户能够查看执行业务策略的业务规则,以及控制业务运营方式的外部法规。业务用户可读取各条规则,识别规则的状态,确定谁最后修改该规则和修改的时间。业务用户能够编辑业务规则存储库中的规则,使用复杂的测试工具测试这些规则,并最终将新修改或新创建的规则部署到实际生产环境中,无需或只需极少的 IT 人员帮助。

如果规则管理活动并不适用于为了启用业务规则开发而必须开发的 3 种模型,那么所有这些活动都不可能完成。这 3 种模型是:

  • 领域类模型 (Domain Class Model) 表示了概念和物理实体,以及位于业务的问题领域中的这些实体之间的逻辑关系。领域类模型是创建成功的业务规则实现所需的其他两种模型的基础。
  • 执行对象模型 (Execution Object Model) 被简称为 XOM,它是为领域类模型而开发的,被用作创建用于创作业务规则的业务词汇表和语法的基础,提供了用来评估并最终执行规则的对象实例。
  • 业务对象模型 (Business Object Model) 简称 BOM,提供了用于创建业务规则的业务词汇表和语法。BOM 是根据 XOM 进行创建的。

本文将介绍创建这 3 种模型的过程,提供了实际执行该过程的示例,还介绍了如何使用能简化该过程的 IBM 工具。


统一建模语言符号概述

在本文中,我们专门使用统一建模语言 (UML) 来建模业务问题领域。因此,确保您理解该符号非常重要。

类符号

类由一种矩形结构表示,这种结构通常被分为 3 部分。类符号的最上面一部分包含类名称。类名称通常使用驼峰大小写格式编写,该格式中每个单词的第一个字母采用大写形式,例如 ClassName。类符号的中间部分包含类的特征或属性的名称,以及以冒号与属性名称分隔的属性值类型。属性名称通常为名词。在属性名称包含多个单词时,这些单词被串联在一起,第一个单词的第一个字母是小写,所有后续单词的第一个字母都采用大写,例如 attributeName : type。类符号的第三部分包含类实例执行的行为或方法的名称。方法名称通常是动词,书写方式与属性名称相同,以圆括号结尾,例如 writeToStream()

图 1. UML 类符号
UML 类符号

关系符号

类可能以多种方式彼此关联。有 4 种常用的关系:

  1. 一般化/特殊化
  2. 组合
  3. 聚合
  4. 关联

除了一般化/特殊化关系之外,UML 关系可表明可导航性,该类在关系中执行的角色,以及关系中的类实例的多样性。

在 UML 2.0 中,双向可导航性使用一条直线表示。单向可导航性使用一个指向关系末端的目标类的箭头 (->) 表示。在业务规则上下文中,可导航性表明一个类 “知道” 另一个类。

一种关系中执行的角色由执行类的关系末端的标签表示,例如 图 2 表明 Engine 类的 0 个或多个实例在与 MotorizedVehicle 类的聚合关系中执行引擎角色。

图 2. 一种聚合关系中的角色
一种聚合关系中的角色

多样性通过多种方式表示:

  • * - 表示 0 对多,是可选的
  • n..* - 表示 n 对多,其中至少 n 是强制性的
  • 1..* - 表示 1 对多,其中至少 1 是强制性的
  • n..m - 表示最少 n 个实例和最多 m 个实例

本文将使用一个示例描述每种关系(组合关系除外),以及每种关系的独特特征。

UML 一般化/特殊化符号

UML 一般化/特殊化符号用于在一个超类和它的子类之间建立关系。超类是子类的一般化,相反,子类是超类的特殊化。一般化/特殊化关系用于表示属性和行为的继承性,其中的子类继承了超类的属性和行为,可添加子类独有的属性和行为。子类也可忽略一种继承的行为的实现,进而引入多态性,这是面向对象的分析和设计的一种不同的特性。一般化/特殊化关系的通俗称法为 “IS-A”,表示子类 “IS-A” 超类。一般化/特殊化关系用一个具有三角箭头的直线表示。箭头指向超类,另一端指向子类。

使用一般化的句子规则

如果以下一个句子在建模的领域中有一定的意义,那么可以应用一般化:

  • 一个子类是一种超类。
  • 一个子类像一个超类。
图 3. UML 一般化/特殊化符号
UML 一般化/特殊化符号

UML 组合关系

UML 组合关系用于表示一个类是另一个类的组件。除了一般化/特殊化关系之外,组合关系是 UML 中表示的最强的关系。组合关系表示关系中的各个组件不能单独存在。删除一个组件会导致删除另一个组件。UML 组合关系由一个指向组合类的充填钻石(filled diamond)和一个指向组件类的箭头表示。组合关系始终表示为一种可单向导航关系。

图 4. UML 组合关系符号
UML 组合关系符号

UML 聚合关系

聚合关系是组合关系得到一种较弱的形式,表示 “部分” 关系。该符号类似于组合关系,一个空心钻石指向聚合类,一条线或箭头指向部分类。

图 5. UML 聚合关系符号
UML 聚合关系符号

UML 关联关系

关联关系是最弱的关系。它表示一个类 “使用” 另一个类。关联关系由一条直线和一个箭头表示,箭头指向两个连接的类中的一个。

图 6. UML 关联关系符号
UML 关联关系符号

执行 Term–Fact 分析

Term-Fact 分析已在 Ronald G. Ross 的 业务规则方法原则 中介绍。Term-Fact 分析是创建业务领域模型的基础。在这本书中,Ross 先生将术语描述为业务人员在其日常的业务职责的执行过程中使用的词汇和短语,将事实描述为描述业务人员所知道的业务真实情况的术语组合。

术语
术语是对业务人员有意义的在业务人员的日常业务职责表现方面的各个词汇或短语。术语可描述合同等抽象的业务概念或物理产品等具体的业务实体。术语可描述业务概念的特征,比如某个合同的生效日期或某个产品的大小和形状。在 UML 建模上下文中,在用一个术语描述一个业务概念时,该概念可建模为一个类。在术语描述一个业务概念的一个属性时,该术语可用作一个类的一个属性的名称。
理解事实
事实是描述业务人员知道的业务真实情况的术语组合。事实可描述业务概念之间的关系,进而可建模为一个 UML 类模型中的类之间的关系。事实可描述业务概念的行为,可建模为方法,这些方法是为建模业务概念的类而定义的。事实也可描述业务领域中的实体交互的方式。事实为业务领域类模型提供了逻辑关联。

描述业务策略和法规

业务策略和法规是一些积极的语句,描述了业务在日常商业行为汇总必须采用的操作和交互方式。根据 Ross 先生的描述,业务策略和法规由事实组成。业务策略和法规需要执行才会生效。软件规则(比如 IBM ODM 规则中创建的规则)可用于自动执行业务策略和法规。业务策略和法规由事实组成,有利于 term–fact 分析流程。在 业务规则方法原则 中,Ross 提供了十几个模板,提供了表达业务策略的标准格式。6 个最常见的模板如 清单 1 中所示。这些模板不仅对编写执行业务策略的规则有用,还对建模必须执行这些策略的业务领域非常有用。

清单 1. 6 个常用的业务策略模板
Rejector: 
<Subject> must/must not <fact> [if/when <condition statement>] <start date> <end date>

Permission Statement: 
<Subject> may/need not <fact> [if/when/while <condition statement>] <start date> <end date>

Computation Rule: 
<Subject> = <mathematical formula> [if/when/while <condition statement>] <start date> <end date>

Derivation Rule: 
<Subject> must/must not be taken to mean <logical expression> [if/while/when <condition statement>] 
<start date> <end date>

Inference Rule: 
<Subject> must/must not be considered to be a <term> [if/while/when <condition statement>] <start date>
<end date>

Imprint Rule: 
<Term> must/must not be set to <term/value> [if/when/while <condition statement>] <start date> <end date>

一个建模示例:计划一个加拿大炼油厂的石油配送

这里描述的示例是虚构的,但描述基于真实情况。

The Acme Refining Company 目前使用了 MicroSoft Excel 来规划产品分发。该配送计划系统不再满足计划需求,所以 Acme Refining Company 启动了一个项目来设计一种基于规则的配送计划解决方案。在与一位任职于 Acme Refining Company 的业务主题专家进行讨论的时候,我们收集到了以下信息。

关于 Acme Refining Company

Acme Refining Company 是一家中型、私营的炼油厂,位于加拿大萨斯喀彻温省。Acme Refining Company 生产 4 种产品:

  • 87 号辛烷,普通汽油
  • 89 号辛烷,中级汽油
  • 91 号辛烷,高级汽油
  • 低硫柴油

Acme Refinery 位于拥有占地几百英亩的大型综合设施。该炼油厂包含一个原油储油库、原油炼油厂、两个存储提炼的汽油和柴油的油库、一条铁路岔线,数百英里管道,数百个油泵,数千个阀门,以及一个配送站,产品从这里配送到 Acme Refining Company 的 200 家客户。

该炼油厂通过铁路罐车接收原油,每个罐车包含大约 30,000 美国加仑或 24,980 英国加仑的原油。石油从位于铁路岔线上的罐车泵送到储油箱中。

炼油厂将原油存储在一个油库中,其中包含 50 个大型储油箱,每个储油箱拥有 5,000 立方米的容量,大约 1,320,850 美国加仑或 1,099,883 英国加仑。Acme Refining Company 的原油储油库总容量约为 54,994,171 英国加仑。

每个原油储油箱的底部有一个 “收集区”,允许收集沉积物和杂质。这个 “收集区” 在每个储油箱底部占据了大约 20,000 英国加仑的空间。原油从储油箱顶部泵送入储油箱。由于放入了流入管,每个储油箱的容量减少了 10,000 英国加仑。因此,对于业务用途,每个储油箱可包含大约 54,964,171 英国加仑。原油使用 30 个电子泵向储油库的储油箱中泵入和从中泵出,这些电子泵由在主要泵送站上运行的软件控制。每个油泵每小时能够泵送 10,000 英国加仑的原油。

Acme Refining Company 的炼油厂一次能够提炼柴油和 3 种等级汽油中的一种。在以 100% 的容量运行时,炼油厂每星期能够提炼 7,200,000 英国加仑原油。该工厂以 80% 的容量运行,以适应炼油厂中的维护需求,因此每星期生产 5,760,000 英国加仑原油。在每星期生产的 5,760,000 英国加仑原油中,有 1,152,000 英国加仑是柴油,4,608,000 英国加仑是汽油。该炼油厂一星期有 4 天生产 87 号辛烷汽油,有 2 天生产 89 号辛烷汽油,有 1 天生产 91 号辛烷汽油。该炼油厂每天运行七天,每天三班倒,每个班次 8 小时。

Acme Refining Company 维护着两个不同的储油库,其中储存着他们的汽油和柴油产品。这些储油库在 20 个储油箱中包含 21,997,668 英国加仑汽油,在 10 个储油箱中包含 10,998,834 英国加仑柴油。每个储油箱的底部有一个 5,000 英国加仑的收集区,用于采集沉积物。包含燃油的沉积物绝不会传送给炼油厂的客户。

每个已提炼燃油储油库包含灌油码头,用于向将燃油拖运到公司客户的油罐车灌油。每个灌油码头可容纳 3 辆油罐车。汽油储油库中有 4 个灌油码头,柴油储油库中有 2 个灌油码头。灌油码头为每一个装载站提供了一个油泵。每个装载站每小时可泵送 3500 英国加仑。

除了提炼原油,Acme Refinery 还使用油罐车将它的精炼产品配送到加拿大北部的偏远地区,每个油罐车可装运 9,000 到 9,300 美国加仑或 7,494 到 7,744 英国加仑。Acme Refining Company 维护着一个有 30 辆油箱拖车和 32 辆牵引车的车队。10 辆拖车用于运输柴油,剩余 20 辆拖车用于运输汽油。Acme Refining Company 能够从独立卡车司机那里租用油箱,以便在必要时扩大内部传送容量。此外,Acme Refining Company 还将他们的产品销售给独立卡车司机,这些司机将燃油运送给非合同客户。

炼油厂使用的所有设备(包括拉动油箱的牵引车、灌油码头和油泵)需要定期维护,可能出现会导致炼油厂总输出容量减少的紧急情况。

Acme Refining Company 的客户是长期合同客户,他们同意购买该公司的预定的产品量,所以需求是固定的。该公司的大多数客户位于靠近北极圈的偏远地区,只能通过结冰的道路到达。因为该公司的客户如此偏远,所以他们都维护着储油库来存储汽油和柴油。该公司的油罐车只能在 9 月末到次年 6 月中旬通过结冰道路运达。因此,该公司必须最大程度地提高它向仅可通过结冰道路到达的客户的配送量,以确保这些客户手头的燃油足够支撑 6 月中旬到 8 月末的夏季。

Acme Refining Company 计划在夏季执行重大的维护,但会继续提炼汽油和柴油,这些燃油在开放市场上售给当地客户。

建模 Acme Refining Company 领域

业务规则的建模遵循一种迭代式方法。本文介绍支持一个配送计划流程的规则创建所需的模型的第一次迭代。建模方法尽可能从一个简单的模型开始,同时应用抽象、封装和多态性的原则。该模型设计来支持可扩展性,支持在分类流程的知识不断扩充的过程中添加类、属性、关联和行为。

建模计划

业务规则解决方案最终将创建配送计划。每个计划都有一个计划开始日期和计划结束日期,这些日期构成了该计划的计划持续时间。配送计划是一种聚合了各个运送计划的计划。每个运送计划需要识别要运送的产品、该产品的量、运送日期、作为运送起点的储油库和作为运送目标的储油库、向其运送产品的客户,以及用于运送的牵引车和油罐车。

图 7. 计划模型
计划模型

点击查看大图

图 7. 计划模型

计划模型

建模领域设施

Merriam-Webster 在线字典将设施 定义为:“某个构建、安装或建立来满足特定用途的东西(就像一家医院)”。

汽油和柴油的运送是一个物流活动,需要能够计算在两个位置(在这种情况下,两个储油库设施)之间运送所需的时长。此外,还需要计算装载或卸载一个油罐车所需的时间长度,以制定一个运送计划。

每个设施都有一个位置,出于配送计划流程的用途,该位置由经度和纬度组成,以支持计算两个设施之间的距离。炼油厂、储油库和暂存区域都是设施的实例,如 图 8 中的设施模型所示。

图 8. 设施模型
设施模型

点击查看大图

图 8. 设施模型

设施模型

建模设备

配送计划的创建涉及一些设备项(比如油泵、储油箱、牵引车、油罐车、有轨罐车和灌油码头)。在创建配送计划时,用于执行配送的设备状态是一个重要的计划元素。所有设备都有一个维护时间表,它将选择在设备维护期间的某个时间段内不可用的设备项。此外,设备可能由于非计划维护而变得不可用。

图 9. 设备模型
设备模型

点击查看大图

图 9. 设备模型

设备模型

建模产品

该炼油厂拥有 4 项产品,包括 3 种不同等级的汽油和一种等级的柴油。

图 10. 产品模型
产品模型

创建可执行对象模型 (XOM)

可执行对象模型 (XOM) 是对其执行规则的模型。ODM 可使用一种基于 Java™ 的 XOM 或基于 XML 模式定义的 XOM(也称为动态 XOM)。使用一个像 Rational® Software Architect (RSA) 这样的工具,创建 XOM 是一个相对简单的任务。

图 11 显示了用于创建 Java 转换文件的 UML 的 Rational Software Architect 向导。在本例中,该文件为 acmeUMLToJavaXform.tc。使用此向导,您可以将 UML 类转换为 Java 源代码,包含为所有属性生成的 setter 和 getter 方法。开发人员惟一需要做的工作是实现这些类的构造函数,这可以通过使用 Eclipse 的一个自动生成无参数构造函数的简单特性来完成。创建 XOM 的机制没有创建 XOM 本身那么重要。

图 11. Rational Software Architect UML 到 Java 转换向导
Rational Software Architect UML 到 Java 转换向导

点击查看大图

图 11. Rational Software Architect UML 到 Java 转换向导

Rational Software Architect UML 到 Java 转换向导

Acme Refining Company XOM

在向导中选择 Run 按钮会创建 图 12 中列出的 .java 文件。

图 12. Acme XOM 的类文件
Acme XOM 的类文件

来自 XOM 的示例代码

下面的代码段是在使用 Rational Software Architect 生成代码时创建的 Java 代码的两个示例。

清单 2. Pump.java
package acme.foundation;

import acme.utility.Rate;

/** 
 * <!-- begin-UML-doc -->
 * <!-- end-UML-doc -->
 * @author Oscar Chappel
 */
public class Pump extends Equipment {
	public Pump() {
		super();
		// TODO Auto-generated constructor stub
	}

	/** 
	 * <!-- begin-UML-doc -->
	 * <!-- end-UML-doc -->
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	private Rate pumpingRate;

	/** 
	 * @return the pumpingRate
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	public Rate getPumpingRate() {
		// begin-user-code
		return pumpingRate;
		// end-user-code
	}

	/** 
	 * @param pumpingRate the pumpingRate to set
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	public void setPumpingRate(Rate pumpingRate) {
		// begin-user-code
		this.pumpingRate = pumpingRate;
		// end-user-code
	}
}
清单 3. Refinery.java
/**
 * 
 */
package acme.facility;

import java.util.Set;
import acme.distributionPlan.DistributionPlan;
import acme.utility.Location;

/** 
 * <!-- begin-UML-doc -->
 * <!-- end-UML-doc -->
 * @author Oscar Chappel
 */
public class Refinery extends Facility {
	public Refinery() {
		super();
		// TODO Auto-generated constructor stub
	}

	/** 
	 * <!-- begin-UML-doc -->
	 * <!-- end-UML-doc -->
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	private Set<TankFarm> tankFarms;

	/** 
	 * @return the tankFarms
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	public Set<TankFarm> getTankFarms() {
		// begin-user-code
		return tankFarms;
		// end-user-code
	}

	/** 
	 * @param tankFarms the tankFarms to set
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	public void setTankFarms(Set<TankFarm> tankFarms) {
		// begin-user-code
		this.tankFarms = tankFarms;
		// end-user-code
	}

	/** 
	 * <!-- begin-UML-doc -->
	 * <!-- end-UML-doc -->
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	private Set<DistributionPlan> distributionPlans;

	/** 
	 * @return the distributionPlans
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	public Set<DistributionPlan> getDistributionPlans() {
		// begin-user-code
		return distributionPlans;
		// end-user-code
	}

	/** 
	 * @param distributionPlans the distributionPlans to set
	 * @generated "UML to Java (com.ibm.xtools.transform.uml2.java5.internal.UML2JavaTransform)"
	 */
	public void setDistributionPlans(Set<DistributionPlan> distributionPlans) {
		// begin-user-code
		this.distributionPlans = distributionPlans;
		// end-user-code
	}
}

创建业务对象模型 (BOM)

BOM 形成了用于编写业务规则的词汇表和语法。BOM 是使用 IBM Operational Decision Manager 的 Rule Designer 组件创建的。Rule Designer 是一种基于 Eclipse 的集成开发环境 (IDE)。与 Rational Software Architect 代码生成一样,创建 BOM 的机制没有实际创建 BOM 那么重要,因为没有 BOM 就无法编写规则。图 13 描绘了为了支持在 ODM 业务规则管理系统 (BRMS) 中创建规则而创建的 BOM。

图 13. Acme Refinery BOM
Acme Refinery BOM

图 14 描绘了 Rule Designer BOM 编辑器中出现的 Pump 类。

图 14. BOM 编辑器中的 Pump 类
BOM 编辑器中的 Pump 类

点击查看大图

图 14. BOM 编辑器中的 Pump 类

BOM 编辑器中的 Pump 类

BOM 编辑器表明,Pump 类描述为 pump>,而且它有一个称为 pumpingRate 的成员(属性)。图 15 表明 pumpingRate 成员描述为 "the pumping rate of a pump"。这是默认的描述。

图 15. BOM 编辑器中的泵送速率描述
BOM 编辑器中的泵送速率描述

点击查看大图

图 15. BOM 编辑器中的泵送速率描述

BOM 编辑器中的泵送速率描述

图 16 显示了修改为 "a pump's pumping rate" 后的 pumpingRate 描述。

图 16. BOM 编辑器中修改的泵送速率描述
BOM 编辑器中修改的泵送速率描述

点击查看大图

图 16. BOM 编辑器中修改的泵送速率描述

BOM 编辑器中修改的泵送速率描述

BOM 编辑器中的 Refinery 类

图 17 显示了 Rule Designer BOM 编辑器中的 Refinery 类。请注意,该类描述为 refinery。该炼油厂有两个分别标为 distributionPlanstankFarms 的成员。

图 17. BOM 编辑器中的 Refinery 类
BOM 编辑器中的 Refinery 类

点击查看大图

图 17. BOM 编辑器中的 Refinery 类

BOM 编辑器中的 Refinery 类

图 18 描绘了 Rule Designer BOM 编辑器中描述为 "the distribution plans of a refinery"distributionPlans> 成员

图 18. BOM 编辑器中的 DistributionPlans 成员
BOM 编辑器中的 DistributionPlans 成员

点击查看大图

图 18. BOM 编辑器中的 DistributionPlans 成员

BOM 编辑器中的 DistributionPlans 成员

图 19 描绘了 Rule Designer BOM 编辑器中描述为 "the tank farms of a refinery"tankFarms 成员。

图 19. BOM 编辑器中的 Tank Farms 成员
BOM 编辑器中的 Tank Farms 成员

点击查看大图

图 19. BOM 编辑器中的 Tank Farms 成员

BOM 编辑器中的 Tank Farms 成员

BOM 完成后,您可开始使用 BOM 中提供的措辞编写规则。


结束语

在本文中,您看到了如何与业务主题专家一道创建初始概念和逻辑领域模型。领域模型包含许多 UML 类图,这些类图提供了该领域的可视表示,可用作创建专门表示复杂规则的各个对象模型的基础。初始的可执行对象模型 (XOM) 已实现,并可用于支持执行将使用从 XOM 创建的业务对象模型 (BOM) 编写的规则。整个模型开发过程是迭代式的。也就是说,初始领域模型、XOM 和 BOM 是基于 term–fact 分析研讨会和早期的规则发现研讨会而创建的。随着项目的不断发展,将会有更多规则发现研讨会和术语事实(term–fact)分析会议,进而导致增加和修改领域模型。这些增加和修改将在 XOM 和 BOM 中反映出来,并最终改进业务规则解决方案。

参考资料

学习

  • IBM WebSphere 软件服务:了解如何使用 IBM 尖端的成熟技术方面的专家经验来帮助您实现业务和 IT 目标。
  • developerWorks BPM 专区:获取有关 IBM BPM 解决方案的最新技术资源,包括下载、演示视频、文章、教程、活动、网络广播等。
  • IBM BPM 期刊:在这个季刊中了解有关 BPM 解决方案的最新文章和专栏。
  • IBM developerWorks 中国 WebSphere 专区:为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库,包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=961317
ArticleTitle=使用 IBM Operational Decision Management 建模业务规则
publish-date=01272014