编写有效用例

        随着网站的发展，我们团队负责的网上论坛系统已经不堪重负，我们头决定重写该系统。由于这套系统以前没有写usecase文档，所以安排我根据目前网上的功能写出这套系统的usecase。

        以下是我在写usecase的时候自己的一些感想，我觉得写出来一个是留个记录，其二也算是一个总结笔记吧（做笔记是我的习惯）。
        一、UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。
         Use Cases本身是用户或其它系统与正在设计的系统的一个交互。这里我觉得要重点领会“功能”和“交互”这两个词。

          二、如何写好use case？
（1）写Use Case的时候，要把自己想象是一个用户进入这个系统，与系统交互，Use Case尽量少地提及UI，除非这个UI与功能有关。

（2）把握住系统的actor, 有哪些actor，系统提供哪些功能。
          actor 是独立于系统之外的；
          actor 是使用系统提供的功能。

（3）Use Case本身是高聚合的，Use Case之间应该是低耦合，也就是说描述一个Use Case的时候要集中描述这个Use Case的功能，不要把其他Use Case做的事情牵扯进来。
        重要的是保持每个用例粒度小，功能单一，不要把与该用例功能无关的东西也牵扯到该用例中。

（4）注重Use Case本身的描述，对Use Case之间的关系不必太关注。
        不要把重点放在用例之间的关系上（到底是包含还是扩展,泛化），这些无论对你的用例还是对于系统的了解，都无多大价值。

（5）如何描述Use Case的一个步骤？
明确句子的主语，体现出交互，同时要把握好“度”。
比如下面的话，有三种描述。
    a.用户输入信息
    b.用户输入用户名和密码
    c.用户在编辑框输入用户名和密码
   很显然b是最恰当的。

（6）Use Case要明确开始和结束。

三、CRUD操作的问题
        CRUD操作是放在一个Use Case中作为分支路径，还是作为一个独立的usecase，我的看法是取决于这个CRUD逻辑上是否是比较复杂，如果逻辑上比较简单，放在一个usecase中会比较好，显得紧凑。

四、扩展事件流用在对一些异常情况、选择分支进行描述。
       当有条件判断的时候，表述上采用系统检验到...，不要使用“如果”等字词。
        同时选择一个条件分支作为Use Case的主路径，其他的条件分支放在扩展事件流中。