用例模型

用例模型被定义为一个模型，用于显示用户如何与系统交互以解决问题。因此，用例模型定义了用户的目标、系统与用户之间的交互以及满足这些目标所需的系统行为。

用例模型包含各种模型元素，例如参与者、用例以及它们之间的关联。

我们使用用例图以图形方式描绘模型的子集，以简化沟通。通常会有许多与给定模型相关的用例图，每个图都展示了与特定目的相关的模型组件的子集。相似的模型组件可能出现在几个用例图中；但是，每个用例都应该是兼容的。如果为了处理用例模型而使用了工具，那么这种兼容性限制会自动执行，因此模型组件的任何更改（例如更改名称）都会自动反映在显示该组件的每个用例图中。

包可以包含用例模型，用于组织模型以简化分析、规划、导航、沟通、开发和维护。

各种用例模型是文本式的，并且文本被捕获在用例规范中，这些规范与每个用例模型的元素相关联。通过这些规范描述了用例的事件流。

用例模型在整个系统的开发中充当集成线索。用例模型用作系统功能需求的总体规范，作为设计和分析的基础，作为用户文档的基础，作为定义测试用例的基础，以及作为迭代规划的输入。

用例的起源

如今，用例建模经常与 UML 联系在一起，尽管它在 UML 存在之前就已经被引入。它的简要历史是

• Ivar Jacobson 于 1986 年首次提出了文本和视觉建模方法来指定用例。
• 1992 年，他合著的书《面向对象软件工程 - 用例驱动方法》促进了捕获功能性需求（尤其是在软件开发中）的策略。

基本模型组件

基本模型包含各种组件

1. 参与者
2. 用例
3. 关联

参与者

通常，参与者是根据其角色定义而参与系统的人员。参与者可以是任何人、外部系统。

用例

用例定义了参与者如何使用系统来完成特定目标。用例通常由用户引入，以满足实现目标所涉及的活动和变体的目标。

关联

关联是基本模型的另一个组成部分。它用于定义参与者与他们参与的用例之间的关联。这种关联称为通信关联。

高级模型组件

高级模型包含各种组件

1. 主题
2. 用例包
3. 泛化
4. 泛化
5. 依赖关系

主题

主体组件用于表示感兴趣的系统边界。

用例包

我们使用模型组件来构建用例模型，以简化分析、规划、导航和沟通。假设有许多参与者或用例。在这种情况下，我们也可以使用用例包来进一步构建用例模型，这与我们在硬盘上使用目录或文件夹来组织信息的方式非常相似。

出于各种原因，我们将用例模型划分为用例包，其中包括

• 通过将问题分解为易于处理的部分来帮助并行开发。
• 通过创建包含参与者、用例和与特定利益相关者相关的包来改善与各种利益相关者的沟通。

泛化

泛化意味着参与者之间的关联，以帮助重用通用属性。

依赖关系

在 UML 中，用例之间定义了各种类型的依赖关系。特别是，《包含》和《扩展》。

我们使用《包含》依赖项将包含用例的共享行为包含到基本用例中，以使用通用行为。

我们使用《扩展》依赖项将扩展用例的可选行为包含到扩展用例中。

如何绘制用例图？

如果我们想在 UML 中绘制用例图，首先，我们必须充分研究整个系统。我们需要找出系统提供的所有功能。当我们找出系统的所有功能后，我们将这些功能转换为多个用例，并在用例图中使用这些用例。

用例是指任何工作系统的基本功能。当我们组织好用例后，接下来我们需要列出许多将与系统协作的参与者或事物。这些参与者用于实现系统的功能。参与者可以是任何人或事物。它也可以是私有系统的一个实体。参与者应与参与者正在交互的功能或系统相关。

当我们列出用例和参与者后，接下来，我们需要找出特定参与者与系统或用例的关系。参与者应找到与系统协作的所有方式。一个参与者可以同时与多个用例交互，或者可以并发地与多个用例交互。

在绘制任何框架的用例时，我们必须遵循以下规则

• 用例名称和参与者名称应有意义并与系统相关。
• 参与者与用例的交互应得到充分描述并以易于理解的方式进行。
• 在必要的地方使用注释。
• 如果参与者或用例有许多关系，则只显示重要的交互。

何时使用用例图？

用例图是客户端完成的非凡系统功能。用例图的目标是捕获系统的关键功能，并可视化不同思维（称为参与者）与用例的交互。这是用例图的基本用途。

借助用例图，我们可以表征系统的主要部分以及它们之间的工作流程。在用例中，实现细节对外部用户隐藏，只表示事件流。

使用用例图，我们可以检测与参与者通信后的前置条件和后置条件。我们可以使用几个测试用例来确定这些条件。

通常，用例图用于

• 检查系统需求。
• 捕获系统功能。
• 我们使用用例图来建模系统背后的总体思想。
• 使用多个测试用例对系统进行正向和反向工程。
• 软件的复杂可视化设计。

用例旨在传达所需的功能，因此用例的确切范围可能因系统和创建 UML 模型目的的不同而有所不同。

绘制用例图的技巧

