【UML】第7篇 用例图（2/3）

目录

一、什么是用例（Use Case）

二、用例的识别

2.1 识别用例的思考方法

2.2 识别用例的注意事项

三、用例的命名

四、用例规约

五、用例的粒度处理

错误1：粒度过细

错误2：把步骤当用例

错误3：把活动当用例

错误4：从系统角度命名用例

---

（续上篇）

【UML】第6篇 用例图（1/2）-CSDN博客

一、什么是用例（Use Case）

用例是参与者可以感受到的系统服务或功能单元。它定义了系统要实现的一个目标。用例只定义系统的一个行为，而不显示系统的内部结构。

用例最大的优点是站在用户的角度描述系统功能。

在图形上，用例使用实线椭圆来表示，并在椭圆内部或下部标注用例的名称。

用例是一种通过用户的使用场景来获取需求的技术，每个用例提供了一个或多个场景，该场景说明了系统是如何同最终用户或其它系统交互的，从而为用户带来可测量的、有价值的结果。从本质上来讲，用例是用户与计算机之间的一次典型交互作用。

 用例的主要目的包括：

1. 捕获需求：通过用例，可以捕获功能性需求并明确系统的范围。
2. 沟通：用例为项目团队、客户和其他干系人提供了一种共同的语言，用于讨论和理解系统行为。
3. 驱动开发：用例可以作为设计和实现的基础，确保系统的开发满足用户需求。

在用例的描述中，通常包括以下内容：

1. 用例名称：简短、明确地描述用例的目的或动作。
2. 参与者：与用例交互的角色或系统。
3. 前置条件：执行用例之前必须满足的条件。
4. 后置条件：用例执行后系统的状态。
5. 基本路径：描述用例的主要成功场景。
6. 扩展路径：描述可能的异常或替代场景。

二、用例的识别

2.1 识别用例的思考方法

在软件开发过程中，有效地识别和定义用例是至关重要的，因为它确保了系统的功能性和用户需求得到满足。以下是六种识别用例的方法：

1. 业务过程分析：深入了解相关的业务领域，通过业务流程图、活动图等，分析业务的流程、任务和交互，从中提取出与业务目标直接相关的用例。
2. 用户角色分析：识别系统中的不同用户角色，理解每个角色的职责和目标。针对每个角色，思考他们与系统交互的目的和方式，从而确定用例。
3. 场景分析：设想用户在使用系统时可能遇到的各种场景，包括正常流程、异常情况和紧急事件。每个场景都可以对应一个或多个用例。
4. 功能分解：从高层次的系统功能开始，逐步分解为更具体的子功能，直到每个功能都可以明确地对应到一个或多个用例。
5. 事件驱动分析：识别系统中可能触发动作或状态变化的事件。每个这样的事件都可能是一个用例的起点或终点。
6. 现有系统/竞品分析：如果有现有的系统或竞品，可以通过分析其功能和用户交互来识别用例。这不仅可以节省时间，还可以确保不遗漏重要的功能点。

在识别用例时，需要注意避免过于技术化或细节化，保持用例的独立性和完整性，确保每个用例都能为用户带来明确的价值。此外，持续与用户和相关干系人沟通也是确保用例准确性的关键。

注意：识别中，记住首先要识别准确参与者，再沿着参与者的方向，去识别用例。

2.2 识别用例的注意事项

• 要目标不要过程。识别出的用例应该反应出系统的目标，即“要做什么”，而非“怎么做”，就是说用例不是系统实现的细节；
• 要关注用户，不要关注系统。从参与者的角度出发定义用例，而非系统的角度。
• 要结果不要动作。用例应为参与者提供有价值的结果，而非动作的集合；
• 要独立不要分解。避免陷入功能分解，步骤分解；
• 每个参与者都应该有可执行的用例，每个用例都应关联至少一个参与者。
• 要确定系统的边界和范围是关键。这有助于区分哪些功能属于系统内部，哪些功能属于外部环境。清晰的边界有助于避免用例的混淆和重叠。
• 要简洁不要冗长。
• 要考虑异常和错误情况。除了正常的操作流程外，还需要考虑异常和错误情况。这些场景可能包括系统故障、用户错误或外部事件。确保这些场景也被纳入用例考虑范围，有助于提高系统的健壮性和用户满意度。

