作者：张克强
作者微博：张克强-敏捷307
在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有“业务规则”的属性，在科伯恩方法中有个相近的属性是约束条件。但是业界使用中常常会给用例加上这个属性，这是为什么呢？为什么两位大师没有加上，是大师们疏忽了？而为什么不少人加上了呢？
从时间和传播上很容易推断，业务规则的来源是传统的需求规格说明书。在传统的需求规格说明书中，整理提炼业务规则或称业务逻辑是其中核心的分析产物。受到传统需求规格说明书的深远影响，不少人觉得这样的业务规则是值得写的用例规约中的。
在《用例规约的编写--业务规则和实体描述》一文（下文称为c文）中，将业务规则分为三类：
1．第一种是全局规则，一般与所有用例都相关而不是与特定用例相关
2．第二种是交互规则，产生于用例场景当中
3．第三种是内禀规则，是指业务实体本身具备的规则，并且不因为外部的交互而变化的规则，例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。
在这篇文章的后面提出“将这些单独列出来并给予关注和管理是很有必要的”。
显然的，将全局规则列出的话，肯定不会在用例规约中，因为它与特定用例无关；那么在用例规约中要单独列出来的是交互规则和内禀规则。
先来看交互规则的情况，同样在上述那篇文章中 “交互规则是在用例场景当中产生的，它们规定了满足什么条件后业务将如何反应。通常，这部分规则是最复杂，也最不稳定，最容易变化的。大家所说的需求经常变更相信绝大部分就来自于此”，那么如果是先写了用例场景（指事件流），再将这复杂不稳定交易的规则提炼出来后，就将产生信息冗余一致性的问题。在以后处理变化时，需要修改2处。如果是提炼到用例以外，那么上下文关联问题和冗余不一致问题就更加突出，如果是提炼在用例之内，即是有专门的“业务规则”属性字段，事件流的表现力是足够表现任何复杂规则的，把相同信息在同一个地方写两次是没有必要的。所以这样的提炼是多余的。
而如果是在业务规则中先写了交互规则，再来写用例事件流，也可大致分为两种情况，一是按传统SRS写法已经书写了较完整的交互规则，这种情况下，用例事件流的书写就显得多余，往往在2～4行字中说明参见业务规则，然后事件流就结束了，这种写法相当于穿着用例外衣的传统SRS，我想这也许就是两位大师都没有加上“业务规则”属性的原因。二是先非常概要的记录了业务规则，然后书写事件流来体现业务规则，这种情况下事件流的书写就显得有价值。那么在这种情况下这概要的业务规则就不必要独占一个专门的属性字段，完全可以写到用例的简要说明中。
再来看内禀规则的情况，首先交互规则与内禀规则的差异是极为模糊的，比如诸如“同一类商品数量不能大于5件”在交互中需要校验，是可以属于交互规则的。其次这本身属于需求的范畴，这是业务层面的规则，c文也是说“这类规则是业务实体的内在规则”，但是c文紧接着说“因此应该写到领域模型文档中”。显然的此类规则应当反映在用例中，因为如果不在用例中反映，那么需求就是不完整的，或者需要组合两份文件来理解一个用例，这显然不合适。其次在用例中如何反映？这与交互规则的情况是完全一样，概要可以写到简要说明，具体规则的具体应用在事件流中反映。而“领域模型文档”从字面上推断是属于架构设计范畴，就算是属于需求范畴，一个规则两处都写的话，有冗余不一致问题；如果不在用例中写的话，那么要引用相应文档，这徒增麻烦。
事实上c文在后面说到“同时这部分规则（指交互规则）通常在系统中以Control类去实现，MVC模式如此，SOA架构中的BPEL也是如此”“这类规则（指内禀规则）应该实现到你的实体类中去，不论你的业务实体是EntityBean,JavaBean,POJO还是COM+，根据面向对象的封装原则，内禀的逻辑一定不要让它暴露到外部去”，这就让需求分析去考虑了后续分析设计的任务，需求分析已经是天下难事，再兼顾分析设计，那么用例承担了过重的任务。当然在RUP当中，用例确实承担了如此重的任务，在“拥抱敏捷的用例分析方法”一文中说明了用例分析不必承担过多的职责，不必考虑识别具体实现的类，专注于需求表达。专注于表达需求的用例对后续的面向对象分析与设计同样是高效而且准确的传递信息。
经过以上分析，可以看到“业务规则”确实不是用例规约的必需字段，可以通过用例简要说明和事件流覆盖用例级别所有的业务规则。如果非要有业务规则，有一个简单的规则来帮助判断是否体现了用例分析的优势：事件流的描述文字是否明显比业务规则长？如果很长的业务规则配与很短的事件流，那么这是穿着用例外衣的传统SRS写法。
OO系统分析员之路--用例分析系列（7）--用例规约的编写--业务规则和实体描述，coffeewoo http://blog.csdn.net/coffeewoo/article/details/4073551
拥抱敏捷的用例分析方法，张克强，http://blog.csdn.net/zhangmike/article/details/6790919
原文：http://blog.csdn.net/zhangmike/article/details/26866875