绘制用例图有多种技巧

• 它必须是完整的。
• 它必须是简单的。
• 用例图必须显示与用例的每一次交互。
• 如果用例很大，则必须将其泛化。
• 用例图必须至少定义一个系统模块。
• 当用例图中有许多参与者或用例时，应只表示重要的用例。
• 用例图必须清晰易懂，以便任何人都能轻松理解。

用例图的重要性

用例在过去几年中得到了广泛应用。用例图有多种好处

• 用例图提供了系统所有组件的概述。用例图有助于定义管理员、用户等的角色。
• 用例图有助于为开始一个无计划的项目时可能出现的各种问题提供解决方案和答案。
• 它有助于我们广泛地定义用户的需求并探索其工作方式。

基本用例图符号和约定

以下是基本用例图符号和约定

System

借助矩形，我们可以绘制包含用例的系统边界。我们需要将参与者放在系统边界之外。

用例

借助椭圆形，我们可以绘制用例。我们必须使用动词标记椭圆形，以表示系统的功能。

参与者

参与者是指系统的用户。如果一个系统是另一个系统的参与者，那么我们必须使用参与者立体声标记该参与者系统。

关系

使用简单的直线表示参与者与用例之间的关系。对于用例之间的关系，我们使用带有“扩展”或“使用”标签的箭头。“扩展”关系表示特定用例下的替代选项。“使用”关系表示完成一项工作需要单个用例。

更好的用例指南

在检查系统需求方面，用例图是另一个一对一的。用例易于理解和可视化。以下是一些有助于您创建更好的用例的指南，这些用例能让您的客户和同行都赞赏。

通常，用例图包含用例、关系和参与者。系统和边界可能包含在复杂的更大图中。我们将根据对象讨论用例图的指南。

不要忘记这些是用例图的指南，而不是规则。

参与者

• 参与者的名称应有意义且与业务相关
  如果用例与外部组织交互，那么我们必须用函数而不是组织名称来命名参与者，例如“航空公司”比“泛亚航空公司”更好）。
• 将继承的参与者放在父参与者下方
  我们将继承的参与者放在父参与者下方，因为这使参与者更具可读性，并轻松突出对该参与者而言是精确的用例。
• 外部系统是参与者
  如果“发送电子邮件”是我们的用例，并且当用例与电子邮件管理软件交互时，在这种情况下，该软件是该特定用例的参与者。

用例

• 用例的名称以动词开头
  用例代表动作，因此用例的名称必须以动词开头。
• 用例的名称必须具有描述性
  创建用例是为了向查看图表的其他人提供更多信息，例如，“打印发票”比“打印”更好。
• 将用例放在被包含用例的右侧。
  为了增加清晰度和提高可读性，我们将被包含的用例放在调用用例的右侧。
• 将继承的用例放在父用例下方
  为了提高图表的可读性，我们将继承的用例放在父用例下方。

系统/包

• 为这些对象赋予描述性和有意义的名称。
• 谨慎使用它们，并且仅在需要时使用。

关系

• 当使用《扩展》箭头时，它指向基本用例。
• 当使用《包含》时，箭头指向被包含的用例。
• 参与者和用例关系不显示箭头。
• 《扩展》可以有一个可选的扩展条件。
• 《包含》和《扩展》都显示为虚线箭头。

用例示例

用例示例-关联链接

在此用例图中，我们显示了一个系统的用例组，这意味着用例与参与者之间的关系。

用例示例-包含关系

为了添加基本用例中未指定的附加功能，我们使用包含关系。我们使用它将通用行为包含在包含用例中，以便支持重用通用行为。

用例示例-扩展关系

借助扩展关系，我们可以显示系统行为或可选功能。我们使用《扩展》关系将扩展用例的可选行为包含到扩展用例中。例如，下面的用例图显示了一个扩展连接器和一个扩展点“搜索”。

用例示例-泛化关系

在泛化关系中，子用例可以继承父用例的含义和行为。子用例能够覆盖并添加父类的行为。下面的图是泛化关系的例子，其中两个泛化连接器连接在三个用例之间。

用例图-车辆销售系统

下图显示了车辆系统的用例图示例。正如我们也可以看到的，像车辆销售系统这样的系统包含不超过 10 个用例，这是用例建模的精妙之处。

包含和扩展的使用也由用例模型显示。此外，还有连接用例和参与者之间的关联。

用例图-学生管理系统

下图显示了学生管理系统的运行情况

在上图的学生管理系统用例图中，我们有两个参与者和五个用例。参与者的名字是学生和老师。用例代表了学生管理系统的特定功能。每个参与者都与一个特定的用例交互。学生参与者能够查看考试分数、时间表和出勤。这些只是学生参与者可以执行的 3 种交互；但是系统中还有其他用例。

并非每个参与者都必须与每个用例交互，但这可能会发生。

在图中，第二个参与者的名字是老师。老师是一个能够与所有系统功能交互的参与者。老师参与者还能够更新学生的成绩和出勤。学生和老师参与者之间的这些交互共同概括了整个学生管理应用程序。