|
多数人从用例开始就走入了迷途，也许是用例图和数据流图的相似性导致人们把用例定义为简单的功能或者菜单项。不论原因是什么，这都是新手最容易犯的错误。
图 1 错误的方式：用例是菜单项或者功能
这幅图有什么错误？用最简单的定义，我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义，是不是所有的“用例”都是独立的有用的呢？
答案当然是不是，在这个例子中，用例表示了系统需要做的所有的事情，但是他们也描述了用户需要通过系统去做的一件单独的事情：定购。所有保留的元素都是这一个用例的备选支流，它们是在定购时可能发生的步骤。在只做一件有用的事情的地方，只应该有一个用例。图1就是一个功能分解的例子，或者“四轮马车”格式的例子――一个参与者在中间，周围是一圈用例。
这是一个常见的问题，为什么人们会陷入这个陷阱呢？我们有一个有对定购的内在需要，并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下，我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时，实际上会把问题复杂化。
问题在这里
用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情，它描述了系统在概念层次上做什么，使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。
再看看图1，现在问你自己，如果我从来没有定购过，我想通过系统查询定单的状态吗？这是不太可能的。或者如果我从来没有定购过，我想变更订单吗？不，也许不。通常这些东西只有当我订购过的时候才对我有用。然而，为了系统能够允许我订购，这些都是必要的。
把系统分解为越来越小的用例模糊了系统的真实目的，极端情况下，我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车，或许你会说这是辆汽车，你也知道零件们是有用的，但是你确实不能说明他们如何组装在一起。
当使用用例的时候，记住用例是考虑整个系统的一种方式，并且要组织成可管理的功能块，这些功能块完成一些有价值的事情。为了得到正确的用例集合，问你自己一个问题：“参与者实际上想使用系统做什么？”
如果你在想图1的改进后的版本是什么样的，图2展示了改进后的版本。
图 2一种更好，更加简单的方法: 合并功能以反映对参与者的真正价值
这一个用例包含了以前的图中所分解为用例的所有“功能”。你也许会问为什么这样做比较好，答案很简单：它关注于客户想要系统提供的价值，而不是我们在系统内部如何细分和构造的。如果把所有的功能分解成单独的用例，你将迫使客户（为系统付钱的人）把分解过的用例装配成一件对他们有意义的东西，以便理解系统所描述的是不是他们所想要的（即他们想为之付钱的）。
关注价值
很多小用例是常见的问题，尤其是在一个习惯于功能分解的团队中，他们的用例名称读起来就象是一个系统所执行的功能的列表，如“输入订单”、“审查订单”、“取消订单”、“履行订单”，这起先听起来也不是很坏，但不仅仅这些。即使对于一个小规模的订购系统，用例列表也很容易达到上百个，如果谁走到了这一步，他们不久就会淹死在用例的海洋中，尤其是当系统规模确实比较大时，在这种情况下，你最终也许会有几百个，甚至上前个用例。
这么做有什么错呢？
这些用例的价值将会被错过。用例的唯一目的是为参与者产生价值。在一定层次上能够输入订单也是某种有价值的事情，但是，如果这些订单从来不被履行，那还有价值吗？也许没有吧。
怎样输入订单、修改订单以及取消订单等等，所有这些事情都是与客户真正想要做的事情有关的，那就是接受订购的货物。这些活动对公司想要的事情是必须的，那就是收到货款。
这种看起来是支离破碎的没有任何明显关系的功能集合的另一个问题是导致难以使用的系统。很多系统跟这个很类似，它们只是一堆杂乱的特性。记住，用例帮助我们关注与什么是真正重要的，也就是具有真正价值的事物，并且使我们能够围绕那些元素来定义系统。用例不要是系统按照功能分解的蓝图。
举例
考虑一个你在互联网上用过的一个电子商务系统，当你登录这个站点的时候，你的目标可能是查找产品相关的信息、选择要购买的产品、安排支付及送货约定。在做这些事的过程当中，你可能会改变主意、输入错误的信息以至不得不修改它、改变邮递或送货地址，以及其他的一些东西。如果这个网站不允许你通过一种吸引人的方式来找到并订购产品，你也许不会完成你的订购，更不用说再次来到这个网站。
当建造一个系统时，始终要记住用例的核心定义：关于采用某种方式使用系统来做有价值的事情的故事。如果你能够实施这个定义，展示用户希望通过系统获得的价值，然后创建反映这些价值的用例的时候，你的系统将会更好地满足用户的期望。 | 