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

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

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

　　一、如何发现用例

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

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

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

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

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

　　二、什么才是有效用例

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

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

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

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

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

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

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

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

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

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

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