1.说明

        关于用例图，这篇文章我将直接照搬罗伯特.C.马丁老爷子在《敏捷开发》一书种的第17章，并配上自己的理解，因为这一章写的实在是太精彩了，希望能够分享给大家，共勉。以下是老爷子的原文中文翻译以及豆芽的个人解读。

2.怎么看待用例

        用例的思路非常好，却被过度复杂化了。我总是看到一些开发团队围坐在一起，讨论用例该如何写。一般来说，这种团队更多的是在关注形式而非内容。他们在前置条件、后置条件、主参与者、辅助参与者以及一堆根本不重要的事情上争论不休。（豆芽解读：看到没有，老爷子一直是一个非常注重实践，任何复杂而无用的理论都应该丢到垃圾桶）。    

         使用用例真正的窍门就是保持用例简单。不要担心用例的格式；简单把它们写在空白纸、字处理器的空白页或空白的索引卡片上就行了。不要担心所有的细节。细节只有到了很后期才有用。不必为记录所有的用例而烦恼，因为那是一项不可能完成的任务。关于用例，有一点要牢记：明天，它们将会变化。不管你多么努力地记录它们，不管你在记录细节方面多么地一丝不苟，不管你考虑地多么全面，不管你在研究和分析需求上投入了多少精力：明天，它们都要变化。如果有些东西明天会变化，那么就不必在今天就记录下它的细节。事实上，你要做的就是把细节的记录推迟到最后一刻。可以请把用例看作是即时需求。(豆芽解读：敏捷开发面对的是变化，也就是需求的变化，用例同样无法固化，所以不要妄图用任何形式固化它。)

3.怎么写用例

        请注意本节的标题。我们是要写用例，而不是要画它们。用例不是图示。用例是从一个特定视角进行编写的关于行为需求的文本描述。

        “等等！”你喊道，“我知道UML中有用例图，我见过。”

        不错，UML中确实有用例图。不过从这些图中你根本看不出任何有关用例的内容。它们根本不包含任何关于行为需求的信息，而这正是用例该记录的内容。UML中的用例图记录的完全是其他一些东西。(豆芽解读：老爷子的这段话我个人感觉比较极端，虽然说用例图没有比文本描述要强上多少，但是老爷子说用例图完全没有用，我觉得还是过于极端了。主要他想表达的是用例图确实无法表示用例的实现细节，对测试和编码来说确实用处不大，但是对需求分析和系统设计而言还是具备一定的指导意义的。)

4.用例图有什么用

        我们下面来看看老爷子所说的用例图是不是那么没用。用例图至少有以下四个应用场景，即需求分析、 系统设计、 测试、 文档编写。我们先看下一个用例通过用例图和文本描述分别是什么样的。例如，下面是销售终端系统的一个典型用例，卖出商品的用例。

文本表示：

1. 收银员在扫描仪上划过商品，扫描仪读取UPC码。
2. 商品的价格、描述以及当前价格总数出现在朝向顾客的显示器上。价格和描述也出现在收银员的屏幕上。
3. 价格和描述打印在收银条上。
4. 系统发出可以听到的“确认”声以通知收银员UPC码正确读取。

用例图表示：

        额，这确如老爷子所说，我竟然不知道如果绘制以上文本描述的用例图。因为如果我用更详细的图示表示的话会发现文字还是更加直观且完整。

        用文本表示用例已经完成表示了用例的基本流程。不需要任何更复杂的东西。事实上，如果用例不是一会儿就要实现，那么即使是上面这几个简单的步骤可能也过于详细了。如果用例不需要在几天或者一周内就要实现，我们是不希望记录这种细节的。如果不记录下用例的细节，如何对它进行估算呢？你可以去问利益相关者有关细节的内容，不必把它记录下来。这会为你提供进行粗略估算所需要的信息。既然要去询问利益相关者一些细节方面的内容，为什么不把它们记录下来呢？因为明天，细节将会变化。难道变化不会影响到估算吗？会影响，不过对大量的用例来说，这些影响会相互抵消。过早记录下细节是完全不划算的。如果我们现在不记录用例的细节，那要记录什么呢？如果不写下一些东西，我们又如何得知存用例呢？记下用例的名称即可。在电子表格或者文档中保持用例名字的代码清单。更好的做法是，把用例的名称写在索引卡片上，保存在一起，等临近实现时再填入细节。

5.怎么画用例图

        虽然以上的大量篇幅看起来都在劝退各位不要使用用例图，但是我们还是需要教会大家怎么画用例图，因为当你评价一个事物前，首先要了解它，我说的。

        用例图中包括四种元素：参与者、用例、它们之间的关系、系统边界。关于参与者与用例的解析，详见下表：

系统边界，主要描述需要系统实现的功能集合，一般使用矩形框将系统边界标注出来。

各元素之前的关系如下

6.总结

你对用例的态度一定要保持这种简洁性。如果陷入用例复杂性的黑暗面，就会被它牢牢控制。运用原力，保持用例的简单化。

引用

《敏捷开发》——罗伯特.C.马丁

如何画用例图（UML） (baidu.com)