UML 从需求到测试 2 业务用例（二）

业务用例 （二）

 你曾经梦到过蚂蚁牵大象吗？好的，我知道除了我以外没人会做这么没有创意的梦。可我们得让我们的工作在某些方面具备蚂蚁牵大象的效果。

上一篇文章说到，为了准确快速的建立业务用例模型，我们需要找到入手点，而入手点就是用户当前系统所服务的对象，或者说是他们的顾客。

将顾客作为入手点有以下几个好处：

1. 准确分割系统内、系统外——将繁杂的业务职责封装在用例内部，作为系统的功能实现。

2. 快速捕获关键功能。

3. 降低业务用例之间的耦合性。

由此，我们便快速的建立了用户当前系统的功能提纲。

那么，在用例图中，各式各样的顾客到底是什么——正如大家猜测的那样，顾客就是触发用例的Actor。

无论是业务用例还是系统用例，Actor必须是所研究的系统之外的存在。他们触发了系统的某个或某些功能——正如用户不容易获得信息系统的源代码一样，功能的实现对他们来讲是不可见的。

Actor只需要明白能够使用系统的哪些功能、以及系统的哪些功能是对一些Actor开放的，而不对另外一些Actor开放。

将话题转回业务用例，我们以比较简单的例子来讲述一下业务用例的分析过程。

A顾客购买一支圆珠笔。

Actor是顾客，业务用例是购买圆珠笔。

还是A顾客，购买一支钢笔。

Actor是顾客，业务用例是购买钢笔。

大家都能看到，一个Actor触发的两个业务用例有相似的地方——购买。购买这个动词体现了用户（可能是某个超市）当前系统（就是超市）的一个主要业务功能——能够让顾客购买物品。而这两个业务用例又有一些区别——一个是购买圆珠笔，一个是购买钢笔——区别在于宾语的不同。

分析的现实意义就是找到区别，并抽象区别。

让我们来看看圆珠笔和钢笔的联系和区别。首先，圆珠笔和钢笔是超市提供给顾客购买的，也就是说，圆珠笔和钢笔不仅仅与顾客有联系（购买），还与系统有联系——超市有圆珠笔和钢笔，顾客才能买圆珠笔和钢笔，也就是说，如果超市不提供圆珠笔和钢笔，那么这两个业务用例就是不存在的。所以，圆珠笔和钢笔也是系统所提供的服务的一部分——很重要，它们是系统的内部存在。这是指，它们被系统维护，又被系统使用，它们构成了业务对象，对业务对象的抽象，成为业务实体。

再继续，圆珠笔和钢笔作为系统内部向顾客提供的两个物品，在仓储、会计明细等等方面又得分别维护。而无论你想到它们的哪些不同——当然是得在合理的层面上畅想，你都会发现，原来圆珠笔和钢笔的区别都建立于超市的内部管理。多数顾客可能不了解超市内部如何管理商品，顾客只是期望购买到想买的商品。由于钢笔和圆珠笔是系统内部的存在，那么它们不能被作为区分用例的因素。

所以，针对这个简单的现实情景，有一个Actor，是顾客，只有一个用例，是购买商品。

有些善于思考的人会问：“一般用户都会把用例叫做销售商品，而不是购买商品。”在文字上较真的确是耗时耗力不讨好的窝囊事儿。咱们现在谈谈这个窝囊事儿，不过目的不是为了确定用例的命名规则，而是阐述一种分析思路。那么，让我们看看销售商品和购买商品的区别。

从动作的发起方来看，销售商品好象是销售部的一个工作职责；购买商品应该是顾客的一种行为——这种行为体现了系统向用户提供的一种“概念笼统”的服务。

销售商品与购买商品相比较，销售商品更像是业务流程中的一个业务点。业务流程是系统实现的逻辑流向，流程中的业务点可能在功能实现的过程中负责修改状态。

用例封装了流程，而不体现业务点。

购买商品用例可能包括了供货、报库存、商品上架、收钱、记录会计帐目等等一系列的业务点，这些业务点形成了一个针对Actor的流程。这里要清醒的看到三个汉字和一个单词“针对”“Actor “的”。在介绍业务用例分析的时候，我不会说更多的关于流程的意见。但在这里，大家应该有个印象——流程是有针对性的。

无论是系统用例还是业务用例，当一个或一组相关的流程作为一个整体的服务提供给用户的时候，它们才能作为一个用例。

说到这里，让我们跳出有关销售商品和购买商品的“文字分析”，如果大家的理解一致，叫什么都无所谓——当然，最重要的是理解一致。

看过上面的文字，让我们将购买圆珠笔的情景弄的复杂一些：

顾客购买圆珠笔，如果顾客是会员，则打1折销售，如果顾客不是会员，则按照市场价格的10倍销售。

虽然从语法上讲有了条件分支，但精明的读者肯定明白：“哦，玩来玩去，用例还是只有一个，叫购买商品。”没错，对顾客是否是会员的判断，建立于超市内部，是功能的实现，而非另外的用例。

其实，这个情景反映了一个“业务规则”——无论它是否变态——在实现购买商品的时候，必须遵循这个业务规则。

业务规则是功能实现的算法，它是实现功能的重要参照物，但由于它属于系统内部，所以不能被体现在用例上——却被包含在用例里。

通过上面的文字，我们能够知道，用例是对系统功能的封装，具体来讲，它至少封装了业务实体、业务流程、业务规则。

不要被我耍了，也不要思考太多，毕竟我们只是在研究最简单的用例，还有，至关重要的——我们要在一天内确定所有业务用例。

无论用例封装了什么，它们仅仅是用例里面的东西，我们才不愿意让大好的时光浪费在非常深入细致的、针对用户功能是如何实现的讨论中呢。不能说这么做没意义，但意义的确非常渺小。

由于用例封装了功能实现，所以功能实现在目前的阶段是不可见的。还是由于用例封装了功能实现，那么我们可以通过分析一个个的用例，深入的研究如何实现功能。由此，我们得到了一个个巨大的石头：

从最简单的系统外部存在，找到了用例，我们清晰的知道，通过逐个的分析用例，我们能够知道我们想知道的一切——我们得到了我们想要的：——功能提纲。

甚至，我们会惊讶的发现，原来出产的用例图是如此的简洁：

1. 基于系统外部存在获得用例，用例之间的耦合程度很小。

2. 清楚的知道用例封装了流程，那么用例之间几乎不会存在明显的先后顺序。

3. 对Actor的恰当分类，不会造成过多的线条交叉。

4. 我们不需要在用例层面上对用例本身进行抽象，因为它们之间的联系非常简单。

在这里，为了让大家不致于产生误解，我提醒一下。用例之间可能存在前后顺序，但顺序不是用例本身造成的，而是由业务实体的状态限制的。更多的解释请等待我写完业务流程部分。

既然我们有了功能提纲，我们为什么不为提纲编上序号以方便查找？既然功能内部存在大量的详细实现，我们为什么不以功能序号作为查询条件，去查找实现这些功能的详细信息呢？

还是那句话，通过逐个的分析用例，我们能够知道我们想知道的一切。

蚂蚁开始行动，大象要露面啦～