软件工程专题：UML用例图

关注BeTester，学习更多知识

让碎片成为一个系统，让测试更专业

1、前言

当许多测试工程师谈论用例时，他们会默认 用例 = 测试用例 。但这是一个非常片面的理解，因为在软件工程领域，Use Case(用例)和 Test Case(测试用例)是一个完全不同的概念。

在《黑盒测试设计专题》和《测试用例专题》中，我们详细解释了测试用例Use Case 是什么， Use Case Diagram 有什么关系？本文将逐一回答。

2、概述

当我们想了解需求时，我们经常使用它5W2H方法协助分析，包括Who和What的问题可以通过用例图来解决。

谁在使用这个系统？这些人通过这个系统能做什么？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 泛化

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

@startumlactor 测试工程师 as tete --> (执行试验用例)(执行试验用例) <|-- (执行功能测试用例)(执行测试用例) <|-- (执行性能测试用例)@enduml

3.3.3 扩展

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

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

4、小结

例子对需求分析具有重要意义。它可以通过包含、泛化和扩展的关系来展示需求概述，使我们能够快速了解需求，然后为后续更详细的分析活动提供参考。

例图不是唯一提供需求分析的工具，但它可以统一和规范我们所有的建模，所以使用例图是非常必要的。

—— 更多文章 ——

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