用例图

顾客

顾客用户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 ）关系表示基用例在它内部说明的某个条件下隐式地合并了扩

展用例的行为。基用例可以独立执行，但是在一定的条件下，它的行为可以被另一种情况所扩展（或称延伸）。基用例只能在它的某些确定的点上被扩展，这种点称为扩展点（extend point）。扩展用例是不能单独执行的，它可以看作是基用例行为的补充。扩展关系的UML 符号是构造型为《extend》的依赖关系，从扩展用例指向基用例。如果想分解某个用例的变体行为，就可以用扩展关系来组织用例。如图2-11所示，处理订单（process order）用例在说明处理客户支付的行为时，在客户是VIP并使用了优惠券的条件下，处理优惠券支付（Handle Gift Certificate Payment）这个扩展用例就捕获了这种变体行为。一般情况下，这种变体行为没必要分解，也可以在基用例中说明。但如果不想修改基用例，或者不断修改基用例，添加无数新的扩展和条件步骤可能会导致基用例难以维护，就可以采用扩展用例来说明这种补充情况。扩展关系也可用于将可选的行为从必须的行为中分离出来。

图2-11 扩展关系的例子

用例之间的泛化（generalization）关系类似于类之间的泛化关系，子用例继承父用例的行为和含义，子用例可以增加或覆盖父用例的行为，子用例可以出现在父用例出现的任何位置。如图2-8所示，验证用户身份（Validate User）用例有两个特殊的子用例验证密码（Check Password）用例和虹膜扫描（Retinal Scan）用例，它们都有父用例的行为，可以出现在父用例出现的任何地方，还添加了自己的行为。但是，由于在子用例的用例详述文档中很难区分和管理从父用例继承来的行为和自己添加的行为，所以用例之间的泛化关系在建模实践中很少用。

2.1.3用例详述

用例模型（use case model）是表述用例和参与者所需的图及其描述的集合。除了用例本身之外，用例模型还包括必要的文字、术语表、图和其他用来详细说明用例的文档。用例详述（use case specification）就是这样的文档，它以外部人员很容易理解的文字来说明一个用例的行为。

