前面我们讲了如何建立用例模型，那么建立用例模型应当注意什么呢？

建立用例模型应当注意的问题

给大家几个建立用例模型中常出现的问题和应对遵循的原则：

一．如何发现用例

经过以上的讲解，相信大家对建立用例模型有了一个整体的概念，然后开始着手练习绘制用例模型。这时候，一个非常严峻的问题出现了：如何发现用例。大师曾经给出了答案，大致意思就是：首先选择系统边界，然后确定主要参与者，定义满足用户目标的用例，为其命名。然而，我在实践中证明，这套方法过于理论，并不实用。也许，我们换一种思路会更加符合实际。

当我们开始一个项目的需求分析时，肯定是去听客户谈他们的需求，或者看客户提交的业务需求文档。这其中，客户一定会提出一个又一个的功能或要求，他们中的每一个就成为了我们最初的用例。分析这些用例，关注它们每一个的参与者，以及它们相互之间的关系，这就形成了最初的用例模型。这里特别应当提醒大家的是，我们采用用例分析的方式与客户沟通需求的时候，我们应当着重关注的是参与者及其目标，即每个功能的参与者是谁，完成这个功能的目标是什么，以及如何完成这个目标。这时的用例说明采用概述的方式，即只进行主成功场景（基本流程）的描述。

此后，我们继续与客户沟通，一方面，继续细化以后的用例，各个用例的替代场景（分支流程）逐渐被整理出来，用例在一步步细化。同时，我们对一些需求的认识一开始可能存在着偏差，因此我们还不断在更正我们的用例描述。另一方面，一些新的功能被用户提出来，形成一些新的用例。

如此反复数轮之后，项目需求的整体框架逐渐清晰，这时候我们开始讨论系统边界。这是，我们需要对我们的用例模型进行一次调整。我们开始考虑哪些系统以外的系统与我们的系统相关，而另一些用例则由于不在系统边界之内而被剔除。

如此迭代数次，才最终形成我们需要的用例模型。

二．什么才是有效用例

在你与客户沟通的过程中，客户会提出许多的需求，也就是提出许多对你要实现的这个系统的期望。但是，并不是所有这是都能有效地形成用例。哪些是有效用例，依然有一个评判的标准，我们通常采用三种测试的方法进行评判：老板测试、EBP测试、规模测试。

1．老板测试。如果老板问你“整天都在做什么”，而你的回答是：“登陆系统”，这显然不能让老板高兴，因为你的回答不具有可量化的价值。不具有可量化的价值就是不具有提高工作效率、产生有价值结果的操作，即该操作对老板来说没有价值。如果你写的用例不具有可量化的价值，则不能通过老板测试，也就不是一个有效用例。老板测试是最低级别的用例有效性测试。

2．EBP测试（Elementary Business Process），它的定义如下：

一个人于某个时间某个地点，为响应业务事件所执行的任务，如果能增加可量化的业务价值，并且以持久状态保留下数据，则可以通过EBP测试。

EBP测试用一种更加精确的方式量化了用例的有效性。它除了要求进行有价值的业务操作以外，还必须产生有价值的、持续保留的数据。同时，它还要求了完成这个任务的时效性，即必须在一个会话中完成。持续数日或跨越多个会话的用例都不能通过这个测试。

3．规模测试，即一个用例必须达到一定的规模才能算有效。必须达到什么样的规模呢？通常必须包含多个步骤，在详述形式的用例说明通常会持续数页。不能通过规模测试的一个典型错误，就是将一系统步骤中的一个作为用例。

一般来说，必须通过以上三个测试才能算是有效用例，但是也存在着例外。譬如，有些为了提高复用性而从用例中提取出来的子用例或扩展用例，可能不能通过EBP测试或规模测试，但它们依然是有效用例。另一个特例就是“认证用户”用例，它可能不能通过老板测试，却依然是有效的。

三．用例模型的核心是文字，而不是图形

如题，用例模型的重点是用例说明而不是用例图。建立用例模型的时候，绘制用例图可能只花费几十分钟，而编写用例说明却得花费你数小时甚至数天。用例图只是给人最直观的展示，而用例说明才是对业务需求最详尽的说明。

四．以黑盒的方式编写用例

黑盒用例（black-box use case），是指以职责来描述用例，而不对系统内部的工作、构建或设计进行描述。它体现了OOD/A的一个重要思想——封装性，隐喻了OOD/A的一个主题——软件元素具有职责。因此，黑盒用例是最值得推荐的一种用例编写方式。

五．以参与者和参与者目标的视点编写用例

用例的创立者Ivar Jacobson是这样定义用例的：用例的执行应当产生“对特定参与者具有价值的可观察结果”。在Jacobson的定义中传达的一个重要信息就是，什么是对这个参与者有价值的。因此，用例分析的两个重要视点就是：关注参与者期望达到的目标，关注参与者认为有价值的结果。我们在编写用例说明的时候，就应当以这两个视点来进行编写。

六．不要描述任何用户界面

