用例图

顾客

顾客用户2.1 用例建模技术

2.1.1 参与者和用例

参与者（actor ）是系统外部与系统有交互的任何事物，是为了完成一个事件而与系统交互的外部实体。参与者主要用于描述系统的边界。例如，向银行提交贷款申请的顾客；通过因特网访问预订系统查询座位情况的旅行社，等等。在UML 中，参与者经常用人形符号表示，或者用类的构造型《actor 》表示，如图2-3所示。

图2-3 参与者的UML 表示符号

参与者并不一定是系统的用户。它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。图2-4展示参与者是外部系统的例子。

图2-4参与者是外部系统的例子

当参与者是人时，它是指一个与系统有交互的用户所扮演的角色。一个参与者并不是指一个特定的人或一个特定的实体。例如，参与者“顾客”是对顾客的概念建模，而不是对张三这个特定的顾客建模。

一个用例并不仅局限于一个参与者; 参与某用例的参与者可能是多个。然而，一个用例况必须向至少一个参与者提供可度量的价值。参与某用例的多个参与者各有不同的角色和职责：一些负责接收用例提供的价值，一些则负责向用例提供服务，其它则负责触发或初始化用例。Ivar Jacobson[1992]将参与者划为两类：主要的和次要的。主要参与者(primary actor)是从系统获得可度量价值的用户。主要参与者的需求驱动了用例所表示的行为或功能。如果他们的需求或角色发生了变化，那么系统将必须有重大的修改。次要参与者(secondary actor)在用例中提供服务，并且不能脱离主要参与者而存在。在图2-4所示的例子中，顾客是主要参与者，而客户关系系统则是次要参与者。

顾客<>顾客 客户关系管理系统 （已有） 网上商店系统（要开发） 问卷调查系统 （已有）

图2-5 抽象参与者的例子

一些参与者只扮演概念上的角色，而另一些则更具体。如图2-5所示，顾客共享用户的属性。用户是“父角色”，顾客是“子角色”。这两种角色之间的关系是一种继承关系，UML 中称为泛化（generalization）。在对参与者建模时，泛化用于表示两个实体之间的共同点和不同点。抽象参与者(abstract actor)代表两个或更多的参与者之间的共享的或共同的行为。

以下问题有助于寻找参与者：

●谁或什么将启动与系统相关的事件？

●谁或什么与系统交互将有助于系统对某个事件做出响应。

●系统需要与其它遗留系统交互吗？

●是否有要与系统交互的硬件或软件设备？

●如果系统中发生了一个事件，是否需要通知某个外部实体? 系统是否需要与外部实

体交互以帮助自己完成任务？

用例（use case）是系统为特定的参与者提供的一个功能，它描述了参与者是如何使用系统来实现其目标。正式地，用例是对一组动作序列（其中包括变体）的描述，系统执行这些动作序列来为参与者产生一个可观察的结果值。在UML中，用例用椭圆表示，如图2-4所示。

用例对参与者提供可观察的结果值。因此，用例总是描述系统与至少一个参与者的交互。用例和参与者之间的关系称为关联（association）。这种关联表示某个参与者与某个用例之间的通信，所以又称通信关联（communicates association），如图2-4所示。

列举目标可帮助我们确定用例的粒度大小。每个产生可观察价值的目标对应一个用例。例如，贷款处理系统的目标可能包括如下内容：

●申请贷款。申请者提交申请贷款所需的信息。信息的完整性由系统检查。

●检查贷款的状态。申请者在申请被接收的过程中可以向系统查询贷款的状态变化。

●提交附加的贷款信息。如果贷款请求需要附加的信息，例如对信用纪录中的某个问

题的解释，申请者必须提供该信息以使贷款处理过程继续。

●接收贷款。当贷款被批准，申请者必须同意贷款发出的所有条件。

相应的用例如图2-6所示

图2-6 贷款处理系统用例图

用例捕获被开发的系统（或子系统、类或接口）想要实现的行为，而不是说明这些行为是怎样实现的。从外部角度的行为说明（what）与从内部角度的行为实现（who）相分离是

place order

order management

非常重要的。从外部角度说明系统行为光靠一个椭圆符号是远远不够的，可以通过用足够清晰的、外部人员很容易理解的文字来说明一个用例的行为，并记录在用例详述（use case specification ）文档中。另外，用例描述的是一组动作系列，其中每个特定的动作系列称为脚本（scenario ）。用例与脚本的关系类似于类和对象的关系，脚本是用例的实例。（用例详述和脚本在2.3.4节详细介绍）。从内部角度说明行为如何被实现是分析和设计阶段的工作，

在UML 中被建模为一个协作（collaboration ）

，如图2-7所示，它描述了实现用例的一组分析或设计元素这个群体，包括静态结构方面（可用UML 类图描述）和动态行为方面（可用UML 交互图表示）。

图2-7 用例与协作

如果想分解多个用例中涉及的公共行为或分解某个用例的变体行为，可通过描述用例之

间的包含（include ）

、扩展（extend ）和泛化（generalization ）关系来组织用例，如图2-8所示。这些关系在下节详细介绍。

图2-8 用例之间的包含、扩展和泛化关系

2.1.2 用例图和活动图

UML 中的用例图（Use Case Diagram ）是七种UML 行为图中的一种，它概要地展示了系统的外部环境（一组参与者）、系统对外提供的功能（一组用例）以及它们之间关系，是一种描述系统功能性需求或系统语境的概览视图。 图2-9是用例图的一个例子。

Credit Authorization Serv ice

图2-9 用例图的例子

用例图的基本元素主要有主题（subject ）、一组参与者、一组用例以及它们之间的关系。主题可以是系统、子系统、类或接口。如图2-9所示，主题表示为一个矩形，其中包含一组表示用例的椭圆，主题的名字标在矩形内。参与者放在矩形外面。

用例图是一种呈现某个主题在语境中如何被使用的外部视图，它通常用于对主题的语境建模或对主题的需求建模。对主题的语境建模所强调的是围绕在主题周围的参与者，说明了该主题有哪些参与者以及它们所扮演的角色的含义；对主题的需求建模强调说明这个主题应该做什么（从主题外部的视点来看），即该主题在它的周边环境的语境中所提供的外部可见服务。在这种方式下，主题被看作是一个黑盒子，通过用例图可以观察到主题外部有什么，主题对那些外部反应，但却看不到主题内部是如何工作的。

参与者之间的关系主要是泛化（如图2-5所示），参与者与用例之间的关系主要是通信关联（如图2-4所示），用例之间的关系主要有包含、扩展和泛化（如图2-8所示）。

用例之间的包含（include ）关系表示基用例在它内部说明的某一位置上显式地合并了被包含用例的行为，基用例不能独立执行，它依赖于被包含用例的行为。被包含用例描述了从多个用例中提取的可复用的公共行为，它从不孤立存在，但它可以独立执行。包含关系的UML 符号是构造型为《include 》的依赖关系，从基用例指向被包含用例。如果想分解多个用例中涉及的公共行为，就可以用包含关系来组织用例。如图2-10所示，处理订单（process order ）用例在客户选用信用卡支付时需要合并处理信用卡支付（Handle Credit Payment ）这一被包含用例的行为。处理信用卡支付这个被包含用例捕获了一种基础服务，它可能在多

图2-10 包含关系的例子

用例之间的扩展（extend ）关系表示基用例在它内部说明的某个条件下隐式地合并了扩