10个创建专业用例图的技巧

什么是用例建模？

用例建模是对“用户（客户）想要什么？”这一问题的简单回答。它允许您通过可视化方式展示用户使用最终产品（可以是系统、软件、程序等）所希望达成的目标。用例建模是一种有用的技术，为软件开发人员提供了开发满足客户需求的软件系统的坚实基础。

尽管用例图中使用的符号看似简单且不包含太多细节，但用例的收集、组织和详细化方式对软件开发生命周期的方向产生重大影响，从而影响最终软件产品的质量。

10个实用的用例建模技巧

在本文中，我们将介绍十个技巧，以最大限度地提高绘制用例图的效果。我们不会详细解释什么是用例，而是涵盖UML建模、用例图和需求获取的一些关键概念。

1. 从最终用户的角度思考

显然，为了构建一个能正常运行的软件系统，您需要了解用户的需求，这一原则在用例建模中尤为重要。许多人错误地将用例建模视为建模系统功能的过程，这可能是错误的。准确地说，用例建模是建模用户需求的一种方式。用例图中的每个用例都应通过用户与最终软件或系统的交互，产生一个可观察的目标。有时，用户目标与系统功能相同，但并非总是如此。例如，“登录”是一个系统功能，但它绝不是用户目标——没有人会启动程序、登录后就离开！因此，您在用例图中绘制的系统功能越多，用例模型在整 个软件开发过程中表达用户真实期望的能力就越弱。因此，当您开发用例模型时，应首先从最终用户的角度思考，以表达所有内容。

2. 避免使用过长的用例名称

如果您正在阅读为ATM系统准备的用例图，您希望在图中看到以下哪个用例？“取现”和“取现并更新账户余额”。第二个用例似乎更具描述性，对吧？如果有50多个用例都使用如此长的名称，您可能不再想阅读该图，甚至可能会感到眼睛疼痛。

我们需要建模的原因之一是，希望以简单易懂的方式理解复杂的软件系统。这就是为什么UML提供了多种不同的符号，每种符号都代表描述完整软件系统的一个特定视角。这种“精神”同样适用于用例命名。如果我们尝试用详细描述来命名用例，为什么不直接使用文本文件呢？为了使用例图易于理解，保持用例名称简短但具有描述性非常重要。应保持名称简短，将详细描述留给用例的描述部分。

3. 角色是某种角色，而不是真实的人

有些人试图将组织中的员工表示为用例图中的角色，结果导致图中出现了彼得、玛丽、黛西等人。请记住，角色代表一种独特的角色，该角色由具有独特特征的人、子系统或任何其他实体组成，并共享相同的目标和期望。

4. 使用关系建模公共用例

用例代表用户目标，可以通过一系列步骤来实现。当在多个用例中发现完全相同的步骤时，可以可选地为这些公共步骤创建一个新的用例，并将其与触发这些步骤的用例连接起来。通过使用包含的用例，可以明确表明包含的用例确实与被包含的用例共享相同的步骤，没有任何歧义。

5. 建模异常行为

扩展关系可用于指定一个用例的行为何时以及如何被另一个用例触发。扩展发生在被扩展用例中定义的扩展点上。扩展用例定义了在特定条件下被扩展用例可能执行的步骤。

6. 使用事件流建模场景

用例代表用户目标，可以通过一系列步骤来实现。有些人试图在用例图上直接建模这些步骤，通过用大量关联连接参与者和用例，假装这些关联就是步骤，这显然是错误的。相反，用例的步骤可以在用例的事件流编辑器中很好地描述。事件流编辑器.

事件流编辑器以表格形式呈现，每一行代表用例的一个步骤。你可以在其中写下步骤，无论是否包含条件流程。你还可以对文本应用格式，以突出关键思想。

7. 善用构造型进行分类

构造型是一种机制，允许你在标准符号之外引入领域特定的符号。当应用构造型时，它显示在形状名称上方的一对尖括号内。正确使用构造型有助于读者更容易地识别用例之间的差异。

8. 使用顺序图建模详细系统流程

顺序图它允许你通过表示对象之间随时间传递的消息通信和交换来建模系统行为。但应该从哪里开始呢？与其猜测要建模的交互，不如从用户需求入手，这正是用例模型所要呈现的内容。

我们知道，每一个用例都代表一个独特的用户目标。从用例绘制顺序图意味着你将建模计算机系统为满足用户需求应执行的操作。理想情况下，不会出现冗余设计，因为所有顺序图都是从代表用户需求的用例创建的。

9. 在适当情况下对用例应用相同的宽度

由于用例名称长度不同，用例宽度不同是正常的。为了使图表更美观且更易读，将其调整为相同的宽度会更好。

10. 以有意义的方式放置参与者和用例

一个参与者和用例随机放置的用例图对读者来说绝对是噩梦。读者必须仔细检查图表，才能从分散的参与者和用例中找到所需信息。将图形以有条理的方式排列会更好。如有必要，还可以使用包形状对用例进行分组。