规则获取中的规则发现姓名：杨海泷摘要：规则获取包括规则发现和规则发现，本文主要介绍了规则的分类以及常见的规则发现活动。
并给出了简单的规则发现流程。
关键词：业务规则，规则获取，规则发现，规则分类；Rule Discovery in Rule HarvestingYang HailongAbstract:Rule harvesting includes the two main activities of rule discovery and analysis.This paper mainly introduces the classification of rules,common rule discovery activities.In addition,this paper gives out a simple process of rule discovery.Keyword:Business Rule；Rule Harvest；Rule Discovery；Classification of Rules规则发现，也称为企业业务规则建模，目的是开发简单模型，像规则描述，业务实体图表，业务流程图。
规则发现是一个不断迭代的过程，不是一蹴而就的过程。
业务规则发现技术和传统的需求抽取类似，主要有一个不同就是，它更关注企业中的那些特殊的需求，这些需求为业务如何执行提供决策。
在开始阶段，我们首先要获取一些产品，这些产品在规则发现阶段会用到。
这些产品包括：业务流程的顶层描述；当前和将来架构的顶层描述；数据源和数据模型的列表；决策表。
特别是决策表能够帮助定义哪里能够找到规则（规则源），哪个方法可以在规则获取时使用。
规则发现流程会随着规则源的不同而改变。
例如，通过合法文档里获取规则和通过采访专业领域专家获取规则的流程是不同的。
1.业务规则的分类在决定如何书写规则和如何实现他们之前，我们必须要首先明确我们要获取哪一类型的规则。
早在2008年，对象管理组织（OMG）定义了业务词汇和业务规则语义的编制规范，称作业务词汇和业务规则语义（SBVR）。
该规范描述了SBVR作为OMG的模型驱动架构（MDA）的一部分，其目的是捕获自然语言中的规范并正规的方式表示它们以便于自动化。
SBVR包括两个专业词汇：一个是通过商业术语视图定义商业术语和意义。
这在SBVR规范中称为业务词汇。
另一个是用一种清楚的方式表达规则。
所谓意义就是某人理解或者想要表达的意思。
意义可以分成概念，问题和建议。
OMG 定义了一种业务动机模型（BMM），该模型定义了业务政策，管理，业务流程，业务规则之间的关系。
BMM模型沿用了SBVR中的分类：·结构型（定义型）业务规则。
该种类型规则描述业务实体的结构，指定了如值的类型，强制关系等元素。
·操作型（行为型）业务规则。
该种类型规则描述如何加强业务策略使运行效率提高，实现业务决策逻辑等规则。
在SBVR中，规则通常来源于业务实体之间的关系。
提出一个概念“事实”，事实便是两种或者是多种概念之间的联系。
这里我们给出一个业务规则模式。
图1.1 业务规则模式该模式向我们展示了，不同类型的规则都与业务相关，其中包括结构型规则和操作型规则。
表1.1再给出简化的业务规则组织层次，该层次由Barbara Von Halle提出。
2.发现活动规则发现阶段包括一些准备工作，比如审核决策表，用例模型或者业务流程，定义发现路标，以及组织团队合作等，这些都是最基本的准备。
规则发现活动在项目实际实施过程中会发生，甚至在系统完成时也会发生或者在某些决策或者商业政策需要改变时也会发生。
因此规则的发现需要将需求分析，反编译现存程序以及专家知识结合起来。
在我们准备规则发现活动或者路标时需要考虑两个方面：·规则的来源：·相关文档（商业计划书，早期项目交付文档，法律法规，规章制度，标准，需求规格书）·不言而喻的规则（我们做事的方式，专家个性等）·现存系统（当前正在使用的信息系统等）·业务记录（这些记录了已经被满足的客户需求等）·项目中所使用的分析技术：·业务事件分析·用例分析·业务流程建模·商业目标以及策略分析·数据分析很明显，不言而喻的规则是最难抽取的，通常也花费最长的时间。
表2.1给出了几种发现活动可行的出发点：这里需要说明一下，通过这些规则发现活动是不可能抽取所有的规则的，我们的目标是完成40-60%的规则获取。
2.1检查决策表或业务流程图在规则发现阶段，我们需要使用一个决策表文档，下面提供两种得到决策表文档的方式。
2.2.1用例方式如果要使用用例方式收集需求，我们可以研究用例描述来确定系统作出决策时的活动。
在Barbara Von Halle的《Business Rule Applied》一书中，她提出通过寻找动词来发现决策点。
例如，检查，检测，计算，测量，估计，估测，比较，证实，确定，验证，断定等词后面就隐藏着大量的业务知识也业务规则。
表2.2给出一个简单基本贷款流程的用例描述：表2.2 基本贷款流程用例描述上面的用例模板包括一个决策列，该决策列驱动规则发现活动中的讨论。
2.2.2业务流程建模方式业务流程建模至少应该包含以下活动：·通过角色定义流程的行为者，清晰地列出不同的人类行为者，并用角色对其分类。
·用任务和隶属关系，设计当前的流程情况，不要想一下子就分析出所有的流程，应该采用增量方法，不断完善下去。
·从当前要点识别出分支要点。
分支处的决策就可被认为是业务规则。
最简单的是提供一个二元决策，当有枚举类型时就必须作出多个响应。
一般有2到6或者8个分支。
相关管理人员可以设置某些决策的优先级，为了完成这个任务，还必须回答以下问题：·当前要定义、编辑、实现、测试、更新的业务规则的流程是什么？·谁是这些规则和商业政策的所有者？·一些特殊的规则有分类吗？例如：国家，地域或产品层次，以及规则被（其它企业）改写过吗？这些变形也是要获取到的。
·每条决策对应的规则数量有多少？·有没有实际规则的例子？·规则可以共享吗？以上所做是为下一阶段，定义发现路标做好准备。
2.2定义规则发现路标规则发现路标的定义是分析团队从不同的源抽取规则的至关重要的步骤。
路标类型的选择是与规则源相联系的。
Tony Morgan在他的书《Business Rules and Information System:Aligning IT with Business Goals》中提出以下发现过程：·静态分析。
主要是从合法的，内部政策以及步骤等文档中阅读和标注规则。
一定要注意不同文档的版本，创建日期以及合法性。
规则抽取工作是基于问卷调查的。
·交流。
主要是与了解业务流程和决策专业领域专家进行交流。
当然，还应该与日日工作在一线的人进行交流来获得业务流程是如何进行控制的。
规则抽取工作在研讨会中进行。
·自动化分析。
使用计算机和特殊应用程序从程序代码，SQL存储过程，代码列表等中搜索规则语句。
在使用规则挖掘技术时，必须格外小心防止在if-then-else实现时造成的内容丢失。
在这里不再介绍代码挖掘技术。
2.3收集相关文档由于规则发现是基于文档和代码的，因此我们必须收集所有的应用文档，并且把这些文档按照版本进行整理，以备以后溯源使用。
收集的文档越多，规则发现的也便越全面。
人们都有一种思维定式，有文档或者代码支持的系统更容易让人信服。
2.4研究决策分支点业务规则可以由决策分支点处获得，因此研究这些分支点至关重要。
从前面已经获得的决策分支表中分析，不断完善决策的描述。
这个过程要不同的专家参与，或者要阅读相关合法文档。
2.5执行规则发现路标这个活动支持三种类型的规则发现：业务用户和专家组，文档研究，代码挖掘。
即便主要的规则源是文档或者代码，也是应该从专业领域专家获得相应的反馈。
规则抽取是一个不断完善的活动。
因此在整个项目开发过程中与其他成员以及利益相关者密切沟通是至关重要的，因为他们的想法可能会随着项目进行而改变。
在这一阶段中，我们要清楚的知道表达规则的不用语言类型：·自然语言·受限制的语言·特殊语法的正规表达语言自然语言是最初在一些会议上描述规则使用的非正规的，没有任何结构的语言。
使用自然语言时没有模板或者指导提纲，因此会产生冗余。
第二种语言已经加入了某些语法和结构，以便于将规则表达成合适的形式。
第三种语言是最准确的，绝不会模棱两可，是可以被信息系统对象使用的规则，这种规则可被计算机执行。
2.6从SME发现规则与专业领域专家交互的方式有采访和分析研讨会。
其中采访一般是两三个人，研讨会是6-10人进行。
其中分析研讨会是抽取大量需求最有效的技术。
头脑风暴是最有效的方式。
头脑风暴包括意见产生和意见压缩。
投票选举在头脑风暴中也经常使用。
研讨会中通常遵循如下的规则：·不要攻击别人·不要迟到，即便利益相关者会迟到·表达观点时避免太强势另外有些人还提出如下意见完善此过程：·组织者维持一份时间表，惩罚迟到的人，每个人有一次机会迟到·组织者鼓励每个人发言5分钟·为避免长时间的讨论无果，最好通过第三方驱动·倘若某条规则不够明确，最好的办法是将它付诸实践·用具体场景来阐述某些规则2.7从文档中发现规则这种方式用在当存在合法文档时。
我们需要胆量和严肃的态度对待这项工作。
当使用的是电子文档时，我们可以按照如下的规则进行实践：·标记任何需要讨论的内容·将商业政策复制粘贴到规则模板中以便将来进行分析·使用一种系统的方法来确保很好的覆盖尽量多的规则·没前进一步都检查是否与当前业务模型一致·调查差异，并用日志记录它们·关注成员的理解，多与他们交流，坚持理清一条合法规则时如何形成的这种方法有一个风险就是，每个人都有每个人的解释，文档不可能包括所有的情况，因此有时很难得到一个统一的商业动机。
所以要尽量采用一套严格的方法来达到如下的目标：·将业务事件详细列出在一张表中·获得支持那些业务事件处理的活动，任务以及过程·识别出业务规则可以在程序中执行的位置·如果规则不清楚，模棱两可要对其进行解释·试着抽取出对象模型，域内的值我们还应该协同专业领域专家来获得相关的反馈，并且用简单的表格与项目成员进行交流。
2.8从代码中发现规则从应用程序代码中发现规则时非常耗时而且通常很难取得成果的。