用例建模

Table of Contents hide

UML 用例图是正在开发的新软件程序的系统/软件需求的主要形式。用例指定了系统的预期行为（什么），而不是实现它的确切方法（如何）。一套完整的用例指定了使用系统的所有不同方式，因此定义了限制系统范围的系统所需的所有行为。

用例建模的一个关键概念是它帮助我们从最终用户的角度设计系统。它是一种通过指定所有外部可见的系统行为来以用户的方式传达系统行为的有效技术。

用例图一览

用统一建模语言定义了标准形式的用例图，如下面的用例图示例所示：

什么是用例？

用例是讨论中的系统与其与特定目标相关的外部参与者之间可能的交互序列的集合。
从用户的角度来看，每个用例都是系统中事件的完整过程。
用例一旦指定，就可以用文本和视觉表示（即用例图）表示。
用例是组件和对象社区喜欢用来指定需求并确实推动整个软件开发过程的方法。
用例通常坚持相当大的任务；不需要为用户可以执行的每个操作编写它们。

用例方法的好处

除了定义用户需求之外，用例还提供了许多好处。用例可用于：

用例帮助捕获系统的功能需求。
用例是可追溯的。
用例可以作为估计、调度和验证工作的基础。
用例可以在每次迭代中从捕获需求的方法演变为程序员的开发指南，再到测试用例，最后演变为用户文档。
用例替代路径捕获可以提高系统稳健性的其他行为。
事实证明，用例很容易被业务用户理解，因此被证明是软件开发人员和最终用户之间的良好桥梁。
识别业务域类及其关联

演员

有人与用例（系统功能）交互。
以名词命名。
演员在商业中扮演角色
类似于用户的概念，但一个用户可以扮演不同的角色
例如：
一个教授。可以是讲师，也可以是研究员
在两个系统中扮演 2 个角色
参与者触发用例。
Actor 对系统负责（输入），Actor 对系统有期望（输出）。

用例

系统功能（过程——自动或手动）
以动词+名词（或名词短语）命名。
即做某事
每个 Actor 必须链接到一个用例，而某些用例可能没有链接到 Actor。

通讯链接

参与者在用例中的参与通过将参与者连接到用例中来显示。
参与者可以通过关联连接到用例，这表明参与者和用例使用消息相互通信。

系统边界

系统边界可能是需求文档中定义的整个系统。
对于大型复杂系统，每个模块都可能是系统边界。
例如，对于一个组织的 ERP 系统，每个模块，如个人、工资、会计等。
可以为特定于这些业务功能中的每一个的用例形成系统边界。
整个系统可以跨越所有这些描述整个系统边界的模块

6 步用例分析

在开发用例时，您应该从功能分区开始——目标系统的主要功能类别的列表。这将有助于确定需要关注哪些领域。

第 1 步 — 确定参与者：确定谁将直接使用系统。这些是演员。

用例开发的主要组成部分之一是参与者。
参与者是系统用户扮演的特定角色，代表在使用系统时表现出类似行为的一类用户。
参与者可能是人或计算机系统。
主要参与者是具有需要系统帮助的目标的参与者。
次要参与者是系统需要帮助以实现其目标的参与者。
其中一个参与者被指定为正在讨论的系统。
一个人可以扮演多个角色，从而代表多个参与者，例如计算机系统操作员或最终用户。

第 2 步：选择其中一个演员。

为了识别目标系统的用例，我们识别系统参与者。
一个好的起点是检查系统设计并确定它应该帮助谁。

第 3 步——识别用例：定义参与者想要对系统做什么。参与者想要对系统做的每一件事都成为一个用例。

演员想要对系统做的事情成为目标。
目标是用户行为的最终结果。有两种类型的目标。第一种是刚性目标。
这个目标必须完全满足并描述了目标系统的最低要求。
为了识别用例，我们可以从参与者的角度阅读需求规范，并与将充当参与者的用户进行讨论。
通过定义每个参与者在与系统交互时能够做的所有事情，系统的完整功能就被定义了。

第 4 步 – 确定正常用例场景：对于每个用例，决定该参与者使用系统时最常用的路线。通常会发生什么。

一个用例包含一门基础课程和几门备选课程。
基础课程是最简单的课程，可以毫无困难地交付请求。
可能有替代课程来描述基础课程的变体以及可能发生的错误。
这些被记录为用例的扩展。

第 5 步 — 开发用例描述：在用例描述中描述基本课程。

使用场景是从用户的角度以通俗易懂的语言编写的。
写出实现确定目标所需的步骤，称为事件流。

第 6 步 – 开发用例替代路径：一旦您对基础课程感到满意，现在考虑替代方案并将其添加为扩展用例。

用例的替代方案

用例还描述了当事情不正确或不正确时系统应该如何响应，但不是我们在主要成功场景中描述的方式。我们称这些情况 为扩展。

有两种变体： exceptions 和 alternates。
例外情况是失败条件（出现问题）。
替代方案只是让事情顺利进行的另一种方式。

用例级别的详细信息

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

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

注意：

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

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