UML系列图——用例图

学习UML已经快一个月了，今天好好地看了一下UML中的9种图，今天就仔细的说一下用例图吧。

   用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

参与者

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

用例

是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。我们可以这样去理解，用例是参与者想要系统做的事情。

系统边界

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

箭头

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。

元素之间的关系

用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。

角色之间的关系

角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系

包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。在包含关系中箭头的方向是从基本用例到包含用例。

泛化关系：代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

 

用例图的主要属性

1、事件流：描述一个用例在执行时执行者与系统之间的交互过程。这个过程包含多个分支：（1）基本流：对用例中常规和预期路径的描述。（2）备选流：由于受到其他因素影响，用例执行了其他的路径。

2、前置条件：是该用例执行的前提条件，用来描述在什么条件下可以开始执行一个事件流。

3、后置条件：说明用例结束时系统的状态。

用例注意点：

1、应该清晰的定义系统边界

2、防止用例过多

3、应该从执行者的角度来命名用例

4、用例描述正规程度

5、避免执行者的名字不一致

6、避免执行者和用例之间的关系太复杂

7、注意用例的大小是否恰当

8、避免用例描述混乱

9、区分用例分解和功能分解

10、避免客户不能理解用例的情况发生

11、有些场合，用用例来描述需求是不适合的

下面是我自己画的机房收费系统的用例图，由于是第一次画，肯定会出现很多的错误，我会慢慢完善修正他的。