软件设计过程中画用例图的步骤.pdf

用例图

用例图(UseCaseDiagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。

用例图包含六个元素，分别是：参与者(Actor)、用例(UseCase)、关联关系(Association)、包含关系(Include)、扩

展关系(Extend)以及泛化关系(Generalization)。

一．参与者（Actor）

确定参与者

在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。

（1）谁将使用该系统的主要功能。

（2）谁将需要该系统的支持以完成其工作。

（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。

（4）系统需要处理哪些硬件设备。

（5）与该系统那个交互的是什么系统。

（6）谁或什么系统对本系统产生的结果感兴趣。

二、用例（UseCase）

识别用例

用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者

和用例，他们分别描述了“谁来做”和“做什么”这两个问题。识别用例最好的方法就是从分析系统的参与者开始，

考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很

大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节

信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。

在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。

（1）特定参与者希望系统提供什么功能。

（2）系统是否存储和检索信息，如果是，由哪个参与者触发。

（3）当系统改变状态时，是否通知参与者。

（4）是否存在影响系统的外部事件。

（5）哪个参与者通知系统这些事件。

三、用例间的关系

1．关联关系（Association）

２．包含关系（Include）

包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，

提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。

包含关系使一个用例的功能可以在另一个用例中使用，如下所述。

（1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用

例建立包含关系。

（2）一个用例的功能太多时，可以用包含关系建模两个小用例。

要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，

它们在某种程度上具有相似的语义。

３．扩展关系（Extend）

相对于包含关系一定要执行的特性，扩展关系（extend）则是一种可选择执行的关系。以自动柜员机（ATMSystem）为

例，打印收据（printreceipt）与提款之间的关系就比较适合采用扩展关系，如下图所示。在提款流程结束之前，会

询问顾客是否需要打印收据，所以打印收据不是一段必要的流程，而是一段可选择的流程。

４．泛化关系（Generalization）

一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。

在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。

在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行

为。如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。