【UML】第7篇 用例图（2/3）
目录
（续上篇）
一、什么是用例（Use Case）
用例是参与者可以感受到的系统服务或功能单元。它定义了系统要实现的一个目标。用例只定义系统的一个行为，而不显示系统的内部结构。
用例最大的优点是站在用户的角度描述系统功能。
在图形上，用例使用实线椭圆来表示，并在椭圆内部或下部标注用例的名称。
用例是一种通过用户的使用场景来获取需求的技术，每个用例提供了一个或多个场景，该场景说明了系统是如何同最终用户或其它系统交互的，从而为用户带来可测量的、有价值的结果。从本质上来讲，用例是用户与计算机之间的一次典型交互作用。
?用例的主要目的包括：
- 捕获需求：通过用例，可以捕获功能性需求并明确系统的范围。
- 沟通：用例为项目团队、客户和其他干系人提供了一种共同的语言，用于讨论和理解系统行为。
- 驱动开发：用例可以作为设计和实现的基础，确保系统的开发满足用户需求。
在用例的描述中，通常包括以下内容：
- 用例名称：简短、明确地描述用例的目的或动作。
- 参与者：与用例交互的角色或系统。
- 前置条件：执行用例之前必须满足的条件。
- 后置条件：用例执行后系统的状态。
- 基本路径：描述用例的主要成功场景。
- 扩展路径：描述可能的异常或替代场景。
二、用例的识别
2.1 识别用例的思考方法
在软件开发过程中，有效地识别和定义用例是至关重要的，因为它确保了系统的功能性和用户需求得到满足。以下是六种识别用例的方法：
- 业务过程分析：深入了解相关的业务领域，通过业务流程图、活动图等，分析业务的流程、任务和交互，从中提取出与业务目标直接相关的用例。
- 用户角色分析：识别系统中的不同用户角色，理解每个角色的职责和目标。针对每个角色，思考他们与系统交互的目的和方式，从而确定用例。
- 场景分析：设想用户在使用系统时可能遇到的各种场景，包括正常流程、异常情况和紧急事件。每个场景都可以对应一个或多个用例。
- 功能分解：从高层次的系统功能开始，逐步分解为更具体的子功能，直到每个功能都可以明确地对应到一个或多个用例。
- 事件驱动分析：识别系统中可能触发动作或状态变化的事件。每个这样的事件都可能是一个用例的起点或终点。
- 现有系统/竞品分析：如果有现有的系统或竞品，可以通过分析其功能和用户交互来识别用例。这不仅可以节省时间，还可以确保不遗漏重要的功能点。
在识别用例时，需要注意避免过于技术化或细节化，保持用例的独立性和完整性，确保每个用例都能为用户带来明确的价值。此外，持续与用户和相关干系人沟通也是确保用例准确性的关键。
注意：识别中，记住首先要识别准确参与者，再沿着参与者的方向，去识别用例。
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：从系统角度命名用例
如下图：
左边就是从系统的角度去描述了，让人云里雾里，或者感觉对，但就是可读性差，别扭。
右侧的，明显就是从参与者（用户）?的角度出发，很清晰简洁。
（未完待续，关注我呦！）
?
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！