第6章UML用例图

构建结构良好的用例图应做到：摆放元素时，应该避 免交叉线的出现；对于语义上接近的行为和角色，最 好使它们在物理上也更加接近；根据系统实际情况控 制粒度。
25
6.10 小
结
本章详细地阐述了参与者和用 例的概念，结合“ATM系统” 的用例图，讲解了系统边界、 包含关系、扩展关系以及泛化 关系，并在此基础上介绍了用 例描述的方法、格式及相关的 要点。
2
第6章 用 例 图
用例图描述了外部参与者所能 观察到的系统功能的模型图。
该图呈现了一些参与者和一些 用例，以及它们之间的关系。 用例图主要用于对系统、子系 统的功能行为进行建模。
3
6.1 什么是用例图
1．用例图
2．用例图的作用
3．用例图的组成元素
4
6.2 参与者与用例
多个用例组成一个系统， 参与者是系统外部的一个实 体，它以某种方式与系统交 互，请求系统执行用例，以 获得参与者需要实现的目标。
9
6.4 用例之间的关系
在需求分析时，当标识出参与者后， 下一步就是识别用例、组织用例。所 谓组织用例，就是首先识别用例之间 的关系，使系统中的用例构成一个用 例图。
UML有3种用例关系：包含、扩展和 泛化。下面将详细讨论这3种关系。
10
6.4.1 包含关系
在开发用例模型的过程中，我们会发现一些用 例包含了相同的一些行为；一些用例与其他用 例比较，多出了一些额外的行为。如图6-7所示， “取款”、“存款”、“查询余额”3个用例都 要求用户登录到ATM系统。
8
6.3.2 参与者之间的泛化关系
参与者是一种类，因此，可以 将参与者之间的关系进行泛化。 通过参与者泛化可以简化模型， 使模型更简洁。 例如，在软件系统开发过程中， 系统分析师(子类)和项目经理 (子类)都属于系统设计师(父 类)，他们都能承担系统设计 师的工作。用UML图表示他 们之间的关系，如图6-6所示。
主要参与者
次要参与者
……
……
前置条件
后置条件
成功保证
启动该用例所应该满足的条件
该用例完成之后，将执行什么动作 描述当前目标完成后，环境变化情况 步骤 活动 在这里写出触发事件到目标完成以及清除的步骤 ……(其中可以包含子事件流，以子事件流编号来表示) 1a表示是对1的扩展，其中应说明条件和活动 ……(其中可以包含子事件流，以子事件流编号来表示)
只有用例规格描述才对用例的详细执行流程进行了描 述。用例规格描述中的事件流描述了用例执行时的具 体流程。 为了让用户能够理解用例的执行过程和细节，我们使 用自然语言来描述用例的执行过程。但是，大多数专 家推荐使用用例模板来描述用例的详细信息。
18
6.7.1 事件流
事件流就是用例 执行时，由一系 列活动组成的控 制流。事件流分 为基本事件流和 扩展事件流两种。 事件流模型如图 6-16所示。
(1) (2) (3) (4) 系统支持哪些用户组完成他们的工作？ 哪一个用户组执行系统的主要功能？ 次要功能由哪一个用户组完成？比如维护或管理。 与该系统进行交互的外部硬件和软件系统是哪些？
在确定具体参与者时，可以通过以下一些常见的问题来帮 助分析：谁使用这个系统、谁安装这个系统、谁启动这个 系统、谁维护这个系统、谁关闭这个系统、谁也能使用这 个系统、谁从这个系统获取信息、谁为这个系统提供信息、 是否有事情自动在预计的时间发生(说明有定时器)、系统是 否需要与外部实体交互以帮助自己完成任务。 一旦参与者被标识出来后，需求获取的下一步活动决定了 每一个参与者将访问的功能。
5
6.2.1 参与者的表示
1．参与者的表示
2．参与者分类
(1) 按参与者本身的性质分类。
外部系统 硬件设备 时钟
(2)
按参与者的重要性分类。
主要参与者 次要参与者
3．参与者和角色
6
6.2.2 用例的表示
1．场景 2．用例的表示
7
6.3 参与者之间的关系
6.3.1 识别参与者
需求获取的第一步是寻找参与者。这一步定义了系统的边 界，并从开发者要考虑的系统中找出所有的参与者。开发 者通过回答下面问题来寻找参与者。
26
6.11 习
1．用例图由哪几部分组成？
题
2．什么是参与者？如何找出参与者？ 3．简述用例之间的关系，参与者之间的关系， 参与者与用例之间的关系。 4．在用例图中，参与者属于系统范围之内吗？ 5．用例和场景之间是什么关系？ 6．举例说明用例之间的扩展、泛化关系。
基本事件流
1 2
扩展事件流
子事件流 规则与约束
1a 1b
对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方 对该用例实现时需要考虑的业务规则、非功能需求、设计约束等
20
6.7.3 用例优先级
根据系统的规模，应该首先开发那些在架构上非常重 要的用例，其次，开发那些可选的或者重要性相对较 低的用例。 优先开发较高优先级用例的目的是尽可能早地降低风 险和不确定性，如根据对于成功完成系统的相对重要 性将用例排序。例如，如果系统包含了一些开发团队 不熟悉的技术，开发者就应该首先仔细检查并分析所 有设计该技术的用例，以减少不确定性。下面的因素 通常可能会提高用例的优先级。
12
6.4.2 扩展关系
如果两个用例相似，其中，A用例由 较小的行为集合构成，B用例由较大 的行为集合构成，B用例的行为集合 包含了A用例的行为集合，B用例减去 A用例的行为集合后，剩余部分在一 定条件下才执行。这时，我们可以把 A用例定义为基用例，把B用例中减去 A用例后的剩余部分定义为扩展用例。 例如，ATM系统中，当客户取款时， 若取款金额大于正常数额，这时， ATM系统就会调用“超额取款”用例。 用UML表示“超额取款”这种可选行 为。如图6-10所示。
用例在架构上的重要性。 使用了未经测试的新技术。 需要仔细研究的问题。 能够比较明显地提高业务处理效率(或者收益)。 支持主要业务过程的用例。
21
6.7.4 用例粒度
1．概述级
2．用户目标级
22
6.7.4 用例粒度
3．子功能级
23
6.8 用例描述实例
用例模板有各种格式。自20世纪 90年代早期以来，使用最为广泛 的格式是上 提供的模板，该模板由Alistair Cockburn创建，下面的用例描述 就是采用这种风格。
19
6.7.2 用例模板
用例编号 用例名称 用例概述
范 围 为用例制定一个唯一的编号，通常格式为UC+编号 应为一个动词短语，让读者一目了然地知道用例的目标 用例的目标，一个概要性的描述 用例的设计范围 该用例的主要参与者(Actor)，在此列出名称，并简要地描述它 该用例的次要参与者(Actor)，在此列出名称，并简要地描述它 项目相关人 项目相关人 利益说明 项目相关人员名称 利益 从该用例获取的利益
16
6.6 组 织 用 例
如图6-14所示给出了一部分ATM系统的用例模型。
如图6-15所示，将ATM系统分解为基本用例(取款、存 款和转账)和抽象用例(登录账户、超额取款)两类，三 个基本用例与“登录账户”用例是包含关系，“取款 “用例与“超额取款”用例是扩展关系。
17
6.7 用例规格描述
用例模型只关注系统的外部执行结果，它表示了系统 由哪些用例组成，以及用例具有的功能，用例模型显 示了系统能做什么以及谁使用系统。然而，用例并没 有描述系统具体执行的细节。
用例UC1：处理销售 参见教材P78
24
6.9 用例建模要点
构建结构良好的用例需做到以下4个方面。
(1) 为系统和部分系统中单个的、可标识和合理的原子 行为命名。 (2) 将公共的行为抽取出来，放到一个被包含用例中， 再将它<<include>>连接进来。 (3) 对于变化部分，将其抽取出来，放到一个扩展用例 (用<<extent>>连接)中。 (4) 清晰地描述事件流，使读者能够轻而易举地理解。
Hale Waihona Puke 146.5 参与者与用例之间的关系
参与者与用例之间是关联关系，表示了参与者 与用例间的通信，这里的通信是双向的。用一 条实线箭头表示，由参与者指向用例，如图613所示。
15
6.6 组 织 用 例
从用户的角度看，有的用例就是用户的最终目标，把 能实现用户目标的用例称为基本用例；把辅助用户实 现目标的用例称为抽象用例。 总之，基本用例是指那些对用户而言有价值的用例， 用户执行基本用例后能直接实现用户的目标；抽象用 例包括扩展用例和包含用例。 一旦识别出系统中的一组用例，就可以找到这组用例 中的公共行为。我们把这些公共行为从这组用例中抽 取出来，把它定义为抽象用例(包含用例或者扩展用 例)。这样，系统就由一组基本用例和抽象用例组成。 基本用例可以直接由参与者实例化，他本身可以实现 用户观测到的价值；抽象用例由基本用例实例化。因 此，从用户角度来看，抽象用例不能实现用户的完整 目标。
13
6.4.3 泛化关系
在UML中，用例的泛化关系和类图中的泛化关 系是一样的。用例的泛化就是指父用例的行为 被子用例继承或覆盖。泛化关系如图6-11所示。
例如，在ATM系统中，对于支付账单用例来说， 可以定义两个子用例，用例“支付账单”有两 个子用例“信用卡支付”和“现金支付”，如 图6-12所示。
11
6.4.1 包含关系
我们把公共行为从3个用例中抽 出，单独封装为“登录账户”用 例，这时，原先的3个用例就分 成了4个用例，如图6-8所示。 包含是指一个用例调用另一个用 例，被调用的用例称为包含用例， 调用包含用例的用例是基用例。 在UML中，用例间的包含关系用 构造型<<include>>表示，它是 指在基用例内部的某一个位置上 显式地调用另一个用例。在包含 用例关系中，箭头由基用例指向 包含用例。