用例图学习

最近写需求分析的时候要用用例图，这里找了一些资料记录下来
在做软件设计，特别是需求分析阶段，用例图必不可少。它是以用户身份进行的系统功能分析，能直观从用户角度来考虑系统的功能。从某种意义上说，是与用户交流的很好的工具，有时候用语言不能讲明白的事情，用use-case就很容易搞定。

一 用例图概述
     1.用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。 (《UML参考手册》)
     2.用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行(或称为发起了哪个用例)。
     3.用例图多用于静态建模阶段(主要是业务建模和需求建模)。

二 用例图中的事物及解释
     1.参与者（actor） 
              
   在系统外部与系统直接交互的人或事物(如另一个计算机系统或一些可运行的进程)。我们需要注意的是：

        (1)参与者是角色(role)而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。

        (2)参与者作为外部用户(而不是内部)与系统发生交互作用，是它的主要特征。

        (3)在后面的顺序图等中出现的“参与者”，与此概念相同，但具体指代的含义，视具体情况而定。


     2.用例(Use Case)
       系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达 。创建新用例，确认候选用例和划分用例范围的优秀法则----“WAVE”测试(稍后介绍)

三 用例图中的关系和解释（这里先做个预告，我会慢慢写好下面的所有内容）
     1.参与者与用例之间的关系——关联
         一条直线，表示参与者与用例发生关系，即这个用例的参与者。（这里暂时没有用图，以后补上）
   

     2.用例之间的关系——包含，扩展
         (1)扩展

箭头指向的用例为被扩展的用例，称为基用例；箭头出发的用例为扩展用例。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。
         (2)包含


箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。
     3.参与者之间的关系——泛化
         箭头所指一方为“一般方”，即所说的父方。箭头的发源端为“特殊方”，即子方。特殊一方继承了一般方的特性并增加了新的特性。

补充知识：
WAVE测试
1 What to do? (Not how to do.)
2 Actor’s point of view?
3 Value for the actor?
4 Entire flow of events?
WAVE测试
1 用例描述了系统应该做什么，而不是如何去做。
2 用例必须依据参与者的视点。(即应该从参与者如何使用系统的角度出发定义用例,而不是从系统自身的角度)。
3 用例必须为参与者提供可辨识的价值。
4 用例及其参与者必须捕获系统使用过程中的一个完整的事件流