一个完整的用例模型并不是一次完成的。每一个用例一般都要随着对系统需求认识的深入，有一个不断精化的过程。随着对问题了解的深入，用例详述不断地添加细节。因此，用例详述可大致分为初始用例详述、基本用例详述和详细用例详述，如图`2-24所示。

初始用例详述基本用例详述详细用例详述

图2-24 初始用例详述、基本用例详述和详细用例详述

●初始用例详述：在需求分析开始阶段开发的用例详述，主要确定和粗略地描述由

参与者初始化的系统行为。它们提供了对系统的一个概念上的描述。

●基本用例详述：基本用例详述通过更详细地记录用例行为来扩展初始用例详述。

基本用例着重于“理想化”的行为和用例路径，避免为异常和选项建立文档。

●详细用例详描述：在基本用例详述中添加一些行为的细节，例如条件逻辑和备选

流程等。

初始用例详述应该为读者提供一个对该用例的完整的、高层的理解。下面是撰写概念层次的用例详述的指南，模板和例子分别如图2-25和图2-26所示。

●总结促成该用例的业务目标。

●描述用例的目的。

●总结用例中的主要行为（用例的范围）。

●文字不要超过几个句子或者一个段落。

●用现在时和主动语态描述。

图2-25初始用例详述模板

图2-26初始用例详述“提交贷款申请”示例

初始的用例图和详述提供了用例及其与系统的关系的高层文档。用例详述的第二个级别称为基本用例详述，它在用例的事件流范围内确定发生在参与者与系统之间的具体行为和交互。在基本用例中表达的需求包括以下方面：

●用例执行时在参与者和系统之间发生的具体的交互。

●在一个用例中系统的具体职责。

●在一个用例中参与者的具体职责。

为了发现这些细节，每个初始用例详述可进一步细化为一系列动作，这些动作系列构成事件流（flow of events）。事件流是对这些动作系列及其顺序的一个描述，当某事件触发该用例时，这些动作序列按照这些顺序发生。这个流一直流到使系统处于某特定状态的“终点”或后置条件。除了事件流，一个基本用例详述还包括与用例相关的补充信息。

图2-27 基本用例详述模板

●前置条件和后置条件

前置条件（Preconditions）描述了某用例执行前系统所处的状态，即为了使该用例能被

执行所必须满足的条件。

后置条件(Postconditions)描述了作为用例完成的结果系统所处的状况，即用例执行完后系统所处的状态。

前置条件和后置条件可以帮助定义用例的范围，例如事件流何时开始何时结束。了解用例职责的范围和用例完成的含意是重要的。

前置条件和后置条件有助于确定用例间的依赖关系。用例并不是独立的，一些用例依赖于其它用例，一个用例结束时系统所处的状态是其它用例执行的前提。某用例所依赖的其它用例是什么？该用例结束时系统处于什么状态？该用例如何配合整个用例模型？这些问题只有在了解全局情况后，才能得到解答。例如，在贷款系统中，“评估贷款”用例发生的前提条件是用例“验证贷款证明”所描述的功能必须存在。而“提交贷款申请”用例结束时系统所处状态，即已确认贷款申请并准备验证贷款证明，则是“验证贷款证明”用例发生的前提条件。

前置条件和后置条件都应以用户可理解的词汇在某个抽象层次上描述。描述这两个条件的详细程度应和用例一样。如果用例在高层，那么前置条件和后置条件也应在高层；如果用例描述了详细的行为，那么前置条件和后置条件也应该详细。例如，如果一个用例在其事件流中涉及贷款申请，那么前置条件和后置条件也应在相同的抽象层次上描述；如果该贷款申请被确认了，那么后置条件可以这样写：“贷款申请被批准”。

前置条件和后置条件仅与系统的状态而不是外部环境有关。例如，在一个描述图书管理员将书借给借阅者的用例中，一个正确的后置条件可能是“该书已被借出”，而“读者可以自由地带着该书离开图书馆”则不够正确。

以下是一些对前置条件和后置条件的指导原则：

?前置条件和后置条件应以可验证和可测试的方式来记录。

?前置条件必须反映用例执行前系统需要处于的状态。

?前置条件和后置条件必须用现在时态记录。

?给多个前置条件和后置条件分别编号。

?可以用对象模型来补充前置条件和后置条件中的系统状态描述。

●事件流

事件流是基本用例详述的实质内容。基本用例详述中的事件流描述了那些在参与者和用例之间的对话期间发生的基本活动（例如，行为和交互）。事件流以一系列步骤或者自由格式的文字记录了这些事件发生的顺序。事件流的步骤应该以用户术语而不是以调用函数名或技术语言来描述。

用例事件流可以以多种形式出现：自由格式的文字、可能包含条件和循环逻辑的有数字标记的步骤。有三种流行的文字表示方法：

?散文方法。将达到用例所描述的目标的所有可能路径（成功的和不成功的）以

自由格式的文字简单地记录下来。散文方法的优点是快速，它不强求如步骤格

式那样严格的次序或顺序。

?步骤方法。在步骤方法中，事件流是以有序的步骤表的方式来描述的。每个步

骤连续编号并提供下一步骤的简短描述，它比散文方法少些冗余，对软件开发

者更有吸引力。

?状态方法。有些领域用状态模型来描述更为自然。状态方法以状态名来标记事

件流中的每个段落，段落描述了从一个状态转向新的状态的过程。UML状态

机可用于补充用例。对于在用例中有许多非线性路径的领域－例如通信系统，

状态方法更为合适。

对用例事件流的描述可以采用所谓黑盒用例描述的外部视图方法，也可以采用所谓白盒用例描述的内部视图方法，或者是两种方法相结合。

?在外部视图方法中，一般只有那些外部参与者直接可见的活动才在用例中描

述。系统是一个与参与者有交互的“黑盒”，并没有描述系统为提供或支持交

互所做的事情。例如，ATM系统的用例事件流仅描述客户与ATM的交互，其

重点集中于客户的需求（诸如取钱和存钱的请求），而支持该交互所需的内部

行为（诸如事务日志、关于透支限制的业务规则等）则很少被记录。

?内部视图方法在用例中包含了系统内部行为的细节（即白盒）。这些行为是一

些需求（“what”而不是“how”），它们可能是系统与外部参与者交互的结果，

或者是对交互的支持。例如，ATM系统的用例事件流深入描述系统内部当客

户取现金时将发生的事情：检查账号的余额，从账号中扣除所取的现金数目，

记录取钱的细节（诸如时间、数量、地点），等等。

?按黑盒和白盒活动将事件流分列：如果要开发内部行为但又要把它们与用例职

责区分开来，可以采用另一种双列的用例事件流格式。这种格式既可以描述用

图2-28 按黑盒和白盒活动将事件流分列

?协作案例方法[Mattingly 1998]：用例只提供关于系统交互的的黑盒视图，而响

应具体交互所触发的内部行为则用所谓的协作案例（不要和UML中定义的协

作混淆）分开来描述。协作案例与用例描述相类似，用于文档化内部系统交互

（白盒细节）。协作案例一般与一个或多个用例发生联系，协作案例名在用例

事件流中指明，如图2-29所示。

图2-29 基本用例和协作案例

撰写基本用例详述事件流的指导原则有以下几点：

?用数字或黑点标记活动。如果在事件流中活动有一个自然的顺序，那么用数字

标记它们。如果有子活动，就用低一级的数字，例如2.1、2.2等。如果没有明

显的顺序或者几个步骤可能同时发生，就用黑点或相同的数字标记。每个活动

的描述可以从一句话到几小段不等。

?尽量使事件流易于理解。基本用例应该描绘一个故事，尽量使用完整的，描述

性的句子来表达所发生的动作。为便于理解整个流程，应使用主动语态。“申

请者填写完贷款申请表并把它提交给银行”比“贷款申请被提交了”更易于

理解而且提供了更好的语境。

?不要过多地陷入细节。不要在这个时候记录系统的每个细节，应使每个用例的

详细程度保持在大致相同的水平上。更多的细节将在细化用例和对象建模时被

文档化。

?目前，要避免文档化异常或条件逻辑，除非它们对理解用例行为来说是必须的。

异常、备选和扩展将由备选、扩展关系以及用例实例来处理。对事件流建模时，

不要忘记用例的后置条件或最终结果。

?注意事件流的长度。为了便于维护事件流和管理它的复杂度，事件流最好不超

过一两页。处理用例长度的原则是每个用例都应该展现一个完整的情节。也就

是说，它应该代表初始化它的参与者的目的，并且应该使系统处于稳定的状态。

?用例必须是明确的。用例事件流就象一出戏，参与者必须通过阅读手稿（用例）

来演戏。每个阅读它的人都可以知道它所展现的是什么。用例应该撰写到这种

程度，客户可以把它们作为合同并在上面签字。用例应该撰写成有助于设计和

实现测试。

●用例优先级

在大的开发工作中，如果需要控制和监控有关系统和范围的迭代或增量开发，那么建立用例间的优先级是必需的。用例的优先级记录了相对于其它用例的开发优先级。用例优先级可以用诸如直接数字标记或把用例按优先级（比如高、中、低）分组等技术来描述。

●备选事件流和异常

尽管在基本用例详述中不对异常和备选事件流进行细化，但可以开始发现并列出用例中的主要的备选事件流和异常，用描述性的名称和简短的描述把它们记下来。

●假设

在用例开发过程中可能会有一些对在用例模板中预先定义的域都不适合的信息出现。模板中的假设域可以用来记录这些重要且杂乱的用例问题，比如以下几方面：

?关于用例范围的假设

?对由外部服务器得到的信息的期望。

?与用例有关的开发问题，比如，开发用例所需的工作级别、时间匡算等。

●问题

在开发用例时会发现一些问题。有些问题可能要在以后的分析和设计阶段才会有头绪。不要忽略它们，把它们简要地记录下来以便在合适的时候解决。

●来源

用来开发用例的信息的来源是什么？它来自需求研讨会、与客户的面谈或是培训手册？把每个特定的信息来源记录清楚，对需求管理来说，可跟踪性（Traceability）是一个关键。

图2-30 “提交贷款申请”基本用例详述

基本用例详述主要描述用例的基本事件流。用例详述的第三个级别称为详细用例详述，它重点在于：

●描述备选流，列出在用例中出现备选情况或异常时的事件流；

●在事件流中直接用条件逻辑来记录事件流中出现的异常和备选过程。

一般在用例执行时会有许多可能的变化、备选以及异常出现。例如，如果用户信用不好时采取什么行为？客户从ATM取钱时，如果帐号中没有足够的钱，该怎么办？由于这些备选和变化可能表示重要的功能，必须仔细考虑它们的含意，并把它们作为用例描述的一部分记录下来。记录备选的方法之一是使用备选流描述，它记录了在基本事件流中出现备选和变化时将会发生的行为。

一个备选可能包括这样一些事情：诸如基于用户输入的不同处理选项，用例事件流中发生的判断行为，或者导致不同行为执行结果的异常条件等。

备选流可以在基本用例描述中快速简单地记录。或者，如果细节代表了重要的需求，可以把它们写在分开的描述模板中。但是，备选流描述是用例的一部分，不是单独的用例。图2-31是一个备选流描述的示例模板。

图2-32是“拒绝贷款申请”备选流描述的例子

图2-32 备选流描述：拒绝贷款申请

不是所有的备选或异常都要用单独的备选流描述来表示。在许多情况下，把它们记录在基本用例详述的备选流部分就可以了。

条件逻辑可以作为一种备选流，条件逻辑直接可以加到事件流文本以表示不同可能的结果。例如，决定贷款申请者的帐户情况时。图2-33中，在“评估贷款申请”用例中增加了条件逻辑以反映如果客户没有良好信用时的备选过程和异常。

当事件流是线性的－含有很少或没有循环和条件逻辑－用文字就足以捕获和表示用例信息。但是，如果用例事件流中有复杂的逻辑，条件和循环反复有时会变得难以理解。在这种情况下，可以考虑使用UML活动图作为一种对用例事件流建模的替代方法。活动图提供了对整个用例的事件流的可视化表示，在表示用例事件流中的条件、同步和循环逻辑时尤其

有用，对验证复杂的事件流也很有好处。

图2-34是用于用例的简单活动图。活动图的初始状态与用例中的前置条件对应，终止状态与用例中的后置条件对应。每个用例事件流的动作都被表示为一个活动，并有一个短小的名字标明它的用途。

图2-34 用于用例的简单活动图

图2-35表示了用于“提交贷款申请”用例的活动图

用例前置条件 （开始状态） 用例活动间的转移 开始

图2-35 “提交贷款申请”用例的活动图

从用例详述出发可以创建一套测试案例或测试套件（test suit），每一个测试案例代表用例的一个脚本。下面以“评估贷款申请”用例为例子，分析如何从用例详述来创建功能性测试案例或脚本。

用例中的一些步骤代表决策点，在这些点上系统需要从参与者那里得到更多的信息。先给用例详述中的这些步骤编号，如图2-36所示。步骤旁的“A”表示该步骤需要执行来自参与者的反馈；“S”表示系统正执行那个动作。“E”表示该步骤是一个异常情况而不是正常过程的一部分。

一旦步骤被编号，就可以创建一棵树来描述用例所遍历的路径，如图2-37所示。

“评估贷款请求”用例显示了遍历系统的四条路经：

A1—S2—A3—A4—S5

A1—S2—A3—AE1

A1—S2—A3—AE2

A1—S2—A3—AE3

在这些路径中，第一条通向成功的结果，而另三条则通向不成功的结果。可以创建四个测试案例，每个测试案例测试一条路径。通向成功结果的测试案例称为积极测试案例（positive test case），其它三条称为消极测试案例（negative test case）。

图2-36“评估贷款申请”用例

图2-37 遍历“评估贷款申请”用例的路径图

2.1.4用例建模过程

用例建模不是一个线性的过程。随着用例建模工作的进行，用例有一个被发现、细化、重新考虑，重新完成和修改的过程。图2-38是一个用例建模过程框架。

图2-38 一个用例建模过程框架

用例建模过程中主要包括以下活动组：

●准备用例建模并确定建模方法。

?建立系统词汇的术语表。

?进行涉众分析；选择团队成员并且识别所涉及的客户和用户。

?选择及定制一个用例过程框架。

?选择用例建模标准、模板和工具。对粒度、语态和风格达成一致。

?确定培训和顾问的需求。

●进行初始用例建模

?创建初始用例模型图以及/或者语境图

?识别主要参与者。

?发现用例（初始用例详述描述）

?开始识别/精化候选的业务（领域）对象。

●扩展用例模型

?开发基本用例详述。

?迭代地细化基本用例详述并确定包含、扩展和泛化关系。

?将用例映射到对象模型。

?开发实例脚本。

●组织用例

?开发业务功能包。

?识别用例依赖流。

?根据涉众的观点组织用例。

?重构用例模型。

●持续进行的用例管理

?让用户确认用例模型。

?定义并执行测试案例。

?跟踪持续进行的用例建模进展。

?根据涉众的反馈更新并且定制框架。