UML用例图

UML 用例图 Use Case Diagram

我们把用例图分解为四个不同的元素：系统Systems，参与者Actors，用例Use Cases和关系Relationships

1、系统

    系统就是我们正在开发的任何东西。它可以是一个网站，一个软件组件，业务流程，应用程序或任何其他的事情。

    矩形表示一个系统，并把系统的名称放在顶部。

我们构建一个简单的银行应用程序用例图。我们称为银行应用程序系统。此矩形有助于定义此系统的范围。

这个矩形内的任何东西都在银行应用程序内。这个矩形之外的任何东西都没有发生在银行应用程序中。

2、下一个元素是参与者，如图所示。参与者Actor将成为某人或者某事，来使我们的系统实现目标。那可能是一个人，一个组织，

另一个系统或者外部设备等。

        

那么谁或将要使用我们的银行业务程序呢？

最明显的参与者是顾客，我们将有顾客下载并使用我们的银行应用程序。

另一个参与者是银行，银行将提供相关信息，与交易一样，我们的银行应用程序提供交易，账户余额等

以下是我们除了参与者Actor时要注意的：

    首先，重要的是要注意这些参与者都是外部对象。它们总是要放在我们的系统外面

     其次，参与者要被视为类型或者类别。对于我们的银行应用程序，参与者不会去成为特定的个人或者特定组织。我们不会将我们的

参与者Actor标记为王超和招商银行。我们希望保持绝对的东西。所有现在我们说两个顾客和银行将使用我们的应用程序。这提出了主要次要的参与者。主要参与者启动系统的使用，而次要参与者更被动。所以在我们的例子中，那个参与者是主要的，那个是次要的？顾客是主要的    客户开始使用我们的系统，他们打算拿出手机打开我们的银行应用程序，并做一些事情。银行是次要的，银行只会在顾客做了些什么之后，才会采取行动。

    主要参与者应该在系统左边，次要参与者在系统的右边。

    

在这里我们只是视觉上强化了这一事实，客户参与银行应用程序，然后银行作出反应。

3、下一个元素是用例，这是我们真正开始描述我们的系统。

    我们使用椭圆描绘一个用例，它代表一个完成的动作，或者系统内的某种任务。

用例将被放置在矩形内，因为它们是在系统中发生的行为。

那么我们的银行应用程序会做些什么呢？简单来说，如果我们的银行应用程序可以进行 客户登录，查询余额，转账，支付等，那么这些将就是我们要描述的用例。

可以看到，我们的每个用例的描述都使用动词开始，我们使用动词加强了动作的发生。我们还希望它们具有足够的描述性。最后我们尽可能的按照逻辑顺序使用用例。这是我们将登陆置于顶端的原因。这是客户使用我们应用程序的第一件事。

4、用例图中的最后一个元素是关系。根据定义，参与者Actor正在使用我们的系统实现目标。所以每个参与者都必须至少与我们系统中的一个用例互动。

在我们的系统中，客户将要登录进入我们的应用程序。所以我们再参与者Actor与用例之间画一条实线，来表示这种关系。这种关系称为关联，它只是表示基本的沟通或互动。客户将与其他用例进行互动，也是如此。他们将查询余额，转账，支付，所以我们将用实线连接参与者与这些用例。

次要参与者Actor也要至少连接一个用例，请注意，每个参与者都必须与至少一个用例互动。

那么银行将与那些用例互动？当客户想要查询余额时，在应用程序上，银行将提供账户余额。我们再银行和查询余额直接画一条实线。同时，当客户进行转账或者支付时，银行正在跟进这些交易。我们不需要在登录时刻连线，是因为该过程发送在应用程序中，银行实际行没有必要参与登录过程。

还有其他三种关系，除了association 组合，还有Include包含、Extend扩展和Generalization泛化。

我们另外构建这个图表用例，以解释这些类型关系。

当客户输入他们的登录信息时，我们程序将在完成登录过程之前，验证密码是否正确，如果密码不正确，程序将显示错误消息。

因此我们创建两个新的用例验证，验证密码，和显示登录错误。

当客户在进行转账或支付时，银行会先验证余额是否充足；另外客户在支付和付款时，可以选择支票支付或者储蓄支付。我们创建两个用例支票支付，储蓄支付。

返回验证密码用例再次讨论关系。验证密码如何与其他用例发生关系？我们的参与者都没有直接发起，它只会在每次尝试登录时，发生在程序内部。这是一个包含关系。

包含关系显示基本用例和包含用例之间的依赖关系。 每次在执行基本用例时，包含用例也被执行。为了执行完一个基本用例，需要执行一个包含用例。

当基本用例有一个包含关系时，我们画一条带有箭头的虚线，到包含用例。

因此，在我们的示例中，登录用例是基本用例，它和验证密码用例是包含关系。每次客户登录是，应用程序将自动验证密码。除非登录用例不完整，或者验证密码已完成。

下一种关系是Extend扩展关系，扩展关系存在于基本用例和扩展用例之间。当执行基本用例时，扩展用例有时会发生，但不是每次都会发生。扩展用例只会在确定的符合标准的时间才会发生。

想到它的另一种方式是，你有扩展基础行为的选项用例。当有延伸关系时，我们画一条带有箭头的虚线，指向基本用例。

在我们的示例中，登录是一个基本用例，和显示登录错误是一种扩展关系。我们不会每次都显示错误信息，只会在用户输入错误密码时才显示。

这里我们解释了包含和扩展直接差异关系，以防万一，我们再举一个简单的例子，来区分两者之间的差异。

如果你打喷嚏，你会闭上眼睛。这是一个包含关系，因为它每次都会发生。另外，如果你打喷嚏，你可能会说劳驾，这是一个扩展关系，因为它补充了打喷嚏，但并非完全属于打喷嚏过程中必不可少的。

请记住每次都包含，延伸恰好发生在有时，而不是每次，箭头指向相反方向。

需要注意的一点是，多重基础用例 可以指向相同的包含或者扩展用例。例如：支付和转账将指向验证余额，我们希望系统每次在进行转账和支付时，进行此检查。每次这些基本用例执行时，都会执行检查余额用例。

最后一种关系是泛化，也叫继承。

当我们使用银行APP进行付款时，可以选择支票支付，或者储蓄支付。这种情况下，付款是基本用例，与支票支付用例，储蓄支付用例是父子关系，每个孩子都有共同的父行为，但每个孩子都有它自己的一些行为，更多的是它自己的。为了表名这种概况，我们从孩子哪里画出箭头，指向父母。

另外我们也允许对参与者Actor进行泛化。这些每种孩子参与者，都具有某些特有的行为或者品质。

最后，我们看一个带扩展点的用例，用例的名称在横线上方，下面有扩展点。扩展点只是一个详细的版本延伸关系。