该篇文章是UML知识的扩充。
什么是用例图
源文链接：https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/
以下是UML世界中经常被问到的一些问题：什么是用例图？为什么要用用例图？或者简单地说，为什么用例？有些人不知道用例是什么，而其他人则低估了用例在开发好的软件产品中的有用性。用例图被低估了吗？希望你看完这篇文章后能够找到答案。
那么什么是用例图呢？UML用例图是未开发的新软件程序的系统/软件需求的主要形式。用例指定了预期的行为(什么)，而不是实线它的确切方法(如何)。用例一旦指定，就可以用文本和视觉表示(即用例图)表示。用例建模的一个关键概念是它帮助我们从最终用户的角度涉及系统。它是一种通过指定所有外部可见的系统行为来以用户的方式传达系统行为的有效技术。
用例图通常很简单。它没有显示用例的详细信息：
- 它只总结了用例、参与者和系统之间的一些关系。
- 它没有显示为实线每个用例的目标而执行的步骤的顺序。
如前所述，用例图应该很简单，并且只包含几个形状。如果您的用例包含超过20个用例，则您可能误用了用例图。
下图显示了UML图层结构和UML用例图的定位。如您所见，用例图属于行为图家族。
注意：
- 有许多不同的
UML图用于不同的目的(从上面的UML图树可以看出)。您可以在其他UML图类型和文档中描述这些细节，并将它们与用例链接起来。 - 用例仅代表系统的功能需求。其他需求，如业务规则、服务质量需求和实线约束，必须再次用其他
UML图单独表示。
一、用例的起源
如今，用例建模通过与UML相关联，尽管它是在UML存在之前引入的。其简史如下：
- 1986年，Ivar Jacobson首次制定了用于指定用例的文本和视觉建模技术。
- 1992年，他与人合著了《面向对象的软件工程———用例驱动方法》一书，帮助普及了捕获功能需求的技术，尤其是在软件开发中。
二、用例图的目的
用例图通常在开发的早期阶段开发，人们经常将用例建模用于以下目的：
- 指定系统的上下文
- 捕获系统的需求
- 验证系统架构
- 推动实施并生成测试用例
- 由分析师与领域专家共同开发
三、用例图概览
用统一建模语言定义了标准形式的用例图，如下面的用例图示例所示：
3.1 用例图使用的符号
3.1.1 角色
- 角色与用例(系统功能)交互。
- 以名词命名。
- 类似于用户的概念，但一个用户可以扮演不同的角色。
- 例如：
- 一个教授，可以是讲师，也可以是研究员
- 在两个系统中扮演2个角色
- Actor对系统负责(输入)，Actor对系统有期望(输出)。
3.1.2 用例
- 系统功能(过程-自动或手动)
- 以动词+名词(或名词短语)命名。
- 即做某事。
- 每个Actor必须链接到一个用例，而某些用例可能没有链接到Actor。
8.1.3 连接线
- 角色在用例中的参与是通过将角色连接到用例中来显示的。
- 角色可以通过关联连接到用例，这表明角色和用例使用消息相互通信。
8.1.4 系统
- 系统可能是需求文档中定义的整个系统。
- 对于大型复杂系统，每个模块都可能是系统边界。
- 例如，对于一个组织的ERP系统，每个模块，如人事、工资、会计等。
- 可以为特定于这些业务功能中的每一个的用例形成系统。
- 整个系统可以跨越所有这些描述整个系统的模块。
3.2 用关系构建用例图
用例共享不同类型的关系。定义两个用例之间的关系是用例图的软件分析师的决定。两个用例之间的关系基本上是对两个用例之间的依赖关系进行建模。通过使用不同类型的关系重用现有用例可减少开发系统所需的整体工作量。用例关系如下所示：
3.2.1 扩展关系
- 表示”无效密码”用例可能包括(根据扩展中的规定)由基本用例”登录账户”指定的行为。
- 用带有虚线的定向箭头描绘。箭头的尖端指向基本用例，子用例连接在箭头的底部。
- 构造型
"<<extends>>"标识为扩展关系。
3.2.1 包含关系
- 当一个用例被描述为使用另一个用例的功能时，用例之间的关系被命名为包含或使用关系。
- 一个用例包括另一个用例中描述的功能，作为其业务流程的一部分。
- 从基本用例到子用例的使用关系表明基本用例的实例将包括在子用例中指定的行为。
- 包含关系具有虚线的定向箭头来描绘。箭头的尖端指向连接在箭头底部的子用例和父用例。
- 构造型
<<include>>将关系标识为包含关系。
3.2.3 泛化关系
- 泛化关系是用例之间的父子关系。
- 子用例是父用例的增强。
- 泛化显示为带有三角形箭头的定向箭头。
- 子用例连接在箭头的底部。箭头的尖端连接到父用例。
3.3 用例示例
3.3.1 关联连接
用例图说明了系统的一组用例，即角色以及角色与用例之间的关系。
3.3.2 包含关系
包含关系添加了基本用例中未指定的附加功能。<<include>>关系用于将包含用例中的常见行为包含到基本用例中，以支持常见行为的重用。
3.3.3 扩展关系
扩展关系很重要，因为它们显示了可选的功能或系统行为。<<Extend>>关系用于在扩展用例中包含来自扩展用例的可选行为。看看下面的用例图示例，它显示了一个扩展连接器和一个扩展点”搜索”。
3.3.4 泛化关系
泛化关系意味着子用例继承父用例的行为和含义。孩子可以添加或覆盖父母的行为。下图通过显示连接三个用例之间的两个泛化连接器提供了一个用例示例。
四、用例图示例
车辆销售系统
下图显示了车辆系统的用例图示例。如您所见，即使是像汽车销售系统一样大的系统也包含不超过10个用例！这就是用例建模的美妙之处。
用例模型还展示了<<Extend>>和<<include>>的使用。此外，角色和用例之间存在关联。
五、如何识别角色
通常，人们发现通过识别参与者来启动需求获取过程是最容易的。以下问题可以帮助您识别系统的参与者。
- 谁使用系统？
- 谁安装系统？
- 谁启动系统？
- 谁维护系统？
- 谁关闭了系统？
- 还有哪些其他系统使用该系统？
- 谁从这个系统中获取信息？
- 谁向系统提供信息？
- 目前有什么事情会自动发生吗？
六、如何识别用例
识别用例，然后通过询问每个角色想要什么外部可见、可观察的价值来进行基于场景的启发过程。一旦确定了角色，就可以提出以下问题来确定用例。
- 参与者希望系统提供哪些功能？
- 系统是否存储信息？哪些参与者会创建、读取、更新或删除这些信息？
- 系统是否需要通知参与者内部状态的变化？
- 系统是否必须知道任何外部事件？什么参与者通过系统这些事件？
七、用例图提示
现在，查看以下提示，了解如何在您的软件项目中有效地应用用例。
- 始终从参与者地角度构建和组织用例图。
- 用例应该从简单和尽可能高地角度开始。只有这样才能进一步细化。
- 用例图基于功能，因此应该关注”什么”而不是”如何”。
八、用例级别的详细信息
用例粒度是指在用例规范中组织信息的方式，在某种程度上，是指编写它们的详细程度。实现正确级别的用例粒度可以简化利益相关者和开发人员之间的沟通，并改进项目规划。
Alastair Cockburn在编写有效用例中为我们提供了一种简单的方法，通过从海洋的角度来思考不同级别的目标级别：
注意：
- 虽然用例本身可能会深入了解每种可能性的大量细节，但用例图通常用于作为蓝图的系统的更高级别视图。
- 当不需要时，以较粗的粒度和较少的细节编写用例是有益的。