什么是用例图？
UML用例图是正在开发的新软件程序的系统/软件需求的主要形式。用例图的目的是可视化系统应该做什么（什么）；在这个阶段，它不考虑如何（如何）去做。
一旦指定了用例，就可以用文本和可视化的表示（即用例图）来表示它。用例建模的一个关键概念是它帮助我们从最终用户的角度设计系统。它是一种通过指定所有外部可见的系统行为以用户术语来传达系统行为的有效技术。
换句话说，必须从外部来看待系统的使用，即不应该从内部来看待系统，而是从更高的层次来确定系统应该提供给外部参与者的功能。
用例图的目的
用例图通常是在开发的早期阶段开发的，人们经常将用例建模用于以下目的。
- 指定系统的上下文
- 捕获系统的需求
- 验证系统架构
- 推动实施并生成测试用例
- 由分析师、领域专家和目标最终用户共同开发
用统一建模语言定义了标准形式的用例图，如下面的用例图示例所示。
用例图的元素
演员
每个用例都会有至少一个参与者，可以理解为至少一个参与者（角色），参与者（角色）不一定是人，也可能是另一个系统或设备。一个参与者可以与多个用例交互，一个用例可以与多个参与者交互。
参与者不一定是人，即用户，但他们实际上可以是非人，即系统或时间。
大多数情况下，用户是参与用例图的人，例如客户、员工、主管等。
人类与非人类演员
有时，系统会受到各种事件的影响，以在给定情况下执行某些功能。比如审核通过后，系统主动发信通知人；那么信件的发送是由系统自动执行的吗？这个用例其实是由时间触发的，那么actor就是Timer；比如这个用例可以看成“每天5:00自动发送一封信”，那么触发这个事件——发送一封信——的actor就不是系统，实际上是Timer Actor
主要与次要演员
主要参与者是使用系统实现目标的参与者。用例记录了系统和参与者之间的交互，以实现主要参与者的目标。次要参与者是系统需要协助以实现主要参与者目标的参与者。
- 演员可能是主要的或次要的。主要参与者启动与系统的交互。
- 系统通常会调用次要参与者寻求帮助，并且次要参与者从不启动用例。
请注意：演员的符号不区分主要演员和次要演员；必须从用例描述（也称为用例叙述）中推断出差异。
例如：
银行信贷员想要审查客户的贷款申请，部分流程涉及实时信用评级检查。
- 用例名称。审查贷款申请
- 主要演员。信贷员
- 次要演员。信用评级系统
如何识别演员？
由于参与者不一定是人，而可能是外部系统、设计或计时器，我们通过询问以下问题来找到更具体的参与者
- 一旦系统开发完成，谁将使用该系统？
- 系统需要从谁或哪些其他系统获取数据？
- 该系统将为谁或其他哪些系统提供数据？
- 该系统将与哪些其他系统相关联？
- 谁将维护和管理系统？
这些问题帮助我们抽象出系统的参与者。以 ATM 为例，回答这些问题可以让我们找到更多的参与者，即
- 运营人负责维护和管理 ATM系统
- ATM 还需要与后端服务器通信以获取有关用户帐户的信息。
用例
用例表示预期由系统实现的功能（通常是需求）。用例的细节，除了它的唯一名称，没有在图中直观地表示；这些细节在用例的叙述（文字描述）中给出。
用例是一系列动作或事件步骤，通常定义参与者角色与系统之间的交互以实现目标。用例是识别、澄清和组织系统需求的有用技术。用例由系统和用户之间可能的交互序列组成，这些交互序列定义了要实现的功能以及可能遇到的任何错误的解决方案。
如何识别用例？
一旦我们找到了参与者，我们就可以根据参与者来确定系统的用例，主要看每个参与者需要系统提供哪些服务，或者参与者如何使用系统。用例的识别可以从以下问题开始（针对每个参与者）。
- 演员为什么要使用这个系统？
- 参与者是否在系统中创建、修改、删除、访问和存储数据？如果是这样，演员如何执行这些操作？
- 参与者是否通知系统某些外部事件？
- 系统是否会通知参与者某些内部事件？
综上所述，ATM系统的用例图可以表示如下。
用例由椭圆、静态或动态、任务或系统表示。
系统边界
系统边界通过在矩形边界中对用例进行分组来描述系统，Visual Paradigm 中的系统边界提供了用例包含行为。
参与者是与正在开发的系统交互的角色（人类参与者或非人类参与者）。因此，参与者应该被放置在系统边界之外，并与放置在系统边界内的用例进行交互。
注意：
参与者由系统的边界定义。如果我们要定义的系统边界仅限于ATM本身，那么后端服务器就是一个外部系统，可以抽象为一个actor。
如果我们要定义的系统边界扩展到整个银行系统，其中 ATM 和后端服务器都是整个银行系统的一部分，那么后端服务器不再被抽象为参与者。
关系
了解这三个关键符号后，继续学习关系知识并绘制用例图。绘制了参与者和用户案例之间的直接关系，并将该关系用作没有箭头的线，表示双向关系，称为链接线。
一个用例可以分解成几个用例，这些用例通过 <<include>>、<<extend>> 或 <<generalization>> 关系（在本文后面描述）连接起来。
通信链路关系
这表示参与者和用例之间的双向通信，因此是二元关系。
<<包含>> 关系
包含关系意味着用例将包含其他用例。包含关系的目的是使用包含关系来减少再次描述相同用例的重复。如果多个案例共享相同的部分功能，则可以将功能分离出来，并将其他用例包含在案例中。
例如，图书管理员借书时需要读取代码记录借书，还书时还需要读取代码记录归还图书，因为读取代码是一个重复的动作部分，可以做成一个单独的用例，让借书和还书都包含这个用例。
如果一个用例 A 包含另一个用例 B，那么 A 的实现需要 B 的实现来完成它的任务。但是，B 是独立于自身的。也就是说，B 不需要知道关于 A 的任何信息。B 也可以包含在任何其他用例中。
<<扩展>> 关系
如果一个用例 B 扩展了另一个用例 A，那么 A 的实现可以有条件地包括 B 的实现以完成其任务。也就是说，在某些情况下，A 可以在没有 B 的情况下完成其任务。但是，根据所描述的条件，A 可能需要 B。在这种情况下，B 依赖于 B。但是，根据所描述的条件，A 可能需要 B . 在这种情况下，B 依赖于 A，不能单独存在。因此，B 不能扩展到一个以上的用例。A 的用例叙述将包括它需要 B 的执行步骤；这个点称为扩展点。
让我们看另一个例子，当没有库存时系统会自动订购货物，这样经理就不必直接执行订单。请参见下面的用例图：
泛化关系
泛化关系类似于类图中面向对象语言的泛化关系，可以应用于角色（参与者）和用例的泛化。
比如在订票系统中，有两种订票方式：“电话订票”和“网上订票”，基础用例“订票机”，可以用泛化的方式来塑造案例，并将 <<essential>> 添加到父用例（预订）以指示广义关系。
讨论用例图中的关系
- 在一般用例图中，我们只表示参与者和用例之间的关系，即它们之间的通信关联。
- 此外，我们还可以描述参与者和参与者之间的泛化，以及用例之间的包含、扩展和泛化关系。
- 我们使用这些关系来适应现有的用例模型，并提取一些通用信息以供重用，使用例模型更易于维护。
- 但是，我们在应用程序中选择这些关系时必须小心。通常，这些关系会增加用例和关系的数量，从而增加用例模型的复杂性。
- 而且，用例模型通常是在完成后才进行调整，所以在用例建模的早期，不需要急于抽象用例之间的关系。
用例——事件流
用例图为我们提供了系统功能的整体视图，我们可以知道哪些参与者将与系统交互，以及每个参与者需要从系统中获得哪些服务。
用例描述了参与者和系统之间的对话，但是这个对话的细节并没有在用例图中表示，所以对于每个用例，我们可以用事件流来描述这个对话的细节。
用例场景和事件流程 – ATM 取款
例如，ATM 系统中的“取款”案例可以用如下事件流来表示：
正常场景——提款——事件的基本流程：
- 用户插入信用卡
- 输入密码
- 输入提款金额
- 提取现金
- 退出系统并取回信用卡
但这仅描述了提款用例的正常场景。作为一个真正的 ATM 系统，我们还必须考虑可能出现的各种其他情况，例如：
- 无效的信用卡，
- 密码错误，
- 用户账户现金余额不足等
所有这些可能的情况（正常和异常）都称为用例场景，场景也称为用例实例。场景也称为用例的实例。在一个用例的各种场景中，最常见的场景由基本流程描述，而其他场景由替代流程描述。
替代方案
对于 ATM 系统中的“取款”用例，我们可以得到一些替代流程，如下所示。
提款 – 替代事件流程。
- 备选方案 I：用户可以在基本流程的任何步骤选择退出，并转到基本流程的第 5 步。
- 备选流程二：在基本流程的第1步，用户插入一张无效的信用卡，系统显示错误并退出信用卡，用例结束。
- 备选流程三：基本流程第2步，用户输入错误密码，系统显示错误提示用户重新输入密码，返回基本流程第2步；密码输入错误 3 次后，信用卡被系统没收，用例结束。
- …
通过结合基本场景和替代场景，可以清楚地描述一个用例中可能发生的所有各种情况。在描述一个用例的事件流程时，我们希望尽可能描述所有可能的场景，以保证需求的完整性。
用例模型与用例图
重要的是要避免将由参与者和用例组成的用例图是用例模型的误解，因为用例图只是系统可以提供的服务的可视化表示，让我们大致了解系统的功能。
用例模型包括一个用例图和每个用例的详细描述，即用例规范，它在 RUP 中作为模板提供。
简要说明
简要说明用例的作用和目的。
事件
流 事件流应该代表所有场景，包括基本场景和替代场景。
用例场景
包括成功场景和失败场景，场景主要是基础流程和备选流程的结合。
特殊需求
描述与用例相关的非功能性需求（包括性能、可靠性、可用性、可扩展性等）和设计约束（操作系统、开发工具等）。
前置条件
在执行用例之前系统必须处于的状态。
后置条件
执行用例后系统可能处于的状态集。
用例规范本质上是一种文本表示，可以选择使用状态图、活动图或序列图来帮助更清楚地描述事件流。用户界面和流程的任何图形表示或其他图形（即线框）都可以附加到用例中，只要它们有助于提高表示的清晰度即可。
例如：
- 活动图可用于描述复杂的决策过程，
- 状态转换图可用于描述与状态相关的系统行为，以及
- 序列图适用于描述基于时间的消息传递。
用例工具
网络版
免费绘图工具Visual Paradigm Online（VP Online）免费版支持UML、ERD和组织结构图。您可以使用直观的 UML 绘图编辑器快速绘制用例图。这个免费的UML工具没有广告，没有限制访问期限，也没有图表数量，形状数量等限制。自由绘制UML。自由绘制UML。您拥有您为个人和非商业目的创建的图表。
桌面版
Visual Paradigm Community Edition于 2004年推出，仅提供用于非商业目的的免费 UML 软件，支持刚开始 UML 建模的用户，以及需要免费的跨平台 UML 建模软件的用户个人使用，例如在学生项目中应用 UML。
参考
简体中文
English
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский