6．4．6　用例图

用例图被称为系统的外部用户所能观察到的系统功能的模型图，呈现了参与者和用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。用例图用于从用户角度描述系统功能，并指出各功能的操作者。对于系统开发人员来说，用例图是一个非常有价值的工具，用于从用户的观察视角来收集系统的需求是非常有效的。用例图是由参与者、用例及它们之间的关系构成的用于描述系统功能的视图。

用例建模的基本步骤是：确定参与者；确定用例；用例描述；用例正确性和完整性检查。

1．确定参与者

参与者是在系统外部与系统交互的人或事物，它以某种方式参与系统内用例的执行。它既可以是使用该系统的用户，也可以是与系统交互的其他外部系统、硬件设备或组织机构，甚至是时间等。在UML中，参与者用一个人形符号来表示，并具有唯一的名字。参与者之间可以存在泛化关系。

参与者的特性包含：参与者位于系统（边界）之外，而不是系统的一部分；参与者表示人或事物与系统交互时所扮演的角色，而不是特定的人或事物。

在获取用例之前，先要确定系统的参与者。在寻找过程中，可以询问如下问题帮助确定参与者。

（1）谁使用系统的主要功能？

（2）谁改变系统的数据？

（3）谁从系统获取数据？

（4）谁负责支持和维护系统？

（5）谁对系统运行结果感兴趣？

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

（7）系统需要和哪些外部系统交互？

（8）系统需要控制哪些外部资源或硬件设备？

通常，凡是直接使用系统的人都可以确定为参与者。另外，在对参与者的建模过程中，除了需要关注参与者的特性外，还应注意：每个参与者应有简短的描述，从业务角度描述参与者是什么；参与者可以有属性和操作。

2．确定用例

1）用例需考虑的问题

接下来检查所有的参与者，并为每个参与者确定用例。用例需考虑以下问题：

（1）参与者希望系统提供什么样的功能？

（2）系统存储信息吗？参与者将要创建、读取、更新或删除什么信息？

（3）系统是否需要把自身内部状态的变化通知给参与者？

（4）系统必须知道哪些外部事件？参与者将怎么通知系统有这些事件？

（5）其他需要考虑的用例包括启动、关闭、诊断、安装、培训和改变业务过程。

2）用例的特点

用例定义了一组用例实例，其中每个实例都是系统执行的一系列动作，这些动作最终对参与者产生有价值的可观察结果。用例的特点如下。

（1）用例由一组实例组成。

（2）用例从使用系统的角度描述系统中的信息，即站在系统外部察看系统功能，而不考虑系统内容对此功能的具体实现。

（3）用例描述了用户提出的一些可见需求，对应一个具体的用户目标，即用例的执行结果对参与者是有意义的。例如，登录系统是一个有效的用例，但输入密码却不是，因为单纯的输入密码是没有意义的。

（4）用例是对系统行为的动态描述，属于动态建模部分。

（5）用例总是由参与者发起的，参与者的愿望和需求是用例存在的原因，不存在没有参与者的用例。

3）用例之间的关系

在UML中，用例用一个椭圆来表示，并具有唯一的名字。用例名使用动宾结构或主谓结构命名，描述其功能或服务的含义。用例之间可以存在泛化关系、包含关系和扩展关系。

（1）一个用例可以被列举为一个或多个子用例，这些特性称为用例泛化。泛化关系的三角箭头由子用例指向父用例。

（2）包含关系是指当多个用例中存在相同事件流时，可以把这些公共事件流抽象成为公共用例，这个公共用例称为抽象用例，而原始用例称为基本用例。基本用例和抽象用例之间是包含关系。在UML中，包含关系表示为虚线箭头加版型include，箭头从基本用例指向抽象用例。

（3）扩展关系表示基本用例在由扩展用例间接说明的一个位置上隐式地合并了另一个用例（扩展用例）的行为。在UML中，扩展关系表示为虚线箭头加版型extend，箭头从扩展用例指向基本用例。

3．用例描述

采用文本描述用例的详细内容。用例描述应当包括以下项目。

（1）简要说明：简要介绍该用例的作用和目的。

（2）事件流：包括基本流和备选流，事件流应该表示所有的场景。

（3）用例场景：包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。

（4）前置条件：执行用例之前系统必须所处的状态。

（5）后置条件：用例执行完毕后系统可能处于的一组状态。

4．用例正确性和完整性检查

一个确认用例划分的简单方法是运用“WAVE”测试。

W（What to do）：用例是否描述了应该做什么，而不是如何做？

A（Actor’s point of view）：用例的描述是否采取了参与者的视角？

V（Value for the actor）：用例是否对参与者有价值？

E（Entire scenario）：用例描述的事件流是否是一个完整场景？

例6－1 阅读下列说明和图，回答问题1至问题3，将解答填入答题纸的对应栏内。

【说明】 Pay ＆Drive系统（开多少付多少）能够根据驾驶里程自动计算应付的费用。

