用例分析技术小记（3）--归档用例

 

     当要决定去做一个项目的时候，就应该完成项目初始阶段的项目描述，风险分析，用例图，执行者和用例描述以及项目建议等等工作（项目建议其实就是概括了这个项目大体需要做成什么样子）。这时对项目的总体应该有个较为清晰的认识。那么接下来的工作就是需要给文档添加更多细节方面的东西。在细化阶段我们需要完善项目的需求文档，项目的体系结构，以及一个项目计划，对于一些较为复杂和较难解决的部分可以创建一些原型来帮助我们制定更加详细和准确的需求，计划。

      在细化需求文档时我们要做的主要工作其实就是细化用例。一个合理的用例他应该包括：前置条件，后置条件，事件流。

      前置条件表示用例在开始时系统必须处在什么状态，后置条件表示在用例结束时系统必须处在什么状态，另外不管紧随用例之后的是哪个分支或者选择，后置条件必须为真。

例子：

       事件流从执行者的角度来看就是一系列的陈述句，他告诉了我们要做一件事情的各个步骤，以及在这些步骤中可能出现的分支情况。

       在具体的去写这些用例的时候我们不可能一次性的做到面面俱到，通常我们应该先是只理清楚用例中事件流的正常情况，这些正常情况被我们看成是最理想的一种情况，即系统不会出现任何意外，执行者也不会出任何差错，一切都是那么的完美，并且这种正常情况也同时应该是经常出现的较为通用的一种情况。在理清楚正常的情况后接下来要做的就是逐步的分析正常情况，找出其中可能出现的分支，可选，异常的情况，通常我们将这些情况和正常情况区分开来写，我们将正常情况写在事件流的基本路径里，将其他可能出现的分支，可选，异常情况写在可选路径里。在可选路径里如果有用到基本路径里的步骤，我们可以直接将基本路径的标号拿过来用，个人目前采用的一种事件流的表现形式如下：

顺便提一下，

一个找出可选路径的方法就是沿着基本的路径一条一条的找，并且考虑：

在这个点上还可以执行别的活动吗？

在这个点上有没有什么可能出错的？

有什么随时可能发生的行为吗？

另一种方法就是用一下大类去发现可选路径。例如：

执行者退出应用程序；

执行者取消指定的操作；

执行者请求指定的帮助；

执行者提供了“坏”数据；

执行者提供了不完整数据；

执行者选择了一个执行用例的可选方法；

系统崩溃，系统不可用。

每个可选路径需要一个名字或者简要的描述。

场景：

    每一个场景描述了贯穿用例的一条路径，如果把用例的所有场景合在一起，你就得到了完整的用例，每个场景代表用例的一个实例。

    举个例子来说，大多数人都有过去银行取钱的经历，对与取钱这件事情我们从执行者的角度来看他就是一件执行者需要去做的事情，我们将这件事情写成一个取钱的用例，单是别忘了我们可以去银行的营业厅取钱，也可以去ATM机取钱，这两种取钱的方式是平行的，谁也不能包括谁，在用例里都是可以体现为一条贯穿用例的路径，这时去营业厅取钱和去ATM机取钱就是取钱这个用例中的两个场景。那么我取钱时出现的类似于账户里的钱不够了或者ATM机里没有现金了这两种情况能算是场景吗？答案是否定的，这两种情况应该是我取款过程中出现的一种分支，并且不正确的到达取款事件流的终端，所以我们以一种可选的条件来考虑他们。场景与可选条件的最大区别就是场景是描述了贯穿用例的一条路径，他会执行到用例的终端，而可选条件要么是需要用例重新执行，要么就是终止用例的执行，并不能到达用例的终端。

 

添加通信关联的指向：

    在完成用例的过程中还有件事要佐的就是添加用例图的通信指向，我们需要知道是谁开始执行用例，执行者、系统或者两者都有。例子：

 

    完成这些工作后，用例的基本形式已经出来，不过我们还需要不断的完善用例，将我们头脑里的想法，将我们得出的结论全部的反应在文档里。