3.3 用例图

用例图（Use Case Diagram）从用户角度描述系统功能，并指出各功能的操作者。用例图的主要目的是帮助开发团队以一种可视化的方式来理解系统的功能需求，用于系统分析阶段，即确定“谁使用系统以及能够做什么”。图3-2是某录像租赁系统的用例图。

在UML中，用例图由执行者、执行者之间的关系、用例、用例之间的关系以及执行者与用例间的关系组成。

图3-2 录像租赁系统用例图

3.3.1 执行者

执行者是指用户在系统中所扮演的角色，是系统以外透过系统边界与系统进行有意义交互的任何外部实体，它以某种方式参与了用例的执行过程。执行者可以是人，也可以是一个外界系统。执行者必须有唯一的名称或标识，在系统的实际运作中，一个实际用户可能对应系统的多个执行者，不同的用户也可以只对应一个执行者，从而代表同一执行者的不同实例。在用例图中，执行者用类似人形的图标表示。

执行者

面对一个复杂的系统，要找出所有的用例常常是很困难的，在这种情况下，需要先找出系统各种可能的执行者，然后通过对这些执行者的调查，为他们描述出各自要求的用例。在绘制用例图时，可以通过以下几个问题来确定系统的执行者。

·谁使用该系统？

·谁改变系统的数据？

·谁从系统获取信息？

·谁需要系统的支持以完成日常工作任务？

·谁负责维护、管理并保持系统正常运行？

·系统需要和哪些外部系统交互？

·谁对系统运行产生的结果感兴趣？

可以认为，对于电子商务系统而言，其执行者主要就是系统的用户，包括商务交易双方及支持交易的合作方。

3.3.2 执行者间的关系

当一个执行者的抽象描述可以被一个或多个具体的执行者共享，且后者还可以增加一些新的描述时，则定义前者为父执行者，后者为子执行者，这种父与子的关系也称作泛化关系（或继承关系）。泛化关系通常用带空心三角形箭头的实线表示，箭头指向父执行者，图3-3描述了某系统中执行者间的泛化关系。

图3-3 执行者间的泛化关系

3.3.3 用例

用例是系统的功能需求，描述了系统所执行的一组动作序列，从本质上讲，一个用例是一个或多个执行者与系统之间的一次交互，系统根据执行者的请求执行用例的一系列动作，或将执行结果反馈给执行者进行观察。用例通常具有以下特点。

·用例代表用户对系统的功能需求，能够实现用户对系统的目标。

·用例必须由执行者激活，并将执行的结果反馈给执行者。

·一个用例应该描述一个从头至尾完整的功能，即具有功能上的完整描述。

在用例图中，用例用椭圆表示，椭圆里面或下方标上用例的名字。用例代表了用户对系统的需求，在绘制用例图时，可以通过以下几个问题来确定系统的用例。

·执行者希望系统提供什么功能？

·系统是否存储和检索信息？如果是，这个行为由哪个执行者触发？

·当系统改变状态时，通知执行者吗？

·存在影响系统的外部事件吗？

·是哪个执行者通知系统这些事件？

3.3.4 用例间的关系

用例之间存在着一定关系，包括泛化关系（继承关系）、包含关系和扩展关系。

1.泛化关系（Generalization Association）

用例间的泛化关系是指一个用例可以被列举为一个或多个子用例，这种关系也称作父子关系。子用例继承父用例的行为和含义，还可添加新行为或覆盖父用例的行为，当父用例能够被使用时，任何子用例也可以被使用。用例间的泛化关系也是用带空心三角形箭头的实线表示，箭头从子用例指向父用例。如图3-4a所示，订票与网上订票、订票与电话订票用例之间存在泛化关系，显然订票是父用例，网上订票和电话订票是子用例。

图3-4 用例间的泛化、包含和扩展关系

a）泛化关系 b）包含关系 c）扩展关系

2.包含关系（Include Association）

