UML学习笔记——用例图

---

用例图

UML中的用例图的相关知识。

用例图的概念

用例是一种*描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。

用例图的基本思想

用例图是从用户角度来描述系统功能的，只关心系统所能提供的服务，并不需要了解系统的内部结构和设计细节

用例图的作用

作为整个系统开发过程中的开发依据，指导和驱动其它模型。用例驱动的软件开发

用例图的构成

• 用例图用于定义系统的功能需求，描述了系统的参与者与系统提供的用例之间的连接关系。

用例图的构成元素

（1）参与者（Actor） （活动者、角色）

（2）用例（Use Case）

（3）关系（Relationship ）

（参与者与参与者之间的关系，参与者与用例之间的关系，用例之间的关系）

参与者

• 参与者（actor） 是系统外部与系统直接交互的事物，也称为活动者。

参与者参与用例的执行过程。

• 每个参与者可以参与一个或多个用例，每个用例可以被多个参与者使用。

• 参与者是由参与用例时所担当的角色来表示。

什么是参与者？

参与者的特征是其作为外部用户与系统发生交互。

参与者的种类

(1)与系统直接交互的真实的人

(2) 与系统直接交互的其它系统:与系统进行信息交换的计算机外部设备、数据库系统，其它软件系统等。

(3)一些可以运行的进程：时间(经过一段时间或到达某一个时间点，触发系统中某个事件时，时间就是参与者)

用例

用例是外部可见的系统功能单元，是对功能需求的描叙。

用例的名称:

①简单名

②路径名:指出用例所在的包

用例规约(Use Case Specification)

(用例描述、用例说明)

针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容，例如描述参与者与系统交互实现用例功能的事件流。

用例图的关系

关联（association）

包含（include）

扩展（extend）

泛化（generalization）

注意:

• 关联指参与者与用例之间的关系

• 包含、扩展、泛化指用例之间的关系

• 泛化即可以用于参与者之间的关系，也能用于用例之间的关系。

关联关系

• 表示参与者与用例之间进行通信。

• 每个用例都有参与者关联，除了包含和扩展用例。

• 一个参与者可以访问多个的用例，一个用例可以被多个参与者访问。

• 关联关系可以是单向的，也可以是双向的。

包含关系

• 一个用例可以包含其它用例具有的行为，并把它作为自身行为的一部分，称为包含依赖关系。

• 基用例把被包含的用例行为作为自身行为的一部分。

例如：

注意：

• 箭头方向由基用例指向被包含的用例，被包含用例如果不存在了，基用例就不完整了。

• 执行基用例时，每次都必须调用被包含的用例。

• 被包含的用例也可以单独执行。

使用包含关系的情形

• 如果两个以上用例有大量一致的功能，可以将一致的功能抽取到另一个用例中，其它用例和这个用例建立包含关系。------体现复用

• 一个用例的功能太多太复杂时，可以将功能分解成小功能小用例，然后使用包含关系。------功能分解

扩展关系

• 一个用例在一定条件下(扩展点)扩展另一个用例的功能，构成新用例，称为扩展用例，被扩展的用例称为基用例。

• 扩展用例被定义为基用例的增量

• 扩展用例依赖于基用例。

注意：

• 基用例本身是一个完整的用例，可以单独执行，在每次执行基用例时，扩展用例不是每次都被执行。

• 扩展用例本身不是完整独立的用例，无法单独执行，扩展用例的执行必须依赖于基础用例。

使用扩展用例的情形

UML提供了扩展点来为基用例扩展新的行为。

扩展点

扩展点的定义：基础用例中的一个或多个位置，在该位置会衡量某个条件以决定是否启用扩展用例。

• 一旦基用例中扩展点给出条件满足，则扩展用例将被执行。

• 一个用例可以有多个扩展点，每个扩展点也可以出现多次。

• 扩展关系为分支处理、异常处理、构建灵活的系统架构提供了一种非常有效的方法。

泛化关系

体现一般和特殊之间的关系。

用例之间可以泛化，参与者之间也可以泛化。

• 子用例表示父用例的特殊形式，通过插入额外的步骤或细节步骤，子用例特化父用例。

参与者间的泛化关系

• 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。

例如：

用例描述和建模过程

●用例图描述参与者和系统功能之间的关系，但是它缺乏描述系统行为的细节。

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

●用例描述常以书面文档的方式进行表达，可以使用 文本方式进行文字描述，也可以使用图形的方式可视化描述，例如活动图有助于描述复杂用例实现的决策流程，状态转移图有助于描述与状态相关的系统行为，顺序图适合于描述基于时间顺序的消息传递。

用例描述一般包含的方面

在UML中对用例的描述并没有硬性规定，但一般情况下用例描述

应包括以下几个方面:

用例名称

表明用例的用途，如上面示例中的“借阅图书”、“归还图书”，

标识符[可选]编号

惟一标识符一个用例，如“UC200601”。这样就可在项目的其他元素(如

类模型)中用它来引用这个用例。

参与者[可选]

与此用例相关的参与者列表。尽管这则信息包含在用例本身当中，但在没

有用例图时，它有助于增加对该用例的理解。

简要说明

对该用例进行说明，描述用例作用。注意语言简要，使用自然语言。

前置条件

一个条件列表。前置条件描述了用例之前系统必须满足的条件。如果条件不满足，则用例不会被执行。

例如:借阅图书用例

前置条件:学生出示的借书证必须是合法的借书证。

后置条件

后置条件在用例成功完成后得到满足，它提供了系统的部分描述。用例结束后，系统处于什么状态。

例如:借阅图书用例

后置条件:借书成功，则返回该学生借阅信息;结束失败，则返回失败的原因。

扩展点

如果包括扩展用例，则写出扩展用例在什么情况下使用。应该在编写事件流的同时编写。

基本事件流(主事件流)

描述当各项工作都正常进行时用例的工作方式。

事件流描述了用户和执行用例之间交互的每一步。.

事件流是将个别用例进行合适的细化任务。

可以发现原始用例图遗漏的内容。

其它事件流(扩展事件流，错误事件流)

在变更工作方式、出现异常或发生错误的情况下所遵循的步骤

例如：

用例建模过程

■捕获需求;

■确定系统的边界范围，找出系统外部的参与者和外部系统;

■确定每-一个参与者所希望的系统行为，命名用例;

■把公共系统行为分解为新用例，供其他用例引用;

■把一些变更的行为分解为扩展用例;

■编制用例的脚本;编写用例描述

■绘制用例图;

■把特殊情况的用例画成单独的子用例图。