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

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

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

因此，为了对整个系统建模，使用了许多用例图。

用例图的目的

用例图的目的是捕获系统的动态方面。但是，此定义太笼统，无法描述目的，因为其他四个图(活动，序列，协作和状态图)也具有相同的目的。我们将研究一些特定的目的，这将使它与其他四个图区分开。

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

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

简而言之，用例图的目的可以说如下-

• 用于收集系统需求。

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

• 确定影响系统的外部和内部因素。

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

如何绘制用例图?

考虑用例图来进行系统的高级需求分析。在分析系统需求时，将在用例中捕获功能。

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

参与者可以是人类用户，某些内部应用程序，也可以是某些外部应用程序。当我们计划绘制用例图时，我们应该确定以下项目。

• 表示为用例的功能

• 演员们

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

绘制用例图以捕获系统的功能需求。确定以上各项后，我们必须使用以下准则来绘制有效的用例图

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

• 给演员起一个合适的名字。

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

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

• 必要时请使用注释以阐明一些重要点。

以下是代表订单管理系统的示例用例图。因此，如果我们查看该图，则会发现三个用例(Order，SpecialOrder和NormalOrder)和一个参与者(即客户)。

SpecialOrder和NormalOrder用例是从Order用例扩展的。因此，他们有扩展的关系。另一个重要点是识别系统边界，如图所示。参与者客户位于系统外部，因为它是系统的外部用户。

在哪里使用用例图?

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

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

用例图指定系统事件及其流程。但是用例图从未描述它们的实现方式。用例图可以想象成一个黑匣子，其中只有黑匣子的输入，输出和函数是已知的。

这些图在很高的设计水平上使用。不断完善这种高级设计，以获取系统的完整实用的图片。结构合理的用例还描述了前置条件，后置条件和异常。这些额外的元素用于在执行测试时制作测试用例。

尽管用例不是进行正向和反向工程的理想选择，但是用例仍然略有不同，因此可以用于正向和反向工程。逆向工程也是如此。用例图的用法有所不同，以使其适合于逆向工程。

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

用例图可以用于-

• 需求分析和高级设计。

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

• 逆向工程。

• 正向工程。