三、用例的命名

用例的命名，要站在参与者的角度，描述要达到的目标，简单讲，就是：

（状语）动词+（定语）宾语

也就是动宾结构。例如上面的“借阅图书”。

四、用例规约

用例规约（Use Case Specification）是对用例的详细描述，它提供了关于用例如何运作的详细信息。一个完整的用例规约应该包括以下内容：

1.用例的标识与名称：

• 标识：每个用例都应该有一个唯一的标识符，以便于在项目中引用和追踪。
• 名称：用例的名称应该简洁、明确，能够清晰地反映用例的主要功能或目的。

2.用例涉及到的参与者：

• 主要参与者：执行用例的主要角色或系统。
• 次要参与者：与用例执行有关的其他角色或系统，但不直接执行用例。

3.用例的简要说明：

• 对用例的简短概述，描述用例的主要目的和功能。

4.前置条件：

• 执行用例之前必须满足的条件或约束。

5.后置条件：

• 用例执行完成后系统的状态或变化。

6.基本路径（主成功场景）：

• 描述用例在正常情况下如何执行的主要步骤序列。

7.扩展路径（备选和异常场景）：

• 描述用例可能遇到的其他场景，如备选流程、异常或错误情况。

8.特殊需求：

• 用例可能涉及的非功能性需求，如性能、安全性或合规性要求。

9.相关用例和依赖：

• 列出与此用例相关的其他用例，以及它们之间的关系（如包含、扩展或泛化）。

10.业务规则：

• 与用例相关的业务规则和政策，这些规则可能会影响用例的执行。

11.设计约束：

• 任何可能影响用例实现的设计约束或限制。

12.用户界面和交互设计（如果适用）：

• 描述用户界面的元素和交互方式，以及用户如何与系统进行交互。

13.验收标准：

• 定义如何确定用例是否已正确实现的标准或准则。

14.其他信息：

• 包括任何对理解或实现用例有用的附加信息，如参考文档、图表、草图等。

一个详细且完整的用例规约可以确保所有项目干系人对用例有清晰、一致的理解，并为开发人员提供实现用例所需的所有必要信息。

注：用例规约同时也是需求采集的有效思考方式，可以帮助我们避免遗漏重要的信息。

五、用例的粒度处理

 我们已经知道，用例的识别中，要避免同一个维度的用例，产生相互的包含关系，也就是“一致性”原则。说起来容易，做起来还是需要一些实践经验和技巧的。这里，就需要考虑用例的颗粒度划分。

用例粒度过细，则用例包含的系统功能就越多，反之越少。用例粒度过粗，不便于理解系统，粒度过细会使用例模型过于庞大，给设计带来困难。

下面总结几个用例识别过程中，常犯的几个错误。

错误1：粒度过细

比如把增删改查，这样的通用操作，作为4个用例来描述。会导致用例图晦涩冗余，覆盖重要的信息。直接归纳为一个用例“管理用户”即可。

错误2：把步骤当用例

比如下图：

这是4个注册用户的步骤，这就是上面我们说的，不要去分解实现功能。这里其实就只有一个用例，就是“注册用户”。

错误3：把活动当用例

 如下图：

这就是典型的把活动当用例，用户其实无法感知这些背后的过程，这也不是用例。

错误4：从系统角度命名用例

如下图：

左边就是从系统的角度去描述了，让人云里雾里，或者感觉对，但就是可读性差，别扭。

右侧的，明显就是从参与者（用户） 的角度出发，很清晰简洁。

（未完待续，关注我呦！）