用例包含关系
1.1 指南：包含关系
主题
∙
解释 ∙
执行包含 ∙
描述包含关系 ∙ 使用示例
1.1.1 解释
基本用例通过包含关系连接到包含用例。
包含用例总是抽象的。
它描述在执行基本用例的用例实例中插入的行为段。
基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但基本用例和包含用例都不能访问对方的属性。
从这种意义上讲，包含用例是被封装的，它代表可在各种不同基本用例中复用的行为。
您可以将包含关系用于：
∙
从基本用例中分解出这样的行为：它对于了解基本用例的主要目的并不是必需的，只有它的结果才比较重要。
∙ 分解出两个或更多个用例所共有的行为。
示例：
在 ATM 系统中，用例 Withdraw Cash （提款）、Deposit Cash （取
款）和 Transfer Funds （转账）都需要包含系统识别客户的方式。
可以将此行为抽取到一个名为 Identify Customer （识别客户）的
新包含用例中，这三个基本用例都包含此用例。
这些基本用例独立
于用于标识的方法，因此将此方法封装在包含用例中。
从基本用例
的角度来看，标识方法是否会读取银行磁卡或执行视网膜扫描并不
重要。
它们仅依赖于 Identify Customer 的结果，即客户的身份。
反之亦然，从 Identify Customer 用例的角度来看，基本用例如
何使用客户身份或者在执行包含用例之前基本用例中发生了什么
并不重要：标识方法都会完全相同。
在ATM 系统中，用例Withdraw Cash、Deposit Cash 和Transfer
Funds 中都包含用例Identify Customer。
一个基本用例可以有多个包含用例。
一个包含用例可以包含在若干基本用例中。
这并不表示这些基本用例之间存在任何关系。
甚至同一个包含用例和同一个基本用例之间可以有多个包含关系，前提是包含用例必须在基本用例中的不同位置插入。
而包含关系就定义了插入的位置。
添加的所有用例都可以是嵌套的，这意味着一个包含用例可以用作另一个包含用例的基本用例。
由于包含用例是抽象的，因此它不需要有与它相关的主角。
只有当包含用例中的行为明确地涉及到与主角的交互时，才需要与主角的通信关联关系。
1.1.2执行包含
包含用例的行为插入到基本用例中的一个位置。
当遵循基本用例说明的用例实例到达基本用例中定义了包含关系的位置，它就将改而遵循包含用例的说明。
一旦执行完包含用例，用例实例就将在基本用例中它先前停止的地方重新开始。
遵循基本用例（包含了包含用例）说明的用例实例。
包含关系是无条件的：如果用例实例到达基本用例中定义了包含关系的位置，就总会执行包含。
如果要表达条件，就需要将其作为基本用例的一部分来表达。
如果用例实例无论如何也不能到达定义了包含关系的位置，则不会执行包含。
用例实例#1 到达基本用例中定义了包含关系的位置，并执行包含。
用
例实例#2 没有到达该位置，因此包含不会作为该实例的一部分来执
行。
包含用例是一个连续的行为段，所有这些行为都包含在基本用例的一个位置中。
如果您需要将一些行为段分别插入不同位置，就应考虑使用扩展关系（请参见指南：扩展关系）或用例泛化关系（请参见指南：用例泛化关系）。
1.1.3描述包含关系
对于包含关系，您应在基本用例的行为序列中定义要插入包含用例的位置。
要定义该位置，可以引用基本用例事件流中的特定步骤或分支流。
示例：
在 ATM 系统中，用例 Withdraw Cash 包含用例 Identify
Customer。
从 Withdraw Cash 到 Identify Customer 的包含关系
可以如下描述：
Identify Customer 插入到 Withdraw Cash 事件流中的“1.1 用
例开始”部分和“1.2 询问金额”部分之间。
为清晰起见，您还应在描述基本用例事件流的文本中提及包含用例。
1.1.4使用示例
如果基本用例中有一个行为段，在那里您可以看到用例不依赖于执行方式，但依赖于功能的结果，那么您就可以将此行为抽取到一个包含用例中，以简化该基本用例。
包含用例可以包含在多个基本用例中，所以您可以在模型的多个用例中复用行为。
对于一个简单电话系统的两个用例，可考虑以下分步概述：
Place Call（打电话）
1.呼叫方拿起听筒。
2.系统发出拨号音。
3.呼叫方拨打一位数字。
4.系统结束拨号音。
5.呼叫方输入电话号码的其余数字。
6.系统对数字进行分析，确定接收方的网络地址。
7.系统确定是否可以在呼叫方与接收方之间建立虚拟通路。
8.系统为虚拟通路分配所有资源并建立连接。
9.系统让接收方的电话振铃。
10.等等。
Start System（启动系统）
1.接线员激活系统。
2.系统对所有构件执行诊断测试。
3.系统对与所有相邻系统的连接进行测试。
对于每个相邻系统，系统确定是否可以在
自身与该相邻系统之间建立一个虚拟通路。
系统为虚拟通路分配所有资源并建立
连接。
4.系统作出响应，表示它已准备好执行操作。
5.等等。
以上列出的蓝色文本极为相似。
在这两种情况下，尽管行为的目的极其不同，我们执行的却是相同的行为。
这种相似性是可以利用的，我们可以将共同的行为抽取到新的用例 Manage Virtual Circuits（管理虚拟通路）中。
当抽取出共同行为后，这两个用例就变成：
Place Call
1.呼叫方拿起听筒。
2.系统发出拨号音。
3.呼叫方拨打一位数字。
4.系统结束拨号音。
5.呼叫方输入电话号码的其余数字。
6.系统对数字进行分析，确定接收方的网络地址。
7.包含Manage Virtual Circuit 用例，在网络中建立连接。
8.系统让接收方的电话振铃。
9.等等。
Start System
1.接线员激活系统。
2.系统对所有构件执行诊断测试。
3.系统对与所有相邻系统的连接进行测试。
对于每个相邻系统（回路），包含Manage
Virtual Circuit，在网络中建立连接。
4.系统作出响应，表示它已准备好执行操作。
5.等等。
在用例图中，已创建的包含关系将如下所示：
用例Place Call 和Start System 都包含有抽象用例Manage Virtual
Circuit 的行为。
用例之间的关系
3.4用例之间的关系1、泛化关系Generalization代表一般与特殊的关系。
（类似于继承）在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。
例子：一个租赁或销售系统用例的部分内容，在此，父用例是“预定”，其两个子用例分别是“网上预定”和“电话预定”，这两个用例都继承了父用例的行为，并可以添加自己的行为。
2、包含关系Include一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。
在UML中，包含关系表示为虚线箭头加版型《include》，箭头从基本用例指向包含用例。
例子：一个租赁或销售系统中，“填写电子表格”的功能在“网上预定”的过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。
3、扩展关系Extend一个用例也可以定义为基本用例的增量扩展，这称作扩展关系，即扩展关系是把新的行为插入到已有的用例中的方法。
在UML中，包含关系表示为虚线箭头加版型《extend》，箭头从扩展用例指向基本用例。
基本用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例的扩展点上。
扩展关系可以有控制条件，当用例实例执行到达一个扩展点时，控制条件决定是否执行扩展。
一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。
同一个基本用例的几个扩展可以在一起使用。
基本用例不知道扩展的任何细节.没有扩展用例,基本用例是完整的。
例子：一个汽车租赁系统用例图的部分内容。
在此，基本用例是“还车”，扩展用例是“交纳罚金”。
如果一切顺利汽车可以被归还，那么执行“还车”用例即可。
但是如果超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提供的常规动作。
用例之间的关系
3、4用例之间得关系1、泛化关系Ｇｅneralｉzａｔioｎ代表一般与特殊得关系。
（类似于继承）在用例泛化中，子用例表示父用例得特殊形式，子用例继承了父用例得行为与属性，也可以增加新得行为与属性或覆盖父用例中得行为。
例子：一个租赁或销售系统用例得部分内容，在此,父用例就是“预定",其两个子用例分别就是“网上预定”与“电话预定”,这两个用例都继承了父用例得行为,并可以添加自己得行为。
2、包含关系Inｃluｄe一个用例（基用例,基本用例）可以包含其她用例(包含用例）具有得行为，并把它所包含得用例行为作为自身用例得一部分，这被称为包含关系.在UML中，包含关系表示为虚线箭头加版型《inｃludｅ》，箭头从基本用例指向包含用例。
例子：一个租赁或销售系统中，“填写电子表格”得功能在“网上预定”得过程中使用，不管如何处理“网上预定”用例，总就是要运行“填写电子表格”用例,因此具有包含关系.3、扩展关系Extenｄ一个用例也可以定义为基本用例得增量扩展,这称作扩展关系,即扩展关系就是把新得行为插入到已有得用例中得方法。
在ＵML中,包含关系表示为虚线箭头加版型《eｘtｅnｄ》,箭头从扩展用例指向基本用例。
基本用例提供了一组扩展点，在这些新得扩展点中可以添加新得行为,而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例得扩展点上.扩展关系可以有控制条件,当用例实例执行到达一个扩展点时，控制条件决定就是否执行扩展。
一般情况下,基本用例得执行不会涉及到扩展用例，只有满足用例得控制条件时,扩展用例才被执行，因此扩展关系处理事件流得异常或者可选事件。
同一个基本用例得几个扩展可以在一起使用。
基本用例不知道扩展得任何细节、没有扩展用例，基本用例就是完整得。
例子：一个汽车租赁系统用例图得部分内容。
在此，基本用例就是“还车"，扩展用例就是“交纳罚金”。
如果一切顺利汽车可以被归还,那么执行“还车"用例即可。
简述用例模型的组成元素以及建模步骤
简述用例模型的组成元素以及建模步骤用例模型是软件开发中重要的一环，它是对软件系统功能需求的描述，是从用户的角度出发，描述系统应该具有的功能和行为。
用例模型的建立对于系统开发和维护非常重要，因此，本文将对用例模型的组成元素和建模步骤进行简述。
二、用例模型的组成元素用例模型是由用例、参与者、系统边界和关系图等组成的。
1.用例用例是描述系统功能需求的一种方式，它描述了系统中某个功能或一组功能的行为和交互。
用例是从用户的角度出发，描述了用户与系统之间的交互过程。
用例可以分为主用例和子用例，主用例是整个系统中最重要的用例，而子用例是主用例的拓展和细化。
2.参与者参与者是使用系统的人或其他系统。
参与者可以是人类用户、硬件设备、其他软件系统等。
参与者与系统之间的交互是通过用例进行的。
参与者可以分为主要参与者和次要参与者，主要参与者是对系统设计和实现有重要影响的参与者，次要参与者是对系统设计和实现没有重要影响的参与者。
3.系统边界系统边界是用例模型中的一个重要概念，它定义了系统的范围。
系统边界将系统与外部环境分开，系统内部的所有用例和参与者都在系统边界内部。
4.关系图关系图是用例模型的另一个重要组成部分，它描述了用例之间的关系。
关系图可以分为三种类型：包含关系、泛化关系和依赖关系。
包含关系表示一个用例包含另一个用例，泛化关系表示一个用例是另一个用例的特殊情况，依赖关系表示一个用例依赖于另一个用例。
三、用例模型的建模步骤用例模型的建模步骤可以分为以下几个步骤：1.确定系统的范围和边界在建立用例模型之前，需要先确定系统的范围和边界。
系统的范围和边界定义了系统的功能和行为，同时也决定了用例模型的规模和复杂度。
2.识别参与者和用例在确定系统的范围和边界之后，需要识别参与者和用例。
参与者是使用系统的人或其他系统，用例是描述系统功能需求的一种方式。
3.编写用例规约用例规约是用例模型的核心，它描述了用例的输入、输出和行为。
用例规约包括用例的前置条件、后置条件、基本流程和异常流程。
用例之间的关系
例子
一个汽车租赁系统用例图的部分内容。在此，基本
用例是“还车”，扩展用例是“交纳罚金”。如果 一切顺利汽车可以被归还，那么执行“还车”用例 即可。但是如果超过了还车的时间或汽车受损，按 照规定客户要交纳一定的罚金，这时就不能执行提 供的常规动作。若研讨修改用例“还车”，势必会 增加系统的复杂性，因此可以在用例“还车”中增 加扩展点，即特定条件为超时或损坏，如果满足条 件，将执行扩展用例“交纳罚金”，这样显然可以 使系统更容易被理解。
用例之间的关系
在画用例图的时候，理清用例之间的关系是重 点。用例的关系有泛化(generalization)、扩展 (extend)和包含(include)。其中include和 extend最易混淆。 使用关系uses(UML1.2以后已经不再使用此关 系） 下面我们结合实例彻底理清三者的关系。
基本概念
包含(include)
include为包含关系，当两个或多个用例中共用一组
相同的动作，这时可以将这组相同的动作抽出来作 为一个独立的子用例，供多个基用例所共享。因为 子用例被抽出，基用例并非一个完整的用例，所以 include关系中的基用例必须和子用例一起使用才 够完整，子用例也必然被执行。include关系在用例 图中使用带箭头的虚线表示(在线上标注 <<include>>)，箭头从基用例指向子用例。
泛化关系是一种继承关系，子用例将继承基
用例的所有行为，关系和通信关系，也就是 说在任何使用基用例的地方都可以用子用例 来代替。泛化关系在用例图中使用空心的箭 头表示，箭头方向从子用例指向基用例。
在用例泛化中，子用例表示父用例的特殊形式，子用例继承了 父用例的行为和属性，也可以增加新的行为和属性或覆盖父用 例中的行为。
用例之间的三种关系
用例之间的三种关系
用例是指为了验证某种特定目的或功能而实际执行的一组任务或
活动。
在软件工程中，用例可以用来描述需求，是需求分析的一个重要输入。
在需求分析阶段，用例描述了系统必须满足的所有功能和行为，以确保系统的正确性和稳定性。
用例之间的关系有三种：包含、扩展和泛化。
1.包含关系：一个用例可以包含在另一个用例中，例如一个用例可以包含在另一个用例的实现中。
这种关系通常用于描述用例之间的依赖关系，即一个用例的实现依赖于另一个用例的实现。
2.扩展关系：一个用例可以扩展另一个用例的行为，即一个用例的行为可以在另一个用例的基础上进行扩展。
例如，一个用例可以扩展另一个用例的功能，或者一个用例可以在另一个用例的基础上添加新的行为。
3.泛化关系：一个用例可以泛化到其他用例的行为中，即一个用例的行为可以适用于其他用例的情况。
例如，一个用例可以泛化到其他用例的功能中，或者一个用例可以在其他用例的基础上进行修改和扩展。
总之，用例是软件需求分析中的重要输入，用例之间的关系可以描述用例之间的依赖关系和扩展关系。
通过正确理解用例之间的关系，可以帮助开发人员更好地理解系统的需求，并确保系统的正确性和稳定性。
用例间的关联(泛化-包含-扩展)
用例间的关系
12
用例间➢销户：因为销户必需先进行账户结算，所以这里用include ➢停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend
14
用例间的关联
(泛化/包含/扩展)
§3.2.2 用例图的组成
3）用例与用例的关联
用例之间也可存在关联。这些关联包括： •泛化关联 •包含关联 •扩展关联
此外，系统分析员也可以利用UML的扩充机制自定义用例 的关联。
2
用例间的关系
用例与用例的泛化关联用来表示一般用例与特殊用例的泛化 关系。在UML图中，使用带空心三角箭头的实线表示。如下图所 示：
（1）B通常是A和C 中共同操作部分抽象出的部分 （2）B是A的子过程为了避免太复杂单独抽象出来的部分
➢A extend B 表示B是A在系统某些情况下（特定条件）触发产 生的，B不是A中必须存在的部分，B可以单独存在 ➢B是对A在一些基本功能上具体的扩展（在A的扩展点处）
9
用例间的关系
➢Include 包含关系通常发生在多个用例中，有可以提取出来 的公共部分（就象提取公因式一样） ➢例如 UseCaseA 中包括了 a 和 b 两个流程，而 UseCaseC 中 包含了 c 和 b 两个流程。为了提高复用性，可以把 b 提取出来， 形成另一个用例 UseCaseB，此时，UseCaseA include UseCaseB，UseCaseC 也 include UseCaseB。 ➢当有 include 关系时，被 include 的用例通常会被两个以上的 其他用例 include（否则就不需要提取出来了）
3
用例间的关系
用例与用例的包含关联用来表示一个用例中重用另一个用 例中的步骤．在UML图中，使用带虚线箭头表示，并在线上标有 构造型<<include>>。如下图所示：
用例图中的关系（一）
⽤例图中的关系（⼀）⼀、⽤例图概述⽤例图，是⼀种客户与开发者之间可以沟通、理解的表现形式。
可以认为⽤例图是开发者与客户之间的可视化契约。
我认为最主要的⼀点就是，在这个⽤例模型中，⼀直是以⽤户的⾓度为主的，做为开发⼈员也要时刻站在⽤户的⾓度来看待整个系统。
从原则上来讲，⽤例之间都是独⽴、并列的，它们之间并不存在着包含从属关系。
但是为了体现⼀些⽤例之间的业务关系，提⾼可维护性和⼀致性，⽤例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)⼏种关系。
共性：都是从现有的⽤例中抽取出公共的那部分信息，作为⼀个单独的⽤例，然后通后过不同的⽅法来重⽤这个公共的⽤例，以减少模型维护的⼯作量。
⼆、⽤例图中的四个基本组件⽤例图包括：参与者或⾓⾊（actor）、⽤例（use case)、关系、系统。
1、参与者：是系统外的⼀个实体，它以某种⽅式参与⽤例我执⾏过程。
参与者通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏，所以参与者可以是⼈，可以是事物，可以是时间、⽓压等环境因素或者其他系统等。
它在系统之外，与系统直接交互。
⽤⼀个群体概念给参与者命名，反映该参与者的⾝份与⾏为（如客户、管理员等）。
2、⽤例：⽤例代表系统的某项完整的功能，是动作步骤的集合。
系统的功能是通过参与者使⽤⽤例来实现的。
在这⾥，我们把⽤例看做是⼀个“⿊盒”，只反映的是系统的⼀项功能，不涉及实现细节。
⽤例的命名：⽤例是从⽤户的⾓度来描述系统的功能，也就是从参与者的⾓度出发进⾏命名（如，使⽤“登录”，⽽不⽤“⾝份验证“）。
还有，⽤例最好使⽤⾏业专业术语。
3、关系：除了参与者与⽤例之间的关联关系外，还可以定义参与者之间的泛化关系，⽤例之间的包含、泛化与扩展关系。
应⽤这些关系的⽬的是从系统中抽取出公共⾏为及其变体。
4、系统：系统指⼀个软件系统、⼀项业务、⼀个商务活动、⼀台机器等等。
系统的功能通过⽤例来表现，换句话说，就是所有的⽤例构成了整个系统。
UML建模——用例图（UseCaseDiagram）
UML建模——⽤例图（UseCaseDiagram）⽤例图主要⽤来描述⾓⾊以及⾓⾊与⽤例之间的连接关系。
说明的是谁要使⽤系统，以及他们使⽤该系统可以做些什么。
⼀个⽤例图包含了多个模型元素，如系统、参与者和⽤例，并且显⽰这些元素之间的各种关系，如泛化、关联和依赖。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⼀、⽤例图所包含的的元素1. 参与者(Actor)——与应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case)——⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem)——⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
⼆、⽤例图所包含的的关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：⽆箭头，将参与者与⽤例相连接，指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
在实际应⽤中很少使⽤泛化关系，⼦⽤例中的特殊⾏为都可以作为⽗⽤例中的备选流存在。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
包含关系对典型的应⽤就是复⽤，也就是定义中说的情景。
但是有时当某⽤例的事件流过于复杂时，为了简化⽤例的描述，我们也可以把某⼀段事件流抽象成为⼀个被包含的⽤例；相反，⽤例划分太细时，也可以抽象出⼀个基⽤例，来包含这些细颗粒的⽤例。
这种情况类似于在过程设计语⾔中，将程序的某⼀段算法封装成⼀个⼦过程，然后再从主程序中调⽤这⼀⼦过程。
请描述构建用例模型的过程
请描述构建用例模型的过程
用例模型是软件开发中的一种重要模型，它描述了系统的功能需求和用户与系统之间的交互过程。
构建用例模型的过程可以分为以下几个步骤：
1. 确定系统边界和参与者
首先需要确定系统的边界，即系统与外部环境的交互界面。
然后需要确定参与者，即与系统交互的各种角色，如用户、管理员等。
2. 确定用例
在确定系统边界和参与者后，需要确定系统的各种功能需求，即用例。
用例是描述系统功能的一种方式，它描述了系统如何响应参与者的请求。
3. 编写用例描述
用例描述是用例的详细说明，它包括用例名称、参与者、前置条件、基本流程、备选流程和后置条件等内容。
用例描述需要清晰明了，以便开发人员和测试人员能够理解和执行。
4. 确定用例之间的关系
在确定了各个用例后，需要确定它们之间的关系。
用例之间的关系
可以分为包含关系、扩展关系和泛化关系等。
包含关系表示一个用例包含另一个用例，扩展关系表示一个用例可以扩展另一个用例，泛化关系表示一个用例是另一个用例的特殊情况。
5. 绘制用例图
用例图是用例模型的图形表示，它包括系统边界、参与者和用例等元素。
用例图可以帮助开发人员和测试人员更好地理解系统的功能需求和用户与系统之间的交互过程。
构建用例模型是软件开发中非常重要的一步，它可以帮助开发人员和测试人员更好地理解系统的功能需求和用户与系统之间的交互过程，从而更好地完成软件开发任务。
用例的三种关系
用例的三种关系用例是软件开发中的重要组成部分，用于描述系统与用户之间的交互。
在用例分析的过程中，我们需要了解用例之间的关系，以便更好地理解系统功能和需求。
用例的关系可以分为三种：包含关系、扩展关系和泛化关系。
1. 包含关系（Include Relationship）包含关系表示一个用例可以包含另一个用例，被包含的用例是基础功能，被包含的用例所描述的场景是包含关系中包含用例的一部分。
包含关系可以用来提高用例的复用性和可维护性。
在用例图中，包含关系用带箭头的虚线表示。
举个例子，假设我们正在开发一个电子商务网站，其中一个用例是“用户下订单”，而另一个用例是“用户选择支付方式”。
用户下订单的过程中必须选择支付方式，所以“用户选择支付方式”这个用例可以被包含在“用户下订单”用例中。
通过包含关系，我们可以将这两个用例的共同部分提取出来形成一个独立的用例。
2. 扩展关系（Extend Relationship）扩展关系表示一个用例可以在特定条件下扩展另一个用例。
扩展关系描述了一个用例可以根据某种条件执行额外的步骤或者部分功能。
扩展关系可以用于处理非必要的但可能发生的情况。
在用例图中，扩展关系用带箭头的虚线表示。
举个例子，继续以电子商务网站为例，假设我们有一个基本的用例是“用户下订单”，而另一个用例是“用户使用优惠码”。
当用户选择使用优惠码的时候，我们可以通过扩展关系将“用户使用优惠码”这个用例扩展到“用户下订单”用例中。
这样，在完成基本的下订单操作后，系统将会检查是否有优惠码，并执行相应的优惠操作。
3. 泛化关系（Generalization Relationship）泛化关系表示一个用例可以作为另一个用例的一般形式。
泛化关系在用例间建立一种继承关系，用于描述用例之间的通用和特殊关系。
在用例图中，泛化关系用带箭头的实线表示。
举个例子，假设我们正在开发一个电子商务网站，其中有多种不同的用户角色，如客户、管理员和供应商。