UML - 用例图

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

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

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

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

用例图的目的

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

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

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

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

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

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

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

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

以下是代表订单管理系统的示例用例图。因此，如果我们查看该图，我们会发现三个用例（订单、特殊订单和正常订单）和一个参与者（即客户）。

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

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

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

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

这些图表用于非常高水平的设计。这种高层设计经过一次又一次的完善，以获得系统的完整和实用的画面。结构良好的用例还描述前置条件、后置条件和异常。这些额外的元素用于在执行测试时制作测试用例。

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

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

用例图可用于 -