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

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

三、用例的命名

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

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

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

四、用例规约

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

1.用例的标识与名称：

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

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

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

3.用例的简要说明：

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

4.前置条件：

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

5.后置条件：

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

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

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

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

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

8.特殊需求：

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

9.相关用例和依赖：

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

10.业务规则：

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

11.设计约束：

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

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

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

13.验收标准：

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

14.其他信息：

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

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

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

五、用例的粒度处理

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

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

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

错误1：粒度过细

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

错误2：把步骤当用例

比如下图：

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

错误3：把活动当用例

如下图：

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

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

如下图：

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

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

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

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

一、什么是用例（Use Case）

二、用例的识别

2.1 识别用例的思考方法

2.2 识别用例的注意事项