UML 用例图

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

仅仅静态行为是不足以对系统进行建模的，相比之下，动态行为比静态行为更重要。在UML中，有五种图表可用于建模动态性，用例图就是其中之一。现在我们要讨论用例图是如何具有动态性质的，那就应该有某些内部或外部因素来进行交互。

这些内部和外部的作用者被称为角色。用例图包括角色、用例和它们之间的关系。该图被用于对应用程序的系统/子系统进行建模。一个单独的用例图可以捕捉系统的特定功能。

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

用例图的目的

用例图的目的是捕捉系统的动态方面。然而，这个定义太泛泛了，无法描述其目的，因为其他四种图表（活动图、顺序图、协作图和状态图）也都有相同的目的。我们将了解一些具体的目的，可以将其与其他四种图表区别开来。

用例图用于收集一个系统的要求，包括内部和外部影响。这些要求通常是设计要求。因此，在分析系统以获取其功能时，会预先准备用例并确定角色。

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

简言之，用例图的目的可以说是以下几个方面：

• 用于收集系统的要求。

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

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

• 展示需求和角色之间的交互。

如何绘制用例图

用例图被认为是对系统的高级需求分析。在对系统的需求进行分析时，功能会被捕捉为用例。

我们可以说用例就是以有组织的方式编写的系统功能。与用例相关的第二个要素是角色。角色可以被定义为与系统进行交互的实体。

角色可以是人类用户、一些内部应用程序，或者可能是一些外部应用程序。当我们计划绘制用例图时，应确定以下事项：

• 作为用例表示的功能

• 角色

• 用例和角色之间的关系

用例图被绘制用于捕捉系统的功能性要求。在确定了上述要素后，我们必须使用以下指导方针来绘制高效的用例图。

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

• 为角色选择合适的名称。

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

• 不要试图包括所有类型的关系，因为图表的主要目的是确定需求。

• 需要时使用注释来澄清一些重要的点。

以下是代表订单管理系统的一个样例用例图。因此，如果我们看图表，我们会发现三个用例 （订单、特殊订单和普通订单） ，和一个角色，即顾客。

特殊订单和普通订单用例从订单用例延伸。因此，它们具有扩展关系。另一个重要点是识别系统边界，如图所示。顾客角色位于系统外部，因为他是系统的外部用户。

在哪里使用用例图

正如我们已经讨论过的，UML中有五个图表来模拟系统的动态视图。现在每个模型都有一些特定的用途。实际上，这些特定的目的是运行系统的不同角度。

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

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

这些图表在设计的高层次上被使用。这个高层次设计会一遍又一遍地细化，以得到系统的完整实用图像。一个结构良好的用例还描述了前置条件、后置条件和异常。这些额外的元素在进行测试时用于制作测试用例。

虽然用例不是前向和逆向工程的理想选择，但它们仍然以略有不同的方式用于前向和逆向工程。逆向工程也是如此。用例图被用于不同的方式，使其适用于逆向工程。

在前向工程中，用例图用于制作测试用例，在逆向工程中，用例用于从现有应用程序中准备需求详细信息。

用例图可以用于：

• 需求分析和高层设计。
• 建模系统的上下文。
• 逆向工程。
• 前向工程。