作者：张克强    作者微博：张克强-敏捷307

来自于科伯恩《编写有效用例》对业务用例的说明

在《使用 UML 进行业务建模：理解业务用例与系统用例的相似和不同之处》中分析科伯恩编写有效用例如下：

Cockburn 的 Writing Effective Use Cases 给业务和系统用例使用了相同的用例说明模版。业务用例与系统用例说明使用这个模版的区别是设计范围，而不是模版。Cockburn 想通过目标层次对用例进行分类，如表格1所示。

Cockburn 编写 Writing Effective Use Cases 的最初目标是系统用例，但他在业务用例上也花了很多精力。他利用目标层次来区分业务与系统用例，而不是使用不同的模版类型。那么这些图标和目标层次又意味着什么呢？

这些图标本身代表着一个简单的系统，它是根据用例与“海平面”（用户的实际层次）的相对高低来确定的。系统用例的最佳点是用户目标，通过海平面图标来表明。有时候需要将复杂的系统用例分解成其它有子功能目标、通过鱼图标表明的用例。但是您应该尽量避免将海平面系统用例分解成蛤或者最低层系统用例。

也许您会猜测到，概要或者蛤用例应该是业务用例。云或者高层概要也可能是业务用例。

Cockburn 的方法是将这些用例看作是一个光谱，从一个组织的最高层次业务目标，到为实现这些业务目标而执行的软件解决方案的需求详细资料。这种方法将系统用例看作是一个业务用例的分解。这个用例分解方法可以用来帮助您从这个业务模型驱动系统用例模型。

业务用例在编写有效用例的位置

编写有效用例的章节安排是一开始就直接讲用例，第一部分的标题用例体部分，没有提到业务用例，是到第二部分的第15章才提到业务过程建模和业务用例，第15章总共的篇幅6页。第2部分的标题是经常讨论的主题，第12章是第二部分的第1章，标题是什么时候才算完成，第13章标题是扩展到多个用例；第14章标题是CRUD和参数化用例。

关于业务用例的两个坏消息

他在第15章最后说到：

业务用例与系统用例具有相同的特征，因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西，也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。

第一：编写者和读者经常把二者弄混，可能把系统行为放入业务用例中，也可能把业务操作归于系统用例。如果能够商量着去做将会有所帮助。但通常编写者和读者不会认识到这样做的重要性。使用系统用例的读者批评业务用例所处层次太高，但却没有认识到提供系统详细的行为细节不是业务用例应该做的；业务用例编写者偶尔把系统行为细节写入其中，结果导致业务主管对这类有详细细节行为的文档失去了兴趣。

第二：完全且正确的连接系统和用户用例不太值得。通常，业务用例编写者应对业务过程到系统使用（通常没有描述）进行描述。而在描述日常生活中客户如何使用新系统之前，用例编写者已经花光时间、财力、精力以及热情。而系统用例编写者有时为了保持一致，会在业务过程中加一两句，但是他们通常不愿意重写一个包含新系统功能的业务用例。这样就在系统用例和业务用例之间形成了空隙，即系统用例和业务用例之间的不一致。

虽然科伯恩在后面附了来自于FirePond公司使用业务用例的正面例子，但可以看出那是少数派。