作者：张克强

作者微博：张克强-敏捷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

需求用例分析之四：业务规则相关推荐

需求用例分析之七：业务用例之小结
作者:张克强作者微博:张克强-敏捷307 RUP虽然对于业务对象建模进行了详细的说明,但其本身并没有把业务对象建模(领域模型).业务用例作为必须的工件.Rational系方法把业务用例作为需求 ...
需求用例分析之九：序列图
作者:张克强作者微博:张克强-敏捷307 序列图,也称时序图.顺序图,英文名Sequence Diagram.在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图.而科伯恩 ...
苍狼敏捷需求用例分析方法简介并讲义下载
作者:张克强作者微博:张克强-敏捷307 用例分析方法已经有不短的历史,发展出了多种用例分析方法.笔者花费了大量时间,对用例分析的各个方面进行实践和分析,得到如下系列文章: 需求用例分析之一: ...
需求用例分析之八：用例颗粒度
作者:张克强作者微博:张克强-敏捷307 RUP系的考虑在RUP中,没有对用例的颗粒度给出清晰的指导.2004年Rational 中国区技术销售经理傅纯一发表一文<用例建模指南> ...
需求用例分析之二：级别设置
在<编写有效用例>(阿莱斯特-科伯恩著,以下用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了如下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次 ...
需求用例分析之一：异常流
问题的引出备选流,又称备选事件流,英文是Alternative Flow.在RUP和UML中,备选流的解释如下:备选事件流包括与正常行为相关的可选或异常特征的行为,同时也包括正常行为的各种变形.您可 ...
需求用例分析之六：业务用例之科伯恩系
作者:张克强作者微博:张克强-敏捷307 来自于科伯恩<编写有效用例>对业务用例的说明在<使用 UML 进行业务建模:理解业务用例与系统用例的相似和不同之处>中分析科 ...
需求用例分析之三：补充规约
补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求.这些需求包括: § 法律法规方面的需求和应用标准. § 要建立的系统质量属性,包括可用性需求.可靠性需求.性能需求和可支持性需求 ...
需求用例分析之备选流
#用例分析#之备选流 alternative flow-这是用例方法中最混淆之处,无论中文还是英文,都出现许多不同的理解和不同的做法.问题在于备选流字面意思模糊,可以是可选的不同做法,也可以说异常,也 ...

需求用例分析之四：业务规则

业务规则有哪些？

用例规约与交互规则

用例规约与内禀规则

小结

参考文献

需求用例分析之四：业务规则相关推荐

最新文章

热门文章