系统中存储了特定区域的道路交通网的信息。道路交通网由若干个路段（RoadSegment）构成，每个路段由两个地理坐标点（Node）标定，其里程数（Distance）是已知的。在某些地理坐标上安装了访问控制（Access Control）设备，可以自动扫描行驶卡（Card）。行程（Trajectory）由一组连续的路段构成。行程的起点（Entry）和终点（Exit）都装有访问控制设备。

系统提供了3种行驶卡：常规卡（RegularCard）的有效期（Valid Period）为一年，可以在整个道路交通网内使用；季卡（SeasonCard）的有效期为3个月，可以在整个道路交通网内使用；单次卡（MinitripCard）在指定的行程内使用，且只能使用一次。其中，季卡和单次卡都是预付卡（PrepaidCard），即需要客户（Customer）预存一定的费用。

系统的主要功能有用户注册、申请行驶卡、使用行驶卡行驶等。

使用常规卡行驶，在进入行程起点时，系统记录行程起点、进入时间（Date of Entry）等信息。当到达行程终点时，系统根据行驶的里程数和所持卡的里程单价（Unit Price）计算应付费用，并打印费用单（Invoice）。

季卡的使用流程与常规卡类似，但是不需要打印费用单，系统自动从行驶卡中扣除应付费用。

单次卡的使用流程与季卡类似，但还需要在行程的起点和终点上检查行驶路线是否符合该卡所规定的行驶路线。

现采用面向对象方法开发该系统，使用UML进行建模，构建出的用例图和类图分别如图6－16和图6－17所示。

图6－16　用例图

（1）根据说明中的描述，给出图6－16中U1和U2对应的用例，以及（1）处对应的关系。

（2）根据说明中的描述，给出图6－17中缺少的C1～C6对应的类名及（2）～（3）处对应的多重度（类名使用说明中给出的英文词汇）。

（3）根据说明中的描述，给出RoadSegment、Trajectory和Card对应的类的关键属性（属性名使用说明中给出的英文词汇）。

分析

（1）用例图的构成要素有参与者、用例、用例之间的关系。图中缺少两个用例和一个用例关系。首先，应从说明中找到所有的用例。从题目描述可知，系统的主要功能是申请行驶卡和使用行驶卡行驶。由于行驶卡分为3种，再结合用例图来看，缺少的两个用例与“使用季卡行驶”用例都有关联关系。由此可推断出，要补充的两个用例必定与另外两种行驶卡相关，分别为“使用单次卡行驶”和“使用常规卡行驶”。又因为U1和“使用季卡行驶”是泛化关系，U1是父用例，根据说明中的“季卡的使用流程与常规卡类似，但是不需要打印费用单，系统自动从行驶卡中扣除应付费用”可知，U1应填用例“使用常规卡行驶”，U2应填“使用单次卡行驶”。

图6－17　类图

用例之间的关系有泛化关系、包含关系和扩展关系。（1）处填extend最为合适。

（2）需要补充的类基本上集中在聚集结构（类C1和C2）和泛化结构（类C3～C6）。SeasonCard和C6是C5的子类，由说明中可知，“系统提供了3种卡：常规卡（RegularCard）、季卡（SeasonCard）、单次卡（MinitripCard）”，而“季卡（SeasonCard）和单次卡（MinitripCard）都是预付卡（PrepaidCard）”。因此，C5和C6分别是预付卡（PrepaidCard）和单次卡（MinitripCard）。C4和C5是C3的子类，所以，C4是常规卡（RegularCard），而C3是能代表所有这几种行驶卡的公共概念，C3是行驶卡（Card）。由说明中的“行程（Trajectory）由一组连续的路段构成”可知，C1和C2分别是路段（RoadSegment）和行程（Trajectory）。

Customer和Card之间的多重性可由说明中“系统中只有3种卡”可知，“一个用户最多只能有3种卡”，所以（3）处应填1．．3。而对于任意一张卡来说，只能有唯一的一个所属人，所以（2）处应填1。

（3）本问题考查类的关键属性的识别。由说明中给出的描述可知，类RoadSegment的属性至少应包括Distance；类Trajectory的属性至少应包括Entry、Exit和DateOfEntry；类Card的属性至少应包括UnitPrice、ValidPeriod。

解

（1）U1对应的用例为使用常规卡行驶，U2对应的用例为使用单次卡行驶，（1）处对应的关系为extend。

（2）C1对应的类名为RoadSegment，C2对应的类名为Trajectory，C3对应的类名为Card，C4对应的类名为RegularCard，C5对应的类名为PrepaidCard，C6对应的类名为MinitripCard，（2）处对应的关系为1，（3）处对应的关系为1．．3。

（3）RoadSegment的属性有Distance，Trajectory的属性有Entry、Exit、DateOfEntry，Card的属性有UnitPrice、ValidPeriod。