软件工程需求分析_软件工程专题：UML用例图

关注BeTester，学习更多知识

让碎片成体系，让测试更专业

1、前言

当很多测试工程师谈及用例时，会默认 用例 = 测试用例 。但这是非常片面的理解，因为在软件工程领域，Use Case（用例）和 Test Case（测试用例）是完全不同的概念。

在《黑盒测试设计专题》及《测试用例专题》中我们对测试用例做了详细的讲解，那 Use Case 是什么，与 Use Case Diagram 有什么关系？本文将一一解答。

2、概述

当我们要弄清楚需求时，往往使用5W2H方法协助分析，其中Who和What的问题可以通过用例图来解决。

1. 这个系统谁在用？
2. 这些人通过这个系统能做什么？

5W2H又叫七问分析法，为发现解决问题的线索提供思路。通常的5W2H分别为：What/Who/When/Where/Why 和 How/How Much。

用例图（Use Case Diagram）是描述用例、参与者以及它们之间关系的图。

用例是 外部可见的系统功能，即用户可感知到的功能，文章下面讲到。

用例图是从用户的角度来描述对信息系统的需求，分析产品的功能和行为。

用例图是系统的蓝图，呈现参与者，用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

3、用例图元素

用例图有三个部分：参与者（Actor)、用例（Use Case) 和 关系。

3.1 参与者（Actor)

参与者是对系统使用者的抽象。参与者是与系统交互的人或另一个系统，如果是人可以称为“角色”。在分析系统时，应该先思考什么角色会用这个系统，然后逐一思考不同的角色对系统有什么需求。

在UML中，通常使用以下表示方法：

actor 测试工程师 as te

在UML中，参与者一般使用人形图案来表示，参与者不仅限于人，还可以是外部交互系统。

3.2 用例

用例是外部可见的系统功能，对系统提供的服务进行描述。用例通常使用动宾结构（动词+名词）来描述，如 编写测试用例、编写代码 等描述来说明用例。每个用例提供了一个或多个场景，该场景说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

在UML中，通常使用以下表示方法（括号）：

te --> (编写测试用例)

在UML中，用例使用一个椭圆形来表示，使用 (Use Case Name) 表示

3.3 关系

用例图中常用关系有：参与者的继承、关联、泛化、包含(include)、扩展(extend)。

关联(Association)：线条是指参与者与用例之间线条，有三种：无箭头，指向用例的箭头，指向执行者的箭头。一般来说，箭头的尾部用来表示启动交互的一方，头部用来表示被启动的一方。

3.3.1 包含

包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。表示符号：<< include >> 。通常用 基用例 表示包。

@startuml
(设计测试用例) --> (分析需求) : <<include>>
(设计测试用例) --> (分析测试点) : <<include>>
(设计测试用例) --> (建立模型) : <<include>>
(设计测试用例) --> (编写测试用例) : <<include>>
@enduml

3.3.2 泛化

子用例继承了父用例所有的结构、行为和关系，是父用例的一种特殊形式。

@startuml
actor 测试工程师 as te
te --> (执行测试用例)
(执行测试用例) <|-- (执行功能测试用例)
(执行测试用例) <|-- (执行性能测试用例)
@enduml

3.3.3 扩展

用一个用例（可选）扩展另一个用例（基本例）的功能，将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。表示符号：<< extend >>。

actor 测试工程师 as te
te --> (执行测试用例)
(执行测试用例) <.. (提交Bug) : <<extend>>

4、小结

用例图对于需求分析有着十分重要的意义，它能够通过包含、泛化、扩展的关系展示出需求的概览，让我们能够对需求有快速的认知，进而为后续所开展的更细致的分析活动提供参考。

用例图不是唯一提供需求分析的工具，但是它能够将我们所有的建模统一化、规范化，因此使用用例图是十分必要的。

—— 更多文章 ——

• 软件工程专题：UML类图
• 软件工程专题：Plant UML实践
• 软件工程专题：UML简介
• 软件工程专题：看板
• 软件工程专题：Scrum框架
• 软件工程专题：极限编程
• 软件工程专题：敏捷开发流程
• 软件工程专题：软件工程概述