UML - 用例图

要对系统进行建模，最重要的方面是捕获动态行为。动态行为是指系统运行/操作时的行为。

仅有静态行为不足以对系统进行建模，动态行为比静态行为更重要。在 UML 中，有五种图可用于对动态特性进行建模，用例图就是其中之一。现在，由于我们必须讨论用例图本质上是动态的，因此应该有一些内部或外部因素来进行交互。

这些内部和外部代理称为参与者。用例图由参与者、用例及其关系组成。该图用于对应用程序的系统/子系统进行建模。单个用例图捕获系统的一个特定功能。

因此，要对整个系统进行建模，需要使用多个用例图。

用例图的目的

用例图的目的是捕获系统的动态方面。但是，此定义过于笼统，无法描述目的，因为其他四个图（活动图、序列图、协作图和状态图）也具有相同的目的。我们将探讨一些具体目的，这些目的将它与其他四个图区分开来。

用例图用于收集系统的需求，包括内部和外部影响。这些需求主要是设计需求。因此，当分析系统以收集其功能时，会准备用例并识别参与者。

初始任务完成后，将对用例图进行建模以呈现外部视图。

简而言之，用例图的目的可以概括如下：

• 用于收集系统的需求。

• 用于获取系统的外部视图。

• 识别影响系统的外部和内部因素。

• 显示需求和参与者之间的交互。

如何绘制用例图？

用例图被认为是系统的高级需求分析。当分析系统的需求时，功能被捕获在用例中。

我们可以说用例只不过是以有组织的方式编写的系统功能。与用例相关的第二件事是参与者。参与者可以定义为与系统交互的任何事物。

参与者可以是人类用户、某些内部应用程序或某些外部应用程序。当我们计划绘制用例图时，我们应该已经识别出以下项目。

• 表示为用例的功能

• 参与者

• 用例和参与者之间的关系。

绘制用例图是为了捕获系统的功能需求。在识别上述项目后，我们必须使用以下指南来绘制有效的用例图

• 用例的名称非常重要。应以能够识别所执行功能的方式选择名称。

• 为参与者提供合适的名称。

• 在图中清晰地显示关系和依赖关系。

• 不要试图包含所有类型的关系，因为图的主要目的是识别需求。

• 在需要时使用注释来阐明一些要点。

以下是一个表示订单管理系统的用例图示例。因此，如果我们查看该图，我们将找到三个用例（订单、特殊订单和普通订单）和一个参与者，即客户。

特殊订单和普通订单用例从订单用例扩展而来。因此，它们具有扩展关系。另一个要点是识别系统边界，如图片所示。参与者客户位于系统外部，因为它是从系统外部使用系统的外部用户。

在哪里使用用例图？

正如我们已经讨论的那样，UML 中有五个图用于对系统的动态视图进行建模。现在，每个模型都有其特定的使用目的。实际上，这些特定目的是正在运行的系统的不同角度。

要了解系统的动态特性，我们需要使用不同类型的图。用例图就是其中之一，其特定目的是收集系统需求和参与者。

用例图指定系统的事件及其流程。但用例图从不描述如何实现它们。用例图可以想象成一个黑盒，只有黑盒的输入、输出和功能是已知的。

这些图在非常高的设计级别使用。此高级设计会反复细化，以获得系统的完整且实用的图景。结构良好的用例还描述了先决条件、后置条件和异常。这些额外元素用于在执行测试时创建测试用例。

尽管用例不是正向和反向工程的良好候选者，但它们仍然以略微不同的方式用于进行正向和反向工程。反向工程也是如此。用例图以不同的方式使用，使其适合反向工程。

在正向工程中，用例图用于创建测试用例，在反向工程中，用例用于从现有应用程序准备需求详细信息。

用例图可用于：

• 需求分析和高级设计。

• 对系统的上下文进行建模。

• 反向工程。

• 正向工程。