作者：张洋

细节的泥沼

现在我们再次将特性列表贴过来：

1.可以将各种原料信息发布到系统上

2.加盟商和连锁店可以使用购物车功能在线定料

3.加盟商和连锁店通过网络进行注册，管理员审核后才可以正式使用系统

4.系统需要一个管理员，可以对系统进行管理

5.定料完成后生成定料单，并可以打印

6.直属连锁店按原价定料，加盟商按照等级分为5级，每级折扣不同

我们已经和这则列表折腾很久了，相信很多朋友已经厌倦了，肯定在想：不要在折腾这该死的特性列表了，赶快开始吧。这点我同意。但是要开始做什么？很多朋友可能会说：开始用例分析吧。说实话，用例是好东西，它让我们清晰认识到系统的工作流程，正式因为过于清晰，所以很容易让我们陷入一个细节的泥沼。

应该说，从“特性列表”直接到“用例分析”不是一个好注意，因为特性列表关注于功能（Function），而用例关注于系统的业务流（Business Flow），我们从功能直接开始分析系统的细节业务流，这个跨越太大，不利于软件质量的保证。特性是相对分散独立的功能描述，而用例是系统细节，很明显，在这之间应该有一个过渡，而这个过渡，就是一个高层次的，从全局角度对系统的一个概观认识。这个概观认识起到承上启下的作用，既将特性列表映射为一个系统的大概模型，又给系统细节的分析奠定了基础。所以，在系统特性基本确定后，我们首先要从全局给出一个系统的概览，避免落入用例分析这样细节的泥沼。

概览系统的有力工具——用例图

既然我们要给出一个全局的系统概览，自然就需要有一种方式将其表达出来。显然，仅仅通过说是不理想的，我们需要一种能用于书面表达的工具，而这个工具，就是我们非常熟悉的UML图之一的用例图。

很多朋友可能有疑问，上面不是说不进行用例分析吗？怎么这里又画用例图了？因为用例和用例图表述的信息层面完全不同，用例更倾向于细节和业务流的描述，而用例图倾向于整体的描述。下面给出两种工具要表述的信息：

用例——表述某个交互操作的动作执行者、用例名称、具体流程过程、例外情况等。

用例图——表述系统有哪些执行者、有哪些用例以及执行者于用例、用例于用例之间的关系。

很明显，用例更关注于某一个操作的具体流程，所以适合在需求分析中使用；而用例图更关注于整个系统的使用和交互情况，因此能给我们一个系统的概览。

下面，我们就使用用例图，从高层次角度看看系统的样子。在这里还要说明的是，随着UML和用例分析技术的发展，提出了业务用例和系统用例的区别，而且用例存在不同的粒度。在进行高层次概览的时候，我们是使用的是一种粒度比较粗的用例图。也许在以后的需求分析中，我们还会使用粒度更细的用例图。

通过简要对特性列表的分析，可以画出一张如下的用例图：

可以看到，这个用例图并没有太多细节的东西，而仅仅描述了三个信息：1.系统有哪些用户 2.系统有哪些操作 3.系统和用户有哪些交互。这些，就是我们要的一个系统概观。

用例图的验证

画完用例图，我们并不是就完事了。因为，要使得用例图真的是全局概观，就一定要保证一点：图中用例覆盖了所有特性。如果不能覆盖所有特性，说明我们的用例图中缺少用例甚至缺少动作执行者。现在我们来验证一下：

特性1覆盖于“原料管理”。

特性2覆盖于“在线定料”。

特性3覆盖于“注册”和“加盟商和连锁店管理”。

特性4覆盖于“原料管理”和“加盟商和连锁店管理”。

特性5覆盖于“打印定料单”。

特性6覆盖于...???

我们忽然发现一点，这里并没有和折扣有关的东西，那么这个特性没有被用例覆盖。我们知道，如果要实现这个特性，系统中一定要有一定的折扣机制，而一定是有管理员设置的。于是我们增加一个“折扣管理”用例。注意，这里我们可以先不陷入细节，仅仅知道系统有这么一个折扣机制，至于具体怎么实现，到分析设计阶段再讨论。于是，修改后的用例图如下：

现在我们可以说：特性6覆盖于“折扣管理”和“在线定料”。

好了，这样我们已经确认，用例图的用例覆盖所有特性。

重点总结

1.不要过早陷入细节

2.在特性列表到用例分析之间，用该先有一个系统概览，让我们从高层次上审视系统全貌。

3.用例图是实现这种概览的有效方式。

4.用例不要粒度过细，要能反应系统粗粒度操作。

5.最后不要忘了检查图中用例是否覆盖了所有特性。