这是一些人（包括我）常犯的错。“点击××按钮”、“显示××列表”都是不应当出现在用例描述的文字中的。界面设计应当交给原型设计或界面设计阶段完成，而不是用例设计阶段。用例分析应当摒除用户界面的思考，而将全部精力关注于参与者的意图。

七．再谈谈采用迭代的方式构建用例

在本文中，我已经反复强调了采用迭代的方式构建用例。迭代是RUP以及后来的敏捷开发所大力提倡的一种开发方式，它从理论上彻底打破了过去的瀑布式开发理论。迭代开发包含了以下几个思想：

1．从整体逐渐细化的过程。人类认识事物总是从整体到局部逐渐细化的一个过程，而迭代开发也体现了这一客观规律。在需求分析的初期，我们总是将系统分为几个大的用例，为每个大的用例，绘制几个最主要的用例出来。而对于每个用例的说明，采用概述的方式，仅仅写出主成功场景。然后，随着一次一次的迭代，我们在不断丰富我们的用例，而用例说明的方式也渐渐变为非正式的方式，最终改为详尽的方式，写出完整的用例图和用例说明。

2．将大段的开发进程划分成了无数小的阶段。一次软件开发项目往往持续数月，甚至超过一年。而需求分析，也常常持续数月。许多项目开发团队不能按时完成开发任务，或者不能从容地完成开发任务，一个非常重要的原因就是，在项目执行过程中，并没有随时评估自己的进度是否走在正常轨道上，也就没有及时将偏离的进度拉回到正常的轨道上来。人造卫星和宇航飞机能够随时矫正自己的轨道，是因为它们在定期检测自己是否偏离轨道，项目管理也同样需要。如何定期检测项目进度是否在正常轨道呢？答案是迭代。迭代将持续数月的需求分析划分成了为期1～2周的一个个迭代期。每个迭代期在项目计划时都有一个目标，即该迭代期完成是项目应当进展到什么程度。在项目执行过程中，每个迭代期都要进行计划、执行、总结三个阶段的工作（如果迭代期为1周，通常是周一做计划，然后开始执行，直到周五开始总结）。在进行总结时，对比该迭代期应当完成的目标，就可以判断项目进度是否在正常轨道，从而进行必要的调整。

3．它强调的是与客户的反复沟通。按照敏捷开发的思想，业务变更是无所不在，正如那句经典的话：I changed when I saw it（当我看到软件时，需求就开始变更了）。瀑布式开发理论之所以失败，正是因为拒绝了这种与客户的沟通，武断地认为，需求确认以后就不能再变更，也就不再需要与客户继续进行沟通。按照敏捷开发的思想，每次与客户沟通，都应当将客户的意见体现到设计开发中。然而，在将客户的意见体现到设计开发以后，需要寻找一个合适的时候与客户进行反馈，让客户确认这样的设计是否符合他的要求。没有及时地与客户进行反馈，就不能保证项目的进展是否偏离了客户的需求。回到用例分析这个主题上，用例分析应当分成无数个迭代期，每个迭代期都应当包含与客户确认需求、进行用例分析、与客户进行反馈三个阶段。同时，用例分析还将持续到需求分析以后的整个项目开发过程中。

用例分析的总结

又到总结时间了，每到这个时刻我总是千言万语不知从何说起。我用了如此多的篇幅说明了什么是用例模型，它与需求规格说明书的区别以及优势。用例模型代表了先进的设计思想和方法，他可以完全替代需求规格说明书，但遗憾的是它至今还为我们所忽视（这也正是我写这篇文章的目的之一）。当然，你可能会说，许多客户依然要求我们编写需求规格说明书作为需求确认的指定文档。许多单位的质量管理手册也要求我们必须编写需求规格说明书，作为质量管理的一个部分。确实，需求规格说明书至今依然有大量fans，但我不得不替需求规格说明书说：不要迷恋哥，哥只是一个传说。说服客户和主管改用用例分析也许需要一定的时间，然而，采用需求分析过程是用例分析，最终结果写成需求规格说明书，不失是另一个曲线救国的方式吧。

后记

我从小到大读书有一个特点，就是不求甚解。一本书，特别是技术书籍，从来没有兴趣从头到尾把它读完过。即使感兴趣的章节，也从来不愿一字一句地去读。翻看目录是我主要干的事情。因为这样的读书方式，我小时候的成绩一定好不了，我却总是能去粗取精，把许多知识的精华握在胸中，跳出书本去思考许多更重要的东西。我看的书总是越看越薄，然后跳出来评判作者思想的得与失。正可谓：当局者迷，旁观者清。

我写这些文章的目的，就是帮你把书读薄，去粗取精，最后留下真正重要的问题与你讨论。在写作过程中，我会将整个文章分成了数个大章，数个小节。每个章节，我都通过简短的语言，说明我下面要说的内容。你不必一章一节地挨着看，只看你感兴趣的部分，不求甚解，这就是柳宗元先生给我们的最大启示。

参考文献

中文名：《UML和模式应用》

英文名：Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development

作者：（美） Craig Larman