商业信息系统业务规则的建模过程及实证分析
业务规则技术是增强信息系统的柔性和敏捷性的重要手段之一。本文介绍了业务规则的分类及形式，探讨了建立商业信息系统业务规则模型的步骤，并加以例证。
关键词：商业信息系统 业务规则 分类
现代企业面对着复杂的商业竞争环境，企业商务活动的动态性也越来越强，因此管理商务活动的信息系统需要进行相应的调整来适应动态的商务活动。在此背景下，一种被称为业务规则管理的新技术被提出。业务规则（BusinessRules）是描述和约束业务的语句，用来刻画业务的结构或者控制和影响业务的行为。传统的软件系统一般把业务规则直接实现为应用代码、客户端程序或实现于数据库的存储过程。一旦业务规则埋没于程序代码之中，就会难于发现、维护和更新。基于业务规则的信息系统是在建立信息系统逻辑模型时，通过对业务规则研究将对业务行为的约束从固化的程序代码中解放出来，避免当由于需求的变化而必须更改业务规则时重新修改代码。
业务规则的分类及形式
（一）业务规则的分类
根据企业的商务活动，可以将业务规则分为目的规则和操作规则两类。目的规则是用描述性的自然语言来描述系统对业务活动的约束，体现商务活动管理的功能和目的。按照管理活动的性质，可以将目的规则细分为业务管理规则、行政管理规则、IT管理规则等。业务管理规则是对执行具体商务处理流程的约束，如客户管理规则、计划规则等。行政管理规则是指那些支持商务活动的政策和限制，如文件管理规则、人力资源管理规则等。IT管理规则是指约束IT管理活动的规则，如数据管理规则、网络管理规则、系统管理规则等。操作规则是系统对具体商务活动操作上的约束，如参与活动的角色、资源、活动间的关联、触发活动的事件、触发活动的条件等。操作规则是目的规则的具体表现和实施，可以分为描述性规则和说明性规则两种。描述性规则描述系统的状态，而说明性规则描述当一些事件发生时，系统所发生的行为。
例如，一个操作规则主要包括活动(Activity)、信息对象(InformationObject )、角色(Actor)、活动资源(ActivityEnabler)等系统要素，活动是业务的核心部分。比如一个采购申请的业务活动，其活动的执行者——采购计划员提出采购申请，其
触发事件为产品需求。该活动正式触发采购申请活动的事件。采购计划员通过采购申请活动，产生了请购单，请购单即为采购活动产生的信息对象。同时，采购申请活动也需要用到库存信息、供应商信息等信息资源。其中，每个系统要素都可以看作一个对象，具有描述对象属性的属性值。正是对这些系统要素属性值的约束组成了一个采购申请业务活动的约束规则。
（二）业务规则的形式
业务规则最初是通过自然语言来描述的，为了将自然语言描述的业务规则转化成能够被计算机系统所理解的标准化形式，需要用一定的格式和符号来描述业务规则的内容，然后再通过形式化描述语言实现自然语言向计算机语言的转化。一般来说，业务规则的形式可用以下标准格式来描述：
＜Event Name＞……本事件名称；
＜Describe＞…………事件描述；
＜Source＞…………资源；
＜Actor＞……………角色；
When
＜Trigger Event＞……触发事件； If
＜Condition＞…………执行条件；
Then
＜Action＞……………活动；
＜Assertion＞…………变量声明。
上式描述了一个完整的业务规则形式。其中包括应用业务规则的事件名称、事件描述、所使用资源、涉及到的角色以及When…IF…Then部分。其中，最重要的内容就是When…IF…Then部分的内容。
根据ECA原则，活动的发生必须是在一定条件下，并具有一定的事件驱动。业务规则可以描述成WHEN…IF…THEN的形式。其中，when 部分是对触发事件的声明；IF 部分是满足该项活动发生的条件；THEN部分描述在IF条件下，所发生的活动内容。对于条件的声明，可以用组成业务规则的对象属性值来表示。对象的属性值表示为Object. Attribute Value的形式。可以通过对象属性值的变化和比较来限定业务对象的活动。
IF部分表示业务活动执行的条件，包括对象属性值的比较等，以信息对象为例。
对象属性值的比较：
IF ＜Information Object＞.＜Attribute value＞ ＞=Value1
IF ＜Information Object1＞. ＜Attribute value＞ ＞=＜Information Object2＞. ＜Attribute value＞
对象属性值的变化：
IF ＜Information Object1＞. ＜Attribute value＞ Changes from ＜value1＞ to ＜value2＞
IF ＜Information Object1＞. ＜Attribute value＞ Changes from ＜value1＞ to ＜value2＞ with ＜value1＞＞= ＜value2＞
THEN部分的内容说明业务规则的执行，可以概括为如下内容：
创建或删除一个或若干个业务活动；
＜Create/Delete Activity＞；
为系统元素的属性赋值；
＜Information Object1＞.＜Attribute1 value＞ =＜Value1＞；
＜Information Object1＞.＜Attribute1 value＞ =＜Information Object2＞.＜Attribute value＞ + ＜Information Object3＞.＜Attribute value＞；
启动一个业务活动；
＜Activity1＞；
错误报道，表示当错误发生时，对错误状态的报道；
＜Integrity Violation Report＞。
业务规则的建模过程
模型是对事物的抽象描述，通过特定的标记、符号、语言、图表等来表示系统。模型具有高度抽象性和概括性的特点。模型的建立过程是一个系统的工程，根据企业业务的需求和系统工程理论，业务规则建模过程可分为如下步骤：
确定目标。企业的商务活动都应该有一个必备的目标，完成这个目标需要一定的资源、活动、信息对象等。目标是对企业商务活动性质、成分、范围的界定。确定业务目标是识别业务过程和业务活动、定义目的规则和操作规则的前提。
定义类。业务规则是对业务活动的约束。业务活动包括角色(Actor)、资源(Source)、活动(Activity)、信息对象(Information Object)等要素。活动要素的划分是根据一定对象特性来进行的。根据对象性质的不同，将具有相同属性的对象划分为一类，就是类的定义。比如，计划员、采购员、库存保管员等都是业务活动的执行者，具有相同的属性，如姓名、年龄等，因此可以将其划为角色类。信息对象是系统中具有信息载体功能的系统要素。如一个合同、一个请购单、一个项目建议书，都是一定业务信息的承载体，所以都可以看作信息对象。活动是由于角色参与，应用一定的资源和信息对象所执行的操作，活动的执行是一次增值的过程。定义类还需要定义类的属性，类的属性可以理解成：类是什么样子的、类知道些什么。
关系描述。关系描述是对上一步骤所定义类之间关系的描述。类与类之间是具有一定关系的，如使用关系、组成关系等。类的关系组成了系统的结构，表明了组成系统的各部分系统要素间的联系，是确定系统业务处理和数据通信的基础。