用例间的包含关系是指一个用例的行为包含了另一个用例具有的行为，并把它所包含用例的行为作为自身行为的一部分，前者称为基本用例，后者称为包含用例。用例间的包含关系是用一条从基本用例指向包含用例的虚箭线表示，箭头上方标明《include》关系。如图3-4b所示，管理价格用例包含涨价、降价和打折3个用例。

3.扩展关系（Extend Association）

用例间的扩展关系用于说明用例间可选的、只在特定条件下运行的行为关系。例如当用例B是用例A执行过程中的某一个步骤，但只在满足特定条件下才插入到A定义的行为中时，A、B之间的关系称作扩展关系，其中A是基本用例，B是扩展用例。一般一个基本用例在以下几种情况下可以使用扩展用例。

·基本用例的某一部分是可选的系统行为。

·基本用例存在只在特定条件下才执行的分支行为流。

·存在一组行为，其中的一个或多个部分可以插入到基本用例的行为中，插入的位置及顺序取决于基本用例与执行者的具体交互内容。

用例间的扩展关系是用一条从扩展用例指向基本用例的虚箭线表示，箭头上方标明《extend》关系。如图3-4c中给出了一个扩展关系的例子，在还书的过程中，只有当遗失或损坏书籍时，才会执行赔偿书籍的行为流。

3.3.5 执行者与用例间的关系

当执行者与用例存在使用、传递数据、获取信息等交互时，定义它们之间的这种关系为关联关系，执行者与用例间的关联关系用一条实线表示。如图3-5所示，客户可以通过在系统中输入数据进行注册，则执行者“客户”和用例“注册”之间存在关联关系。

图3-5 执行者与用例间的关联关系

3.3.6 用例文档

用例图描述了系统有哪些用例，但没有指明用例所对应的功能是如何实现的，而用例文档则是通过文字来描述一个用例的行为，说明用例的逻辑流程。用例文档没有固定的格式，但关于用例的一些基本或重要的内容必须进行描述，一般包括用例名称、执行者、简要说明、基本事件流、其他事件流及异常事件流等。

简要说明：对用例的主要功能进行简要描述。

基本事件流：描述用例在正常情况下的基本事件流程。

其他事件流：描述用例执行过程中可行或备选的事件流程，该事件流不一定要被执行。

异常事件流：描述用例执行过程中可能发生的非正常事件流程。

用例文档主要用于对一些存在较多异常情况的用例进行描述，并不是每一个用例都要编写用例文档，表3-1是某系统为会员设置的“找回密码”用例的用例文档。

3.3.7 建立用例图的步骤

一般来说，建立用例图的步骤为：

1）确定系统的执行者及其之间的关系。

2）根据执行者确定系统的用例及其之间的关系。

3）确定用例与执行者间的关系。

4）绘制并优化用例图。

5）编写用例文档。

表3-1 “找回密码”的用例文档

案例3-1

银行ATM系统是安装在自助服务终端供客户使用的自助处理系统，客户可以通过该系统自主完成一些常见的账户处理业务。系统提供的主要功能包括客户登录、退出、修改密码、查询账户、取款、存款、转账和缴费，其中查询账户时可以只查询余额也可查询某一时间段的交易明细，转账业务可以实现同行转账和跨行转账两种方式，缴费的种类包括电费、水费和通讯费。取款、存款、转账和缴费业务完成后可以根据需要打印交易凭单。

根据银行ATM系统所提供的功能可绘制如图3-6所示的系统用例图，系统的执行者是客户，它和登录、退出、修改密码、查询、取款、存款、转账、缴费这8个用例间存在关联关系；“查询”用例包含“查询余额”和“查询明细”两个子用例；“转账”用例包含“同行转账”和“跨行转账”两个子用例；“缴费”用例包含“缴纳电费”、“缴纳水费”及“缴纳通讯费”3个子用例；缴费、取款、存款和转账4个用例与打印凭单用例之间是扩展关系。

图3-6 银行ATM系统用例图