用例建模是捕获需求的有用工具。它提供了软件系统需求的图形表示。
随着Ivar Jacobson (1991) 的《面向对象的软件工程，用例驱动方法》一书的出版，用例建模有效地成为了一种实用的分析技术”。今天，Jacobson 继续推广这种系统分析方法，并将其升级到用例 2.0，正式成为14 种 UML 图类型之一。
由于用例模型在概念和外观上都比较简单，因此与非技术人员（如客户）讨论其正确性相对容易。
用例不是过程、过程或功能。
用例图的元素
用例图的元素是参与者（外部实体）和用例本身。从广义上讲，用例是系统中的一个功能单元（需求）或服务。
演员
参与者是设计系统外部的任何实体，无论是个人还是其他非人类实体。系统的用户是参与者的典型示例。其他类型的参与者包括与当前系统（例如，数据库系统）集成的软件系统、传感器等外部硬件。
UML 规范中有两种表示法：
对演员使用火柴人更具表现力，但如果演员实际上不是人，而是机器或外部设备，则会导致混淆。矩形符号是类的标准UML表示法。
演员是角色而不是真人
参与者代表与当前系统交互的实体的角色，而不是实例。 演员符号表示实体是一个类而不是读取实例（即真实用户 John 或 Mary）。演员之所以是一类的，是不是演员本人，而是
他/她所扮演的角色。
例如，参与者可以代表银行的客户，而不是为每个客户指定单独的参与者。类似地，可能有另一个参与者代表银行经理。有趣的是，在现实世界中，一家银行的经理也可能是同一家银行的客户。换句话说，同一个人同时扮演客户和经理的角色。
用例的主要参与者是需要系统提供其服务的利益相关者。它有一个与系统相关的目标——系统运行可以满足的目标。主要参与者通常（但不总是）是触发用例的参与者。
次要角色由系统使用，但它们不与系统交互。换句话说，次要参与者不会启动任何用例。
用例通常由主要参与者发起。系统通过一组用例使用数据库等辅助角色。用例和参与者之间的关联代表了一种双向通信。
因此，对于由主要参与者发起的每个用例，必须响应连接的用例。类似地，对于次要参与者和用例之间的每个关联，通信都从用例开始，次要参与者应该响应启动。
用例
用例代表系统预期实现的功能（通常是需求）。用例的细节，除了其唯一的名称，在图中没有直观的表达；这些细节在用例描述中给出。
用例通常由关键参与者发起。系统通过一组用例使用数据库和其他辅助参与者。
用例和参与者之间的关联代表了双向通信。因此，对于主要参与者发起的每个用例，都必须响应后者。类似地，对于次要参与者和用例之间的每个关联，通信都从用例开始，次要参与者应该响应启动。
系统边界
系统边界定义了与周围世界相关的感兴趣系统。
用例图示例：航空公司预订系统
用例定义外部参与者和系统之间的交互，以实现特定目标。用例图包含四个主要组件
在票务预订系统的用例图中，系统由包含许多不同用例的框表示。主要参与者是客户，次要参与者是管理员。客户启动用例，例如预订、浏览和取消航班，而管理员启动用例，例如更新航班记录，但在取消航班用例中被视为次要参与者，因为她只是帮助完成客户发起的用例。
构建用例
根据应用领域和设计者的选择，一个用例可以分解成多个用例，通过<<include>>或<<extend>>关系连接起来。
关联链接表示参与者和用例之间的双向通信，因此是二元关系。由于它是双向通信，因此对于由主要参与者发起的每个用例，该参与者必须从用例中获得响应。
类似地，对于用例和次要参与者（由用例发起）之间的每次通信，次要参与者必须将响应发送回用例。
概括
泛化表示之间的关系
- 角色或
- 用例。
如果两个参与者通过这种关系连接，那么箭头末端（连接到三角形底部）的参与者（或用例）是另一端参与者（或用例）的特殊版本。
通常，底端（连接到三角形底部）的参与者（或用例）被称为另一端参与者（或用例）的专用版本。
泛化意味着专用版本具有通用版本的所有功能，甚至可能更多。
包含 是两个用例之间的一种特殊关系。如果一个用例 A 包含另一个用例 B，那么 A 的实现需要 B 的实现来完成它的任务。但是，B 是独立于自身的。也就是说，B 不需要知道关于 A 的任何信息。B 也可以包含在任何其他用例中。
扩展是两个用例之间的另一种特殊关系。如果一个用例 B 扩展了另一个用例 A，那么 A 的实现可以有条件地包括 B 的实现以完成其任务。也就是说，在某些情况下，A 可以在没有 B 的情况下完成其任务。但是，取决于所描述的条件。
用例图符号
执行用例分析的 9 个简单步骤
- 确定谁将直接使用该系统。这些人就是演员。
- 选择这些演员之一。
- 定义该参与者想要对系统做什么。参与者想要对系统做的每一件事都成为一个用例。
- 对所有其他用例重复步骤 2-3 为您
确定的用例确定次要角色和非人工角色支持。 - 绘制用例的初始版本，此时不要过度复杂化用例关系
- 与用户讨论和审查以验证每个用例的目标（提议功能的好处） 修改后，您可以继续在步骤 8 – 10 中详细说明用例
- 对于每个用例，确定参与者在使用系统时将遵循的最常见流程。通常会发生什么。
- 在用例描述中描述这个基本过程。
- 一旦您对基本流程感到满意，现在考虑替代方案并将其添加为扩展用例。
用例模型和规范
仅用 UML 表示法显示用例图是不够的。每个用例都附有解释用例目的和执行用例时完成的功能的文本。
用例描述了由参与者执行的任务，该任务为企业产生业务价值结果。用例可以可视化为用例图或/和结构化文本规范格式。
用例场景
一个用例由许多场景组成，每个场景代表用例的一个特定实例，对应于参与者的特定输入或环境中的特定条件。每个场景都描述了系统运行的另一种方式，或者它可能描述失败或异常。
一个用例有：
- 只有一个目标
- 单一起点
- 单一的终点
- 从头到尾的多种路径
- 即为各种可能的条件指定行为
- 每个条件可能需要特定的操作
例如 – 客户支付账单：
实现目标有多种途径 ：
- 电话支付
- 通过邮寄
- 亲自
- 通过支票
- 用现金等
不通向目标的路径 ：
- 信用卡被拒绝
使用包对用例进行分组
您还可以： 将用于用例逻辑分类的包绘制到相关子系统中。
详细的用例规范
详细用例是一种文本表示，它以特定格式描述事件流和其他相关用例信息。标准用例模板通常用于记录用例的详细信息
什么是用例描述
用例描述是对分析师为完成完整系统事务而执行的一系列步骤的书面描述。它由参与者发起，为参与者提供价值，并且是参与者在系统中工作的目标。
参与者——任何在系统外部使用系统或与系统交互以实现目标的人或系统。每个参与者都被赋予一个角色来代表他们与解决方案的交互。人物演员应该以角色的形式命名，而不应该被分配实际名称。参与者通常分为主要、次要或利益相关者
主要参与者——启动用例的参与者。
次要参与者——对主要参与者执行的动作做出反应或响应的参与者。
利益相关者——不直接与用例交互，但对用例的结果感兴趣的场外参与者。
事件流（路径） ——参与者和解决方案执行用例必须采取的步骤序列。通常，用例由主要成功路径（也称为基本或主要）、备用路径和异常路径组成。
正常路径——参与者的输入和系统的响应——代表了实现参与者目标的最常见的成功路径。
备用路径——来自参与者和系统响应的输入，代表完成参与者目标的其他不太常见的路径
异常路径——来自参与者和系统响应的输入，表示参与者的目标无法实现时的不成功路径。
| 用例描述 | |
|---|---|
| 用例名称： | 提取现金 |
| 演员： | 客户（主要）、银行系统（次要） |
| 摘要说明： | 允许任何银行客户从他们的银行账户中提取现金。 |
| 优先： | 一定有 |
| 状态： | 中等细节水平 |
| 前提： | 银行客户有一张卡要插入 ATM ATM 正常在线 |
| 后置条件： |
|
| 基本路径： |
|
| 替代路径： |
|
| 商业规则： |
|
| 非功能性要求： |
|
简体中文
English
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский