关于用例建模你需要知道的一切

用例图的好处

1. 用例是一种强大的技术，用于获取和记录黑盒功能需求。
2. 因为，用例很容易理解，并提供了一种与客户和用户交流的绝佳方式，因为它们是用自然语言编写的。
3. 用例可以帮助管理大型项目的复杂性，方法是将问题划分为主要的用户特征（即用例）并从用户的角度指定应用程序。
4. 通常由序列图表示的用例场景涉及多个对象和类的协作，用例有助于识别将对象和类粘合在一起的消息（操作和所需的信息或数据——参数）。
5. 用例为高级模型的验证（即参与者和一组协作对象之间的交互）和随后的功能需求验证（即白盒测试的蓝图）之间的链接提供了良好的基础。
6. 用例驱动方法为项目跟踪提供了一个可追溯的链接，其中关键的开发活动，如实施、测试和交付的用例，从用户的角度实现了目标。

如何绘制用例图？

可以按照以下步骤开发用例模型。

1. 识别系统的参与者（用户的角色）。
2. 对于每一类用户，确定与系统相关的用户所扮演的所有角色。
3. 确定用户需要执行哪些系统才能实现这些目标。
4. 为每个目标创建用例。
5. 构建用例。
6. 对用户进行优先级排序、审查、估计和验证。

注意：为了使用例方法更“敏捷”，不要详细说明所有用例，而是在产品 backlog 中优先考虑它们，您应该根据开发阶段及时细化不同细节级别的用例和恰到好处的方式。

你也可以：

1. 将用于用例逻辑分类的包绘制到相关子系统中。

构建用例

UML 定义了用例之间关联的三种原型：

<<include>> 用例

使用 <<include>> 关系的时间是在您完成所有主要用例的第一个剪辑描述之后。您现在可以查看用例并确定用户-系统交互的常见序列。

<<扩展>>用例

实际上，扩展用例是基本用例的替代过程。<<extend>> 用例通过在概念上将附加动作序列插入基本用例序列来实现这一点。

抽象和概括的用例

一般用例是抽象的。它不能被实例化，因为它包含不完整的信息。抽象用例的标题以斜体显示。

例子

此示例描述了几个业务用例（目标）的模型，它表示餐厅（业务系统）与其主要参与者之间的交互。

在第一次切割中确定了基本用例之后，也许我们可以在第二轮润色中使用 <<extend>> 和 <<include>> 用例进一步构建这些用例，如下图所示：

业务用例

业务用例是用 无技术术语描述的 ，它将业务流程视为一个黑盒并描述其业务参与者使用的业务流程，而普通用例通常在 系统功能级别进行描述 并指定功能或者系统为用户提供的服务。换句话说，业务用例表示在当前情况下如何手动完成工作，不一定由系统完成或打算在目标系统范围内自动化。

如何识别演员

通常，人们发现通过识别参与者来启动需求获取过程是最容易的。以下问题可以帮助您识别系统的参与者（Schneider 和 Winters — 1998）：

• 谁使用系统？
• 谁安装系统？
• 谁启动系统？
• 谁维护系统？
• 谁关闭了系统？
• 还有哪些其他系统使用该系统？
• 谁从这个系统中获取信息？
• 谁向系统提供信息？
• 目前有什么事情会自动发生吗？

如何识别用例？

识别用例，然后通过询问每个参与者想要什么外部可见、可观察的价值来进行基于场景的启发过程。一旦确定了参与者，就可以提出以下问题来确定用例（Schneider 和 Winters — 1998）：

• 参与者希望系统提供哪些功能？
• 系统是否存储信息？哪些参与者会创建、读取、更新或删除这些信息？
• 系统是否需要通知参与者有关内部状态的机会？
• 系统是否必须知道任何外部事件？什么参与者通知系统这些事件？

用例图提示

现在，查看以下提示，了解如何在您的软件项目中有效地应用用例。

• 始终从参与者的角度构建和组织用例图。
• 用例应该从简单和尽可能高的角度开始。只有这样才能进一步细化和细化。
• 用例图基于功能，因此应该关注“什么”而不是“如何”。

用例级别的详细信息

用例粒度是指在用例规范中组织信息的方式，在某种程度上，是指编写它们的详细程度。实现正确级别的用例粒度可以简化利益相关者和开发人员之间的沟通，并改进项目规划。

Alastair Cockburn 在 编写有效用例 中为我们提供了一种简单的方法，可以通过从海洋的角度来思考不同级别的目标级别：

注意：

• 虽然用例本身可能会深入了解每种可能性的大量细节，但用例图通常用于作为蓝图的系统的更高级别视图。
• 当不需要时，以较粗的粒度和较少的细节编写用例是有益的。

我希望您现在可以回答“什么是用例图”，并可以在您的项目中应用用例。如果您想了解更多关于其他 UML 图类型的信息，请查看 UML 指南：  Overview of the 14 UML Diagram Types。

仅以UML表示法显示用例图  是不够的。每个用例都附有解释用例目的的文本以及执行用例时完成的功能。

用例规范通常在分析和设计阶段以迭代方式创建。

• 首先，只写了执行用例的正常流程所需的步骤的简要描述（即，用例提供了什么功能）。
• 随着分析的进行，这些步骤被充实以添加更多细节。
• 最后，将异常流添加到用例中
• 每个项目都可以采用标准用例模板来创建用例规范。

用例与用例规范

用例描述了由参与者执行的任务，该任务为企业产生了商业价值的结果。用例可以可视化为用例图或/和结构化文本规范格式：

用例（任务——客户想要执行）可能是：

• 交互式——系统用例描述了参与者与系统的交互，以实现已定义的业务目标
• 手动 – 演员执行的一系列动作
• 自动化 — 由程序或脚本执行的一系列步骤

用例的特征

一个用例有：

• 只有一个目标
• 单一起点
• 单一的终点
• 从头到尾的多种路径
• 即为各种可能的条件指定行为
• 每个条件可能需要特定的操作

例如——客户支付账单：

实现目标有多种途径：

• 电话支付
• 通过邮寄
• 亲自
• 通过支票
• 用现金等

不通向目标的路径：

• 信用卡被拒绝

敏捷用例方法

用例模型及其各个用例会随着时间的推移逐级演进。并非模型的所有用例都必须指定为相同的详细程度。

适时且恰到好处

用例可以在不同级别的数据和范围内编写，每个都有一个目的：

• 摘要：系统功能或业务流程的一般描述和全面概述。
• 用户级别：与任务相关的用户描述以及他们如何与系统交互；特定业务流程的描述。用户级用例通常被认为是用户主要工作的任务级别。
• 子功能：用于完成核心用例的子部分的较低级别活动的描述。

注意：某些用例可能被充分指定到 II 级。当使用及时和恰到好处的方式获得足够的细节时，您就会停下来。

详细的用例规范

详细用例是一种文本表示，它以某种格式说明一系列事件以及其他相关用例信息。人们通常采用标准用例模板来记录用例的详细信息