张老师：您好。

我读过您的几篇关于用例的文章，深受启发，尤其是评Jacobson博士的《用例的昨天，今天，明天》以及《统一用例方法》。

有个问题想请教您的是，在目前应用最多的技术应该是Jacobson方法以及cockburn方法了。那么除了这两种方法之外，当前还有没有其它比较有价值的方法呢？

还有就是，作为一个用例的初学者应该怎么对待这两种方法呢？

在实践中，到底哪种方法更有效呢？从资料及评论上来看，好像cockburn方法的推崇者好像在增加。

在《用例建模》中，在用例描述中作者加入了本质用例的内容，单只是一提，不知道您对在jackbson的方法中加入本质用例，包括“会话式”，有什么看法呢？本质用例是通过“用户意图”和“系统响应”来表示的。那么在实际中我认为肯定需要进行详细描述吧？本质用例又是怎么做的呢？

望不吝赐教。

小马

小马，您好！

J、C 方法已经具有很高的价值。但我认为今后比较有价值的用例方法，应该是能够统一 J、C 方法的各自优点，弥补其不足，并且继续向前发展的新方法和新技术，包括我的 UUCM （网络上只公布了少部分内容）

:-)

为此，我会专门写一本关于《统一用例方法》的书，并且正在开发一种新的用例工具 UUCM Tool。现在在做统一用例工作这件事的人，应该不只张恂一个。

作为初学者，可以选用 J、C 当中的任意一种方法的经典著作，认真阅读和学习，作为起步。应该先熟练地掌握其中一种，然后，如果希望深入研究和掌握用例技术的话，再学习其他不同的方法，包括 Jacobson 和 Cockburn 流派的高级技术，以及 UUCM（UUCM 是 J、C 方法的继承和发展）。

在实践中，如果你深入运用的话，会发现两者都存在一些问题，这时候就需要仔细甄别和选择，如果两者都解决不了的，就需要我们自己提出改进措施。所以，两者的结合更有效。

我感觉，总体上看 C 方法只是 J 方法的一个补充，而 J 方法和 RUP 结合在一起，还有业务用例、业务建模的结合部分，用例驱动软件开发的部分，等等 ... 因而 J 方法更加全面。你可以在我的网站上看到，有关 J 方法的书也是最多的，好像支持这一派的专家也比 C 方法多。

当然，C 方法也很简便、实用、有效，我本人也很喜欢 Cockburn 方法，因此我才会想到开发一种把几种主流方法结合在一起的用例工具。

在什么地方，有的方法不行，存在缺陷，这要看具体情况。我在 UUCM 中写到的那些问题，有一些是双方共有的缺陷和不足。

Jacobson 与 Cockburn 方法，各有所长，两者实际上没有本质的差别。具体哪个采用的数量多，我估计差不多吧，都很不错。

Larry Constantine 的 Essential Use Case（核心用例）这本书出得比较早（1999 年），我发现 Cockburn 和 Kurt Bittner 等人的方法其实已经吸收了 EUC 的长处，包括“用户意图”，在 Cockburn 的书中已经反映出来了，Jacobson 和 Cockburn 方法的用例其实也都是 essential use cases，而且比 EUC 更完善，所以我就在文章中没有花很多的笔墨来探讨 EUC。

EUC 主要用在驱动 UI 的设计，是用例驱动 UI 设计的经典名著。但 EUC 只管发生在用户界面边界上的事，不管系统后台发生的事，所以我觉得它不如前两者重要。当然，对 EUC 我研究的还不够深入。如果你有兴趣，可以作一下对比研究。关于这部分内容，将来我会补充到 UUCM 中。

对于 EUC 两列式的用例表格，我不推荐，不紧凑，有点浪费空间。

你有没有读过 EUC 的书《Software for Use》？具体怎么做上面有详细的介绍。

张恂

有学员问：

是否可以在设计 Use Case 之前先与用户沟通，描述 User Story？

User Story 不是一种比 Use Case 更直接的方法吗？那么网络上大家都在讨论的 User Story 与 Use Case 的区别，是不是没有任何意义？

与用户沟通也可以直接用 Use Case。

当然，在实际操作时，如果客户、用户不了解、不喜欢用例技术，软件人员可以不用告诉客户这是用例，可以从最原始、最简单的需求描述开始，逐步引导用户、客户来完成用例的收集、填写。在许多情况下，用户可以用他们最熟悉的方式来编写需求（素材），而根本不用知道用例的存在，由开发人员把用户的需求素材（RUP 中好像叫做 Stakeholder Requests）改编成正规的用例，用来驱动真实的软件开发流程。用例技术主要是给软件专业开发人员使用的。当然，国内外也有报道，行业客户、用户经过培训后，也有不少人称为了用例专家。

