用例图的构成

1 角色：人员角色——人、事；

角色不一定局限于人，还可以是事物、事儿

2用例：功能的描述；

每一个用例描述了一个完整的系统服务

3 系统边界

4 关系：执行者与用例之间的关系。

      泛化

      依赖

      关联

                    聚合，组合

      实现

 

从图中可以看书，角色，系统边界，用例和角色与用例间的关系。所有的用例都在系统边界内，表示它属于一个系统。角色则放在系统边界外面。表名角色并不属于系统，但是角色负责直接驱动与之关联的用例的执行。

1 角色 

通常用一个稻草人图符表示。

角色由用户承担。角色的存在是因为角色与系统具有交互行为。否则角色就不必要了。再次角色是一个类，而不是一个对象。因此可以引入类之间的继承关系。

角色之间的关系

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

2 用例

用例用来描述角色可以感受到的完整的功能，在UML规格文本中，用例被定义为“由系统执行的一个动作序列。并能产生可观察的结果值给某个特定的角色。

（1）    用例通常由某个角色来驱动执行。

（2）    用例把执行结果的值反馈给角色。

（3）    用例在功能上具有完整性。

图符表示为椭圆形

 

用例的主要属性

l  事件流

l  前置条件

l  后置条件

l  特殊要求

l  扩展点

l  问题说明

事件流描述一个用例在执行者与系统之间的交互过程，这个过程包含多个分支。包含

基本流

备选流

===================================================================================

用例之间的关系

l  包含关系  

  业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

l  泛化关系 

  子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

扩展关系

   系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行为。扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的

用例的粒度和范围

l  概述级

l  用户目标

l  子功能

用例的粒度，子功能抽象，成为复用的关系。

关系

n  泛化

n  依赖

n  关联

n  实现

具体的用例分析中，可能需要实际分析，期间的困难是难免的。这里就给大家实例一个例子。

下图是机房收费系统的具体用例图事例

 

 

                                                                                         作者信息见（网易博客 http://hanhan2010.blog.163.com/ ）