采用用例技术

    用例技术保持了需求的简单原则，用例和形式和用户故事非常的相似，但是用例具有自己的格式，虽然这个格式也是可以任意定义的。用例的重点是表示系统的行为。我们看看上面的例子如何用用例来表示：
   
    主要角色：业务人员
    层次：业务流程级别
    前置条件：收到汇款
    基本流程：
    1 业务人员选择汇入汇款业务。
    2 业务人员输入必要的汇款相关信息。
    3 业务人员将汇款转入收款人帐户。
        3.1 如果收款人为本银行帐户，直接入帐。
        3.2 如果收款人为同城同业（本地的其他银行），则通过同城同业转汇给收款人（后续如何处理？）
        3.3 如果收款人帐户属于异地同业（异地的其他银行），则通过银行的帐户行将汇款转汇至异地，并支付帐户行转汇的费用（后续如何处理？）。
    备选流程
    暂缺
 

    可以看到，用例表示的内容和用户故事并没有太大的差别，但用例比较强调格式。虽然不同的团队有不同的格式，但是在同一个团队中，尽可能使用相同和相似的格式（不同的用例可能需要不同的用例格式）基本流程中的每一个步骤都代表了业务人员和系统一次交互，流程非常的简单，但是已经覆盖了一个成功的流程。我们看到，流程的每一步都高度抽象的原因是该用例的层次是业务流程级别的。（业务流程级别也仅仅是一种约定，并不是标准）。利用层次的概念对用例进行精度的划分。在上面的例子中，低精度的用例主要的目标是把握系统的全貌。在RUP中，这种用例也被称为业务用例（Business Use Case）。在原先的用户故事中，对分支情况描述比较含糊，但采用了用例的这种描述形式，分支情况就一目了然了，和前面一样，分支情况的表述也有很多种的形式。

    用例技术从提出到现在，已经有了大量的经验积累。在XP项目中采用用例技术并不是什么新鲜事。但在XP中应用用例也必须遵循XP的原则，以及精益编程的思路。所幸的是，这些思路是非常自然的，使用用例技术是完全可以实现的。本文并不打算详细的描述用例技术，如果要深入了解用例技术，有几本书是非常值得一看的（见附录）。

    先把握系统的全貌：在做需求的时候，常常出现的一种情况是需求分析人员花费了很多的心思来精华、完善某个用例。对XP来说，这种做法并不推荐，而根据精益原则，这种行为存在浪费的可能性。我们对软件、对项目的认识是不断深入的。因此，我们在项目一开始就深入到需求、故事、或用例的细节，分析人员的能力可能很强，能够正确的捕捉到用户的实际需要。但是一个星期之后我们对需求的认识就有可能发生变化，也许是原先对用例范围的界定出现了问题，也许从另一个角度分析用例效果会更好，也许原先处理用例的思路不正确。不管如何，需求变化的可能性是非常大。用例越详细，发生变化的可能性就越大。这时候，原先花在精化用例上的时间就被浪费了。

    因此，不要在一开始就精化需求，一开始的工作重点应该是放在尽可能全面的收集用例，了解整体的业务流程，分析主体业务流程等工作上。在获得了系统的全貌之后，你会发现你原先对系统的认识是不充分的，用例需要根据新的思路进行重新排列，用例的优先级需要调整，在UML图中，往往有一张系统的用例概览图，这张图所表示的就是系统行为的一个概述。
   
    寻找优先级高的用例进行精化：我们在上文提到了需求优先级的判断，用例的优先级判断和需求的优先级判断相似。在讨论迭代的时候我们说过，前几次迭代的主要目的是要识别出项目风险。因此，寻找有代表性、优先级高的用例进行精化，能够帮助开发人员更快的理解领域知识，构建起初步的领域模型。

    继续上面国际结算的例子，在完成总的用例图之后，我们发现，银行的业务非常的复杂，如果缺少领域专家，要在短时间内领会领域逻辑是非常困难的，同时，我们发现，汇款的业务在日常业务中所占的百分比是非常高的，而汇款业务涉及到了大多数的领域知识，而业务流程却相对简单。因此，我们决定，先把汇款的用例作为一个突破口，在完成了这个用例之后，我们的开发人员就会对业务领域有着比较深入的认识，也就能够进行更复杂的工作了：

    主要角色：业务人员
    层次：业务流程级别
    前置条件：收到汇款
    基本流程：
    1 业务人员选择汇入汇款业务。
    2 业务人员输入必要的汇款相关信息。
    3 业务人员将汇款转入收款人帐户。
        3.1 如果收款人为本银行帐户，直接入帐。
        3.2 如果收款人为同城同业（本地的其他银行），则通过同城同业转汇给收款人（后续如何处理？）
        3.3 如果收款人帐户属于异地同业（异地的其他银行），则通过银行的帐户行将汇款转汇至异地，并支付帐户行转汇的费用（后续如何处理？）。

    备选流程
    2．A在任何时候，业务人员都可以应客户的要求对向汇款银行进行查询。
    2．A1在收到汇款银行的查询答复之后，记录答复信息。
    2．B在任何时候，业务人员收到汇款银行要求退回汇款的授权。
    2．B1如果汇款未被提走，根据要求将汇款退回汇款银行。
    2．B2如果汇款已被提走，通知汇款银行无法处理，用例结束。
 

    注意到，在这个例子中我们对用例优先级的判定条件和上文的稍有不同，我们选择有代表性，但又相对简单的用例作为高优先级的用例。这样做是因为对业务领域比较陌生，一开始实现复杂的需求有很大的难度。所以，虽然我们提供了一些制定用例优先级的思路，但是实践的时候仍需要根据实际情况权衡。

    迭代精化：用例的编写过程是一个对业务领域不断熟悉的过程。随着调研的深入，不断有新的问题显露出来，需要补充或修改原先的用例。这里有两种情况，一种是在同一个增量内，在对用例B精化的时候，发现用例A中忽略了一种情况，这时候我们就需要补充用例A。例如，我们在精化其它用例的时候，发现汇款用例中忽略了报表的需求，这样我们的工作又必须回到汇款用例上。这样的情况是非常普遍的，这就要求我们不要过分的修饰用例，不要把精力花在用例格式上，这样只会造成浪费。

    第二种情况是在不同的增量中，这时候用例往往会加入新的需求、新的情境。我们如何去控制不同增量期间的迭代呢？一般来说，有两种方法，一种是对原有的用例进行增补，增补的部分用不同的颜色或标记。另一种方法是为用例建立版本，不同版本的用例对应于不同的增量周期。这样，对应对N个增量周期就有了n个不同版本的用例（n≤N）。不管是哪一种情况，都要求我们采用迭代的思路来处理用例。

    形式不是最重要的：在团队中强制要求统一的用例书写格式是有意义的，但有的时候，这个意义并没有想象中的那么大。可以约定条件的编写形式、也可以约定层次的划分。但是过分的强制形式就没有什么意义了。