按照我的 UUCM 研究，采用用例方法可以完全取代用户故事方法。用例是比用户故事更完善、更完备的方法，可以完全取代用户故事的作用。采用了用例，就没有必要采用用户故事了。这是合并同类项的结果。

即便你们已经采用了用户故事，如果要增加需求的完整性和精度，可以在用户故事的基础上再引入用例技术，两者并不矛盾。

UUCM 的目标之一就是要把用例、特性、用户故事等技术整合统一起来。

有学员问：

原先锯木头要 3 个月，现在发明了一种锯木头机器只需 1 个月，但是学习机器的使用要 1 年，这样的代价是否值得？

学习用例其实是非常重要的。用例（或者相关的 Scenario、协议和契约等）技术是目前唯一的详细描述软件动态行为需求的技术。用例可以把特性、用户故事、情节等方法整合起来。

只有写到用例这一层的需求，才是真正的软件需求。软件需求必须是可测试、可验证的。可以这么说，不会写用例（或类似的等价物），就不会写软件需求（因为你的需求是不完整的，还存在于大脑中，或是未知的）。

你提到的锯木头的比喻，很有意思。如何取舍，事实上要看情况而定，答案和你的 Context 有关。如果你要据 10 批木头，每批 3 个月，那么你一共需要 30 个月。如果用新机器/新技术，虽然学习花去了 12 个月，但完成锯 10 批木头的任务只需 22个月，节省了 8 个月。当然，你也可以举出在短期内学习新技术不划算的情况，比方你只需要锯 1 批木头。最终，有一个从不划算到划算的临界点，这其实是一个数学应用题。

总之，学习一些关键的新技术，能大幅度或显著提高生产率和产品质量的战略技术，短期可能要花费一些成本和时间，但从长远来看，是非常合算的。UML、用例等技术就是这样一种战略技术。而且，这些技术并不难学，可以从很简单的应用学起。

What is a use case?

相关问题：

用例的组成
用例与特性（Feature）、用户故事（User Story）有何联系与区别？
什么是用例的粒度？
什么是用例驱动开发？
什么是功能需求？
什么是非功能需求？

在《Use Case Modeling》的第一章第一页，Kurtner 和 Spence 开门见山地写道（大意）：

用例代表了系统为其用角（Actors）所做的有价值的事情。用例不是功能（functions），也不是特性（features），它们不能被分解。每个用例都有一个名字和一段简述。用例的详细描述本质上是一些叙述（stories），说明了用户如何使用系统来完成他们认为重要的事情，以及系统做了些什么来满足这些需要。

张恂观点：
1）用例是一种粒度刚刚好的功能需求。什么是 functions，什么是 functional requirement，两者是不是一回事，容易把人搞晕；
2）本质上，用例也是一种特性，是系统功能特性的某种组合，然而反之不成立，也就是说系统的特性一般不是用例；
3）我们知道在 Cockburn 方法中，用例是可以分解的，有多个层次和不同的粒度。面对这种分歧，我们怎么办？

RUP 的定义

UML 的定义

Jacobson 的定义

Cockburn 的定义

我的用例定义：

用例是一种粒度刚刚好，反映了用户的真实目的（目标），并记录了为达到此目的（目标），用户与系统或多个干系者之间如何开展协作，从事了哪些动态交互行为的软件需求（表现形式）。

------

用例的英文是 Use Case。如果仅从字面上看，就是“使用情况”、“使用实例”、“使用案例”的意思，然而问题并没有如此简单，“用例”这个术语背后的真实含义到底是什么？

简而言之，用例是软件功能需求（functional requirements）的一种最佳（粒度刚刚好）表达方式。用例是可数的，软件/系统的功能需求可以用用例的集合来表示，用例的个数代表了软件的所有功能需求的个数。完全实现了一个软件的所有用例，也就完整实现了这个软件的功能需求。

回答“什么是用例？”这个问题，不能遗漏几个关键词：“名称”、“交互”、“动态行为”。

每一个用例都有一个用动词词组表示的名字。用例的这个名字/名称反映了用户真正的（有价值的）使用目标，比如“打印统计报告”。相比之下，“登录”是一项功能需求，却不是一个用例，显然没有哪个用户使用某个软件的真正目的是为了“登录”系统。

用例代表了用户与软件/系统之间的动态交互行为。用例的内容反映了为了达到使用目标，提供和实现用户价值，用户与软件系统开展交互式的动态行为。在此交互过程中，用户提供信息数据的输入，系统则负责完成信息数据的处理和结果输出。在用户和软件所组成的这样一个系统中，将随着用例步骤的执行发生若干消息流、事件流、动作流和状态的变迁。这就是一个用例所要描述的大致内容，一个最基本的用例概念模型。

What is a use case realization?

...

What is a business use case?

他们之间有哪些明显的分歧

...

又译场景