需求用例分析之七：业务用例之小结
作者：张克强 作者微博：张克强-敏捷307
RUP虽然对于业务对象建模进行了详细的说明，但其本身并没有把业务对象建模（领域模型）、业务用例作为必须的工件。Rational系方法把业务用例作为需求规格说明（SRS）前的推荐工件。在《编写有效用例》中，业务用例被放在很次要的位置，前面提到云朵和风筝时，科伯恩并没有清晰的指出这是业务用例，相反的还是在系统范围内讨论用例。而且科伯恩还指出了2大“坏消息”。
Dean Leffinwell, Don Widrig所著《软件需求管理用例方法》第2版中的一个小节：何时使用业务建模：业务建模不是我们对每个软件工程工作的推荐。当应用环境是复杂而且横跨多领域，并且许多人员直接参与到系统使用，业务建模带来最大价值。比如，如果你在一个既有通讯交换器上添加一个补充功能，你没有必要考虑业务建模。另一方面，如果你要为GoodAreUs建设订单入口系统，那么进行业务建模为支持问题分析带来好处。
附加说明，《软件需求管理用例方法》书中前文是采用业务用例来进行业务建模的，这与RUP是一样的，此书总共502页，业务建模章节占了8页。
在Frank Armour和Granville Miller的《高级用例建模卷Ⅰ:软件系统》一书中，没有提及业务用例，有意思的是，提出了“发现概念层次的系统用例”，并且与科伯恩利用目标帮助识别用例的方法联系起来了。这与《编写有效用例》其实是一样的观点，《编写有效用例》在前面说明不同目标的用例，并没有提到业务用例，所分析范围其实是在系统范围内，恰是符合此书提出的“概念层次的系统用例”。
在KurtBittner，Ian Spence《用例建模》（出版社 清华大学出版社，出版时间 2003-5-1）中，全书同样没有提及业务用例，其提出描述问题领域和环境的关键概念是必需的，有三种形态：1，简单的文本词汇表；2，正式的领域模型；3，带有图片说明领域模型的文本词汇表。从其说明可以看出，正式的领域模型包括业务用例。
Doug Rosenberg / Kendall Scott 的《UML用例驱动对象建模》（出版社: 清华大学出版社
出版年: 2003-7-1），也即是著名的ICONIX方法，全书同样没有提到业务用例。
高焕堂编著的《USE CASE入门与实例》（2008年出版)全书没有提到业务用例。
徐峰的《软件需求最佳实践》（ 出版社: 电子工业出版社 出版年: 2008）使用其它方式进行业务流程分析，没有提到业务用例。
邱郁惠著的《系统分析师UML用例实战》（2010年出版）是一本用例分析入门书，全书没有提到业务用例。
谭云杰的《大象Thinking in UML》第2版，全书有526页，书中前后花费了17页来说明了业务用例，其中提到“并不是所有的软件需要从业务用例建模开始”，其17页中的将近一页来是用来说明使用和不使用业务用例模型的理由，核心内容与Dean Leffinwell, Don Widrig所著《软件需求管理用例方法》中的“何时使用业务建模”是一致的。
在某本我不愿意提起书名但口气超大的书中，花了前面的131页来谈业务建模，而后面的需求分析占领101页，是众多用例类书的特例。
在最新的Use-Case 2.0中，业务用例在后半段被提到了一次，重点放在了引入Use-Case Slice。
通过以上，可以清楚的看到，业务用例在用例分析中的位置：1，不是必需的；2，可被替代的。
就笔者亲身经历而言，除了在RUP材料与及Rational后续文章中看到较好的业务用例之外，就没有在实际使用中看到过合乎RUP的业务用例。在笔者亲自参与的项目中，都是直接采用用例（系统用例），而在处理复杂并且不熟悉的业务时，绘制流程图、活动图等等来作为理解业务的载体。
更多相关文章
需求用例分析之一：异常流需求用例分析之二：级别设置
需求用例分析之三：补充规约
需求用例分析之四：业务规则
需求用例分析之五：业务用例之Rational系
需求用例分析之六：业务用例之科伯恩系