用例包含关系
用例之间的关系
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）泛化关系表示一个用例可以作为另一个用例的一般形式。
泛化关系在用例间建立一种继承关系，用于描述用例之间的通用和特殊关系。
在用例图中，泛化关系用带箭头的实线表示。
举个例子，假设我们正在开发一个电子商务网站，其中有多种不同的用户角色，如客户、管理员和供应商。
用例和用例之间的关系
用例和用例之间的关系嘿，朋友们！今天咱们来聊聊用例之间那些有趣的关系，就像在探索一个充满奇思妙想的魔法世界一样。
你可以把用例想象成一个个性格各异的小角色。
有些用例呢，就像是双胞胎，它们之间是一种包含关系。
比如说，有个“购物用例”，其中“线上购物用例”和“线下购物用例”就像是购物这个大家庭里的一对双胞胎。
这就好比是同根生的两棵树，虽然各有各的枝桠，但主干都是购物这件事，一个在虚拟的网络森林里摇曳，一个在现实的商业大街上矗立。
还有些用例之间是扩展关系，这就像是孙悟空拔毛变出的小猴子。
主用例就像孙悟空，而扩展出来的用例则是那些小猴子，它们在主用例的基础上衍生出更多的功能或者场景。
例如“社交用例”这个孙悟空，“语音社交用例”和“视频社交用例”就是它拔毛变出来的小猴子，在社交这个大舞台上玩出了新花样，就像小猴子们在花果山表演杂技一样。
另外，用例之间还有泛化关系呢。
这就像是一个家族里的远房亲戚。
比如说“交通工具用例”，汽车用例、轮船用例、飞机用例就像是这个大家族里的远房亲戚。
它们虽然各有各的独特之处，汽车在陆地上跑得欢，轮船在大海里慢悠悠地晃荡像个大胖子在散步，飞机在天空中呼啸而过好似超级英雄在赶路，但都有着交通工具这个共同的家族特征。
有时候，用例之间还会玩“接力赛”，这就是顺序关系啦。
就像一场滑稽的接力比赛，第一个用例跑一段，把接力棒传给下一个用例。
比如“制作蛋糕用例”，先是“准备材料用例”像个勤劳的小蚂蚁一样把材料收集好，然后传给“搅拌面糊用例”，接着再传给“烤制蛋糕用例”，最后到达“装饰蛋糕用例”这个终点，每个用例都像接力赛选手一样，一个接一个，不能乱了顺序，不然蛋糕可能就会变成一场灾难，不是烤糊了就是根本没成型，就像一个东倒西歪的小丑。
还有一种关系就像是镜子里的倒影，那就是依赖关系。
一个用例就像一个自恋的家伙，得依赖另一个用例才能完整地表现自己。
例如“登录用例”和“查看用户信息用例”，查看用户信息这个自恋鬼得依赖登录这个镜子才能看到自己的内容，如果登录都没成功，那查看用户信息就像个迷失在黑暗中的小幽灵，啥也干不了。
用例间的三种关系
⽤例间的三种关系⽤例间的三种关系：（1）扩展(extends)：⽤例B extends ⽤例A，表⽰⽤例B是⽤例A在某种特定情况下可能会出现的扩展⽤例。
例如：⽼王进城办事，2⼩时就可以回去，在这2⼩时内内急时就会去上厕所。
上厕所⽤例是进城⽤例的扩展，因为不上厕所⽼王进城办事也可完成。
（2）包含(includes)：⽤例A includes ⽤例B，表⽰没有了⽤例B，⽤例A本⾝也就不完整了。
例如：还是⽼王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城⽤例与上厕所⽤例的关系就应该是包含关系了。
（3）泛化：泛化关系指的是同⼀业务⽬的的不同技术实现。
例如：⽼王进城，他可以坐飞机，可以坐⽕车，还可以⾛路，那么进城⽤例就泛化为坐飞机、坐⽕车和⾛路三个⽤例了，它们之间存在层级关系。
总的来看，扩展可以“冻结”基本⽤例以保持稳定（因为扩展⽤例通常是不确定的）；包含可以提供公共交互，提⾼“复⽤”；泛化是同⼀业务⽬的的不同技术实现。
⽤例之间除了上述三种关系不再有其他关系，⽤例之间不能通讯。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝下⾯是另外⼀种解释，⽤例⼦来描述。
⽤例描述的是系统外部可见的⾏为，是系统为某⼀个或⼏个参与者提供的⼀段完整的服务。
从原则上来讲，⽤例之间都是并列的，它们之间并不存在着包含从属关系。
但是从保证⽤例模型的可维护性和⼀致性⾓度来看，我们可以在⽤例之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这⼏种关系。
这⼏种关系都是从现有的⽤例中抽取出公共的那部分信息，然后通后过不同的⽅法来重⽤这部公共信息，以减少模型维护的⼯作量。
4.2.1 包含(include)包含关系是通过在关联关系上应⽤<<include>>构造型来表⽰的，如下图所⽰。
它所表⽰的语义是指基础⽤例(Base)会⽤到被包含⽤例(Inclusion)，具体地讲，就是将被包含⽤例的事件流插⼊到基础⽤例的事件流中。
用例间的关联(泛化-包含-扩展)
➢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（否则就不需要提取出来了）
10
用例间的关系
➢Extend 关系：假设 UseCaseA 的功能描述为“发送一条通 知”，可是，发送通知的方式可能有许多种（例如通过邮件发 送、通过短信发送等）。在需求分析阶段，可能无法明确到底 有多少种方式， 在用例分析阶段，UseCaseA 需要留出扩展接 口，然后把已知的发送方式作为扩展用例给出，例如 UseCaseB 是“通过短信发送”，而 UseCaseC 是“通过邮件 发送”，此时，UseCaseB 和 UseCaseC extend 了 UseCaseA， 表现为两根虚线，箭头指向 UseCaseA
11
用例间的关系
12
用例间的关系
错！
13
用例间的关系
➢销户：因为销户必需先进行账户结算，所以这里用include ➢停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend
[宝典]用例图元素之间的关系
![[宝典]用例图元素之间的关系](https://img.taocdn.com/s3/m/57d75107240c844768eaee82.png)
[宝典]用例图元素之间的关系用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
包括:角色之间的关系、用例之间的关系、用例和角色之间的关系。
角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系:(1)包含关系:基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。
(2)泛化关系:代表一般于特殊的关系。
它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
泛化(Generalization)在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图:在用例图中，角色和用例都能够泛化。
角色的泛化/继承很容易理解，因为角色本来就是类(Class)，它是一种版型(stereotype)为Actor的类，所以角色的继承直观而自然。
但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展(extended)和包含(include)两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。
包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。
(3)扩展关系: 扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
用例图——包含（include）扩展（extend）和泛化（generalization）
⽤例图——包含（include）扩展（extend）和泛化（generalization）1、包含(include)包含关系：使⽤包含（Inclusion）⽤例来封装⼀组跨越多个⽤例的相似动作（⾏为⽚断），以便多个基（Base）⽤例复⽤。
基⽤例可以依赖包含⽤例执⾏的结果，但是双⽅都不能访问对⽅的属性。
也就是说，基⽤例的事件流具有它下属的所有的包含⽤例的事件流2、扩展(extend)扩展关系：将基⽤例中⼀段相对独⽴并且可选的动作，⽤扩展（Extension）⽤例加以封装，再让它从基⽤例中声明的扩展点（Extension Point）上进⾏扩展，从⽽使基⽤例⾏为更简练和⽬标更集中。
扩展⽤例为基⽤例添加新的可选⾏为。
扩展⽤例可以访问基⽤例的属性，因此它能根据基⽤例中扩展点的当前状态来判断是否执⾏⾃⼰。
但是扩展⽤例对基⽤例不可见。
也就是说，下属的扩展⽤例对应的事件流是基⽤例对应的事件流执⾏完毕后，可选的事件流，重点是可选。
3、泛化(generalization)泛化关系：⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
4、扩展（extend）和泛化（generalization）的区别表⾯上看起来，好像两者没有什么分别，但是实际上他们之间的区别是⾮常的⼤的。
泛化：⼦⽤例⼀定和基⽤例是具有同⼀种操作的，或者说，⼦⽤例、⼦⽤例之间、基⽤例⼀定是同⼀种事件流扩展：下属扩展⽤例和基⽤例并不⼀定是同⼀类事件流，⽽且下属⽤例是基⽤例事件流执⾏完毕之后的⼀种选择有的时候，包含（include）和其他的两种关系也会有⼀定的重合，在实际操作中，应该⾃⼰判断⼀下，这种关系，更倾向于哪⼀种，从⽽做出适当的选择，毕竟我们使⽤⽤例图的⽬的是，更加清楚的表述系统的需求，⽽不是使系统的分析更加的复杂5、下⾯附上⼏张图，帮助理解⼀下6、下⾯，我们从整体上看⼀下，⽤例图都包含哪些内容7、下⾯我们来说⼀说⽤例规约和活动图，这⾥有⼀个问题：像上图中的每⼀个⽤例圆圈就是⼀个具体的动作，怎么还会有规约和活动图呢？实际上，真正合理的⽤例图中的每个⽤例都是⼀个能够代表⼀个完整动作的事件流，⽐如：订票可以作为⼀个⽤例，⽽订票这个⽤例是由⼀些列的有序事件组合完成的—>填写省份证号码—>跳转到⽀付界⾯—>确认订票信息—>确定⽀付—>订票成功。
UML用例图的异常处理方法与策略分享
UML用例图的异常处理方法与策略分享UML（统一建模语言）是软件开发过程中常用的一种建模语言，用例图是其中的一种重要图表。
用例图是用于描述系统功能和用户之间交互的图表，通过用例图可以清晰地展示系统的需求和功能。
然而，在实际的软件开发过程中，异常情况是难以避免的。
因此，如何在用例图中合理地处理和展示异常情况，成为了软件开发者关注的重点。
异常处理是软件开发中的重要环节，它涉及到系统的可靠性和稳定性。
在用例图中，我们可以使用一些方法和策略来处理异常情况，保证系统的正常运行。
首先，我们可以使用扩展关系来描述异常情况。
扩展关系是用例图中常用的一种关系，它表示一个用例在特定条件下可以扩展为另一个用例。
通过扩展关系，我们可以将异常情况作为一个扩展用例展示在用例图中。
这样做的好处是可以清晰地展示系统的正常流程和异常流程，帮助开发者更好地理解系统的功能和需求。
其次，我们可以使用包含关系来描述异常处理的策略。
包含关系是用例图中另一种常用的关系，它表示一个用例包含另一个用例。
通过包含关系，我们可以将异常处理的策略作为一个独立的用例包含在主用例中。
这样做的好处是可以将异常处理的策略和主用例分离开来，使系统的设计更加模块化和可维护。
除了扩展关系和包含关系，我们还可以使用泛化关系来描述异常处理的抽象策略。
泛化关系是用例图中的一种继承关系，它表示一个用例是另一个用例的特殊情况。
通过泛化关系，我们可以将异常处理的抽象策略定义为一个父用例，然后派生出具体的异常处理策略作为子用例。
这样做的好处是可以将异常处理的共性和差异性进行有效地管理，提高系统的可扩展性和可复用性。
在实际的软件开发过程中，异常处理的方法和策略也需要根据具体的需求和场景来进行选择和调整。
有时候，我们可以使用条件语句来处理简单的异常情况，有时候，我们需要使用异常处理机制来处理复杂的异常情况。
无论采用何种方法和策略，我们都应该遵循一些基本原则，如尽早发现异常、尽早处理异常、合理地记录异常信息等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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 的行为。