UML九种图之用例图

Ø 什么是用例图？

用来描述用户的需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。

u 详细定义

a) 用例图定义：由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图称为用例图。

b) 用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

c) 用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。

d) 将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。

e) 用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。

Ø 用例图的基本元素

用例图的构成（基本元素）：用例；角色；关系；

（1）用例（use case）：功能的描述

（2）角色（actor）：actor是一些人或事

--可以激活系统交互信息；

--可以对系统进行输入；

--可以从系统被动的接受信息。

角色：角色既可以是人也可以是物

寻找执行者的几个原则：

-谁使用系统的功能；

-谁需要系统支持日常工作；

-谁来维护关系系统；

-系统需要操纵那些硬件-需要与系统交互的其他系统；

-对系统产生的结果感兴趣的人或事物。

（3）关系（assosciation）：执行者与用例之间的关系，包括依赖、泛化、关联。用例和角色都可以有关系。

如下图：



其中：角色用一个小人表示，用例用一个椭圆表示，关系用一条带箭头的直线表示即可。

Ø 用例图之间的关系

关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系

u 用例之间的关系

三种关系：包含、泛化和扩展

² 包含关系

包含(include)： include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<<include>>)，箭头从基用例指向子用例。

举例：



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

² 泛化关系

泛化(generalization)：泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。

举例：

² 扩展关系

扩展(extend)： extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注<<extend>>)，箭头从子用例指向基用例。

举例：

停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend.

如图：

u 角色之间的关系

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

Ø 用例图主要属性

1 对用例的描述。

用例图：只能描述系统的大概功能，是一种视图。

用例描述：更详细地描述用例的功能。

2 用例描述的组成

用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。

事件流：就是用例执行时，由一序列活动组成的控制流。

基本事件流：对用例中常规、预期路径的描述。

扩展事件流：主要是对一些异常情况、选择分支进行描述。

前置条件：在用例启动时参与者（actor）与系统应置于什么状态。

后置条件：用例结束时系统应置于什么状态。

Ø 用例图的粒度和范围

不同的人画的用例图不同，如何判断谁的用例图更为合适，这就用到了粒度。

用例的粒度必须适中，不能过多也不能太少，分为以下三个级别

u 概述级

u 用户目标级

u 子功能级（更细的粒度）

Ø 用例注意点

应该清晰的定义系统边界

防止用力过多

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

用例描述正规程度

避免执行者的名字不一致

避免执行者与用例之间的关系太复杂

注意用例的大小是否恰当

避免用例描述混乱

区别用例分解和功能分解

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

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

以上是我对于用例图自己的一些理解，敬请期待下一篇类图。