软件工程中,用例间常见的几种关系
用例图元素之间的关系
用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
包括：角色之间的关系、用例之间的关系、用例和角色之间的关系。
角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：(1)包含关系:基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。
(2)泛化关系：代表一般于特殊的关系。
它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
泛化（Generalization）在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图：在用例图中，角色和用例都能够泛化。
角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。
但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。
包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。
(3)扩展关系：扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
与包含关系一样，扩展关系也是依赖关系的版型。
用例之间的关系
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. 泛化关系定义：⼀个⽤例可以被特别列举为⼀个或多个⼦⽤例，这被称为⽤例泛化。
泛化关系在类间也有。
⼦⽤例从⽗⽤例处继承⾏为和属性，还可以添加⾏为或覆盖、改变已继承的⾏为。
表⽰⽅法：带空⼼箭头的实线，箭头指向被泛化（被继承）的⽤例，即⽗⽤例。
（PS：泛化关系的箭头不是指向被泛化，⽽是指向被继承。
泛化和继承是不同的⽅向。
泛化是从下到上的抽象过程，继承是从上到下，从⼀般到特殊的过程。
）如图所⽰：机房收费系统中可以这样应⽤：当系统中具有⼀个或多个⽤例是⼀般⽤例的特化时，就使⽤⽤例泛化。
3.包含关系定义：其中⼀个⽤例（基础⽤例）的⾏为包含了另⼀个⽤例（包含⽤例）的⾏为。
基础⽤例可以看到包含⽤例，并依赖于包含⽤例的执⾏结果。
但是⼆者不能访问对⽅的属性。
表⽰⽅法：虚线箭头+<<include>>字样，箭头指向被包含的⽤例。
如图所⽰：使⽤情况：（1）如果两个以上⽤例有重复的功能，则可以将重复的功能分解到另⼀个⽤例中。
其他⽤例可以和这个⽤例建⽴包含关系。
（2）⼀个⽤例的功能太多时，可以⽤包含关系创建多个⼦⽤例。
4.扩展关系（extend）定义：是把新⾏为插⼊到已有⽤例的⽅法。
个⼈感觉可以叫做特殊情况处理。
⽐如去⾷堂⽤饭卡打饭，绝⼤部分⼈是刷卡，拿饭，两个步骤就完成了。
但是如果某个学⽣的饭卡⾥没钱了，假定不⽤现⾦或者借钱或者赊账等等其他的⽅式来打饭，⽽是必须⽤⾃⼰的饭卡来打饭。
那么他就要先去给饭卡充值。
“饭卡充值”就是“刷卡”的⼀个扩展⽤例。
“饭卡充值”与“刷卡”就是扩展关系。
表⽰⽅法：虚线箭头+<<extend>>字样，箭头指向被扩展的⽤例（即基础⽤例）。
用例的三种关系
用例的三种关系用例是软件开发中的重要组成部分，用于描述系统与用户之间的交互。
在用例分析的过程中，我们需要了解用例之间的关系，以便更好地理解系统功能和需求。
用例的关系可以分为三种：包含关系、扩展关系和泛化关系。
1. 包含关系（Include Relationship）包含关系表示一个用例可以包含另一个用例，被包含的用例是基础功能，被包含的用例所描述的场景是包含关系中包含用例的一部分。
包含关系可以用来提高用例的复用性和可维护性。
在用例图中，包含关系用带箭头的虚线表示。
举个例子，假设我们正在开发一个电子商务网站，其中一个用例是“用户下订单”，而另一个用例是“用户选择支付方式”。
用户下订单的过程中必须选择支付方式，所以“用户选择支付方式”这个用例可以被包含在“用户下订单”用例中。
通过包含关系，我们可以将这两个用例的共同部分提取出来形成一个独立的用例。
2. 扩展关系（Extend Relationship）扩展关系表示一个用例可以在特定条件下扩展另一个用例。
扩展关系描述了一个用例可以根据某种条件执行额外的步骤或者部分功能。
扩展关系可以用于处理非必要的但可能发生的情况。
在用例图中，扩展关系用带箭头的虚线表示。
举个例子，继续以电子商务网站为例，假设我们有一个基本的用例是“用户下订单”，而另一个用例是“用户使用优惠码”。
当用户选择使用优惠码的时候，我们可以通过扩展关系将“用户使用优惠码”这个用例扩展到“用户下订单”用例中。
这样，在完成基本的下订单操作后，系统将会检查是否有优惠码，并执行相应的优惠操作。
3. 泛化关系（Generalization Relationship）泛化关系表示一个用例可以作为另一个用例的一般形式。
泛化关系在用例间建立一种继承关系，用于描述用例之间的通用和特殊关系。
在用例图中，泛化关系用带箭头的实线表示。
举个例子，假设我们正在开发一个电子商务网站，其中有多种不同的用户角色，如客户、管理员和供应商。
UML-用例关联
UML-⽤例关联
1、⽤例关联：就是各个⽤例之间的关系，分3种关系分别是：包含关系、扩展关系、泛化关系。
2、包含关系
1）、⽰例
2）、使⽤场景
A、⽤例在其他⽤例中重复使⽤
B、⽤例⾮常复杂冗长，将其分解为⼦单元便于理解。
3、术语
具体⽤例：由参与者发起，完成了所期望的完整⾏为。
如处理销售。
抽象⽤例：其他⽤例的⼦功能实现。
如处理信⽤卡⽀付，他不能独⽴存在，只能是其他⽤例的⼀部分。
基础⽤例：包含其他⽤例的⽤例，或者被其他⽤例扩展或者泛化的⽤例。
如：处理销售⽤例包含处理信⽤卡⽀付⽤例，因此处理销售是基础⽤例。
附加⽤例：被其他⽤例包含的⽤例，或者扩展、泛化其他⽤例的⽤例。
如：处理信⽤卡⽀付⽤例被处理销售⽤例包含，因此处理信⽤卡⽀付⽤例就是附加⽤例。
附加⽤例通常是抽象⽤例。
基础⽤例通常是具体⽤例。
如下图：
4、扩展关系
如果某个⽤例⽂本因为某些原因不能被修改，但是，业务要修改，怎么办？答：创建扩展或附加⽤例，并且在其中指明扩展点，即：在何处、何种条件下触发扩展⽤例。
5、泛化关系
增加复杂度。
可选。
6、⽰例
专家建议，保持事物简单、优先使⽤包含关系。
1）、包含关系
2）、扩展关系。
用例之间的关系
例子
一个汽车租赁系统用例图的部分内容。在此，基本
用例是“还车”，扩展用例是“交纳罚金”。如果 一切顺利汽车可以被归还，那么执行“还车”用例 即可。但是如果超过了还车的时间或汽车受损，按 照规定客户要交纳一定的罚金，这时就不能执行提 供的常规动作。若研讨修改用例“还车”，势必会 增加系统的复杂性，因此可以在用例“还车”中增 加扩展点，即特定条件为超时或损坏，如果满足条 件，将执行扩展用例“交纳罚金”，这样显然可以 使系统更容易被理解。
用例之间的关系
在画用例图的时候，理清用例之间的关系是重 点。用例的关系有泛化(generalization)、扩展 (extend)和包含(include)。其中include和 extend最易混淆。 使用关系uses(UML1.2以后已经不再使用此关 系） 下面我们结合实例彻底理清三者的关系。
基本概念
包含(include)
include为包含关系，当两个或多个用例中共用一组
相同的动作，这时可以将这组相同的动作抽出来作 为一个独立的子用例，供多个基用例所共享。因为 子用例被抽出，基用例并非一个完整的用例，所以 include关系中的基用例必须和子用例一起使用才 够完整，子用例也必然被执行。include关系在用例 图中使用带箭头的虚线表示(在线上标注 <<include>>)，箭头从基用例指向子用例。
泛化关系是一种继承关系，子用例将继承基
用例的所有行为，关系和通信关系，也就是 说在任何使用基用例的地方都可以用子用例 来代替。泛化关系在用例图中使用空心的箭 头表示，箭头方向从子用例指向基用例。
在用例泛化中，子用例表示父用例的特殊形式，子用例继承了 父用例的行为和属性，也可以增加新的行为和属性或覆盖父用 例中的行为。
用例之间的三种关系
用例之间的三种关系
用例是指为了验证某种特定目的或功能而实际执行的一组任务或
活动。
在软件工程中，用例可以用来描述需求，是需求分析的一个重要输入。
在需求分析阶段，用例描述了系统必须满足的所有功能和行为，以确保系统的正确性和稳定性。
用例之间的关系有三种：包含、扩展和泛化。
1.包含关系：一个用例可以包含在另一个用例中，例如一个用例可以包含在另一个用例的实现中。
这种关系通常用于描述用例之间的依赖关系，即一个用例的实现依赖于另一个用例的实现。
2.扩展关系：一个用例可以扩展另一个用例的行为，即一个用例的行为可以在另一个用例的基础上进行扩展。
例如，一个用例可以扩展另一个用例的功能，或者一个用例可以在另一个用例的基础上添加新的行为。
3.泛化关系：一个用例可以泛化到其他用例的行为中，即一个用例的行为可以适用于其他用例的情况。
例如，一个用例可以泛化到其他用例的功能中，或者一个用例可以在其他用例的基础上进行修改和扩展。
总之，用例是软件需求分析中的重要输入，用例之间的关系可以描述用例之间的依赖关系和扩展关系。
通过正确理解用例之间的关系，可以帮助开发人员更好地理解系统的需求，并确保系统的正确性和稳定性。
UML用例图中的关系
UML用例图中的关系用例之间的关系做一个总结。
1、关联关系（association）：用带箭头的实线表示，由参与者指向用例。
关联关系是指参与者与用例之间的关系，是参与者和用例之间的通信。
一个参与者可以关联多个用例，一个用例可以关联多个参与者。
但是每一对参与者和用例之间（即一条连线上）的通信必须是唯一的，否则则存在可以合并的参与者或者用例。
2、泛化关系（dependency）：用带空心三角形的实线表示，由子级指向父级。
泛化关系是参与者于参与者之间或者用例于用例之间的关系。
泛化即继承关系，子用例（子参与者）继承了父用例（父参与者）的一切行为和通信。
同时还可以增加属于自己独有的行为和通信。
以机房收费系统中的三个参与者为例。
操作员继承了一般用户的所有功能，同时增加了充值、工作记录查询等功能。
而管理员则继承了操作员的一切功能，同时增加了结账和报表生成等功能。
用例图如下：3、包含关系（include）：用带箭头的虚线和版型（include）表示，由基本用例指向被包含用例。
包含关系是用例之间的关系。
所谓的包含关系是指当一个用例需要以另一个用例的执行为前提才能执行时，这两个用例间的关系。
即一个用例不能被独立执行，随着另一个用例的执行而执行，也随着另一个用例的消亡而消亡。
以机房收费系统中的结账功能为例，如下图：在上图中结账用例和汇总退还金额用例之间即包含关系。
如果结账用例不执行时就无法执行汇总退还金额用例，而结账用例结束那么汇总用例也随之结束。
4、扩展关系（extend）：用带箭头的虚线和版型（extend）表示，右基本用例指向扩展用例。
扩展关系也是用例之间的关系。
它指的是，当一个用例执行时出现某种特定的条件时，激活另一个用例。
这里的一定条件称之为扩展点，被激活的用例称之为扩展用例。
以机房收费系统中，上机时余额不足为例，如下图：上图中，上机用例执行时若发现学生卡号中的余额小于最低余额时则直接转入充值用例，但是充值用例也可以单独被执行。
UML用例图三种关系详解
.和泛化(extend)(include)、扩展1UML用例图中包含(generalization）三种关系详解共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
这时包含关系可以用来理清关系。
;..(extend)、扩展2）用扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）上进行扩展，Extension Point例加以封装，再让它从基用例中声明的扩展点（扩展扩展用例为基用例添加新的行为。
从而使基用例行为更简练和目标更集中。
因此它能根据基用例中扩展点的当前状态来判断是用例可以访问基用例的属性，但是扩展用例对基用例不可见。
否执行自己。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。
对于查询而言，能不能导打印和查询相对独立，导入、打印是不可见的。
打印查询都是一样的，出、导出、而且为查询添加了新行为。
UML用例中的包含、扩展、泛化关系的理解
UML用例中的包含、扩展、泛化关系的理解在用例关系中有有三种关系，一是包括，"include" 一是扩展"extend"一是泛化，当然还有最基本的关系，“关联”.其中，包含关系：包含关系用于将部分工作流程分离出去，对这部分工作流程来说，基本用例只取决于结果，与获得结果的方法无关。
如果这种分离可以简化对基本用例的理解（隐藏详细的行为），或者可以在其他基本用例中复用被分离的行为，您就可以将这部分工作流程分离出去。
基本用例通过包含关系连接到包含用例。
包含用例总是抽象的。
它描述在执行基本用例的用例实例中插入的行为段。
基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但是基本用例和包含用例都不能访问对方的属性。
从这种意义上来讲，包含用例是被封装的，它代表可以在各种不同的用例中复用的行为。
包含关系用于：（１）从基本用例中分解出来这种的行为：它对于了解基本用例的主要目的不是必需的，只有它的结果才比较重要。
（２）分解出两个或者多个用例所共有的行为。
扩展关系：扩展关系将扩展用例与基本用例连接了起来，通过在基本用例中引用扩展点，可以定义在基本用例的哪些位置插入扩展用例，扩展用例通常是抽象的，但是不是必须抽象。
扩展的目的在于：（１）表明用例的某一部分是可选的（或者可能可选）的系统行为。
这样，你就可以将模型中的可选行为和必选行为分开。
（２）表明只有在特定条件下（有时候是异常情况下）才执行的分支流，如触发警报。
（３）表明可能有一组行为段，其中的一个或者多个段可以在基本用例中的扩展点处插入。
所插入的行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互。
扩展是有条件的，它是否执行取决于在执行基本用例时所发生的事件。
基本用例并不控件执行扩展的条件，这些条件在扩展关系中进行说明。
扩展用例可以访问和修改基本用例的属性。
但是基本用例看到到扩展用例，也无法访问它们的属性。
[宝典]用例图元素之间的关系
![[宝典]用例图元素之间的关系](https://img.taocdn.com/s3/m/57d75107240c844768eaee82.png)
[宝典]用例图元素之间的关系用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
包括:角色之间的关系、用例之间的关系、用例和角色之间的关系。
角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系:(1)包含关系:基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。
(2)泛化关系:代表一般于特殊的关系。
它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
泛化(Generalization)在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图:在用例图中，角色和用例都能够泛化。
角色的泛化/继承很容易理解，因为角色本来就是类(Class)，它是一种版型(stereotype)为Actor的类，所以角色的继承直观而自然。
但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展(extended)和包含(include)两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。
包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。
(3)扩展关系: 扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
UML中的4种关系
UML中的4种关系在UML中共有四种关系，这些关系主要描述类和类之间的联系，当然也可以表示用例和用例之间，角色和角色之间的联系。
这四种关系分别是：关联，依赖，泛化，实现。
下面对这几种关系分别进行介绍。
关联普通关联普通关联是最常见的关联关系，如下图所示注：其中job叫做关联名，employee和employer是角色名；这些都是对关联的修饰关联关系在具体编程中通常这样表示：一个类作为另一个类的一个属性，如下图所示关联按照相互性又可分为单向关联（A类是B类的一个属性，而B类却不是A类的属性）和双向关联（A是B得属性，B也是A的属性）两个类之间可以有多种关系，一个类也可以与多个类发生关系如果一个类的一个实例对象和另一个实例对象有关联关系，那么我们称之为内部关联除了普通关联外，还有两种关联是表示整体与部分之间的关系的，他们分别叫做聚合和组合聚合聚合表示的总体和部分之间的关系比较弱，部分可以脱离总体而单独存在，二者在时间先后上没有必然关系。
在上图中书和书架都是单独存在的。
组合组合表示的整体和部分之间的关系比较强，部分不能脱离总体而单独存在，在时间上先有整体才能有部分。
上图中人上提上的任何一部分都不能脱离整体而单独存在，所有的部分都必须属于一个整体。
依赖依赖关系用一个英文单词可以形象的表示，这个单词是“Using”，即依赖描述的是一种使用关系。
在代码实现时，通常是一个类是另一个类的某个方法的形参，或者在方法的具体实现中用到了那个类。
1中通过“Course”类作为“Professor”类“teach”方法的参数类型来实现2中通过“Course”类作为“Professor”类“teach”方法的内容里的一个变量类型来实现泛化泛化也叫继承，通过泛化关系，子类从父类哪里继承到了所有的属性和方法。
用一个等式表示就是：子类=父类的方法和属性+子类自己新增的方法和属性类A继承类B的代码表示方法：1使用C ++语言实现的继承A：Public/private/protect B2使用Java语言实现的继承A extends B实现实现关系主要是指类和接口之间的关系，一个类实现一个接口即为实现关系实现在代码中用“implements”关键字表示。
用例图中的三种关系包括、扩展、泛化
⽤例图中的三种关系包括、扩展、泛化⽤例图使⽤户与开发者交流的⼀种重要的⽅式，是对⽤户需求的⼀种描写叙述。
开发者从⽤户的⾓度总体上理解系统的功能。
⽤例图主要有三种元素：參与者（Actor）。
⽤例。
以及⽤例图中对象间到的关系。
当中关系有包括、扩展是⽤例图中特有的，泛化在其它类图中相同存在。
包括:当能够从两个或两个以上的⽤例中提取公共⾏为时，应该使⽤包括的关系来表⽰它们。
当中这个提取出来的公共⽤例成为抽象⽤例。
⽽把原始⽤例成为基本⽤例或基础⽤例。
当中“<<include>>”是包括关系的构造型，箭头指向抽象⽤例。
⽐如，在机房收费系统中“注冊学⽣信息”和“充值”两个⽤例都须要操作员或者管理员登陆。
为此，能够定义⼀个抽象⽤例“⽤户登陆”。
⽤例“注冊学⽣信息”和“充值”与⽤例“⽤户登陆”之间的关系就是包括关系。
如图有时当某⽤例的事件流过于复杂时，为了简化⽤例的描写叙述，我们也能够抽象出⼀个基⽤例，来包括这些颗粒的⽤例作⽤：当多个⽤例须要使⽤同⼀段事件流时。
抽象成为公共⽤例，能够避免在多个⽤例中反复地描写叙述这段事件流。
也能够防⽌这段时间流在不同⽤例中的描写叙述出现不⼀致。
当须要改动这段公共的需求时，也仅仅要改动⼀个⽤例，避免同⼀时候改动多个⽤例⽽产⽣的不⼀致和反复性⼯作。
另外，当某个⽤例的事件流过于复杂时，为了简化⽤例的描写叙述。
也能够将某段事件流抽象成为⼀个被包括的⽤例。
2、扩展关系假设⼀个⽤例明显地混合了两种或者两种以上的不同场景，即依据情况可能发⽣多种分⽀，则能够将这个⽤例分为⼀个基本⽤例和⼀个或多个扩展⽤例。
这样可能会使描写叙述更加清晰。
扩展⽤例为基⽤例加⼊新的⾏为。
扩展⽤例能够訪问基⽤例的属性，因此他能依据基⽤例中扩展点的当前状态来决定是否运⾏⾃⼰。
⽽扩展⽤例对基⽤例不可见。
如机房收费系统中“维护学⽣信息”操作时假设发现信息有误或者更新则须要使⽤“改动学⽣信息”⽤例完毕更新，所以⽤例“查询上机记录”和“导出EXCEL”之间的关系就是扩展关系。
用例中的主要关系有
用例中的主要关系有
1. **包含关系**：包含关系用于表示一个使用案例是另一个使用案例的一部分。
换句话说，被包含的使用案例是包含使用案例的特殊情况。
例如，“登录”使用案例可能包含“验证用户名和密码”、“获取用户信息”等子使用案例。
2. **扩展关系**：扩展关系用于表示一个使用案例可以在特定条件下扩展或修改另一个使用案例的行为。
扩展使用案例通常在基本使用案例的基础上增加额外的功能或行为。
例如，“在线购物”使用案例可以扩展为“使用优惠券”、“选择送货方式”等扩展使用案例。
3. **泛化关系**：泛化关系用于表示一个使用案例可以被另一个更通用的使用案例所替代。
泛化使用案例是特殊情况下的一般化描述，而子使用案例则是更具体的实现。
例如，“发送电子邮件”使用案例可以泛化为“发送消息”，因为发送电子邮件是发送消息的一种具体形式。
4. **关联关系**：关联关系用于表示使用案例之间的逻辑联系或依赖关系。
一个使用案例可能需要与其他使用案例一起执行，或者它可能在执行过程中依赖于其他使用案例的结果。
例如，“创建订单”使用案例可能与“查询产品信息”、“选择付款方式”等使用案例有关联。
这些关系类型有助于我们更好地组织和理解使用案例，以及识别系统或产品的不同功能和行为之间的相互作用。
通过明确使用案例之间的关系，我们可以更好地规划系统的设计和开发，并确保所有必要的功能和场景都得到了充分考虑。
软件工程中,用例间常见的几种关系
1．用例间常见的关系有几种？①包含关系：指基用例在它的内部说明的某个位置上显式的合并了另一个用例的行为。
在棋牌馆用例图中，用例预定座位就包含了用例检查座位信息。
可以设想，当客户预定座位时，当然需要知道座位的信息（是否有空座位，有那些空座位），因此这两个用例的事件流执行顺序如下图。
也就是说，被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现。
也只有当某个事件流片段在多个用例中出现的时候（本例中，在客户预定座位和总台服务员安排座位时都需要检查座位的详情），才将这个事件流片段抽取出来，放在一个单独的用例中，这样就可以简化基本用例的事件流描述，同时也使得整个系统的描述更加清晰。
（2）包含(includes)：用例A includes 用例B，表示没有了用例B，用例A本身也就不完整了。
例如：还是老王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城用例与上厕所用例的关系就应该是包含关系了。
②扩展关系：指基用例在由扩展用例间接说明的一个位置上隐式的合并了另一个用例的行为。
在棋牌馆用例图中，用例处理等候队列就是对用例预定座位的一个扩展。
可以设想，当客户预定座位时，如果没有空座位或者客户想要的座位时，客户就有两种选择：一是取消预定操作，二是进入等侯队列，等系统通知；如果有客户想要的座位，就无需进入等候队列了。
也就是说，用例处理等候队列中的事件流并不是在每次预定座位的时候都会发生。
因此这两个用例的事件流执行顺序如下图。
所以说，基本用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展。
在实际建模中，只有对那些表示用户看作可选的系统行为的用例才使用扩展关系来建模。
通过这种方式，可以把可选行为从必须的行为中分离出来。
扩展(extends)：用例B extends 用例A，表示用例B是用例A在某种特定情况下可能会出现的扩展用例。
用例图之间的几种关系
⽤例图之间的⼏种关系⽤例图之间的⼏种关系1. 执⾏者与执⾏者之间的唯⼀关系(继承)A.解释执⾏者与执⾏者之间只有⼀种关系即继承(也叫泛化)。
其意义与⾯向对象过程中的继承关系类似,但它主要强调⼦类执⾏者对⽗类执⾏者与⽤例之间的交互⾏为的继承。
B.表⽰形式(从⼦类指向⽗类)C.核⼼两个或两个以上执⾏者之间有共性,共性单独设为⼀个执⾏者。
D.例⼦在教务管理系统中,⽼师、学⽣、⽤户之间的关系理解:⽼师和学⽣都是⽤户的⼦类,所以继承了⽤户⾝份验证和注册操作E.有什么⽤？1.减少代码的冗余量2.易于修改2.执⾏者与⽤例之间的关系(关联)A.解释通常来讲,执⾏者与⽤例之间的关系都是⽤⽆向边表⽰的(可理解为双向传递信息)B.表现形式C.核⼼对号⼊座D.例⼦管理员与⽤户⾝份验证的关系但也有特殊情况,如下所述1．当多个执⾏者与⽤例相连时,为了强调某个执⾏者是主要执⾏者,就在执⾏者到⽤例之间加上⼀条边。
2.被动执⾏者仅从⽤例获取信息,⽽不提供信息给⽤例,那么此时⽤例到执⾏者之间就可以连⼀条有向边。
E.有什么⽤1.使程序整洁了,避免混乱2.使软件开发符合要求,难出现缺⽄少两的现象。
3.⽤例与⽤例之间的关系3.1 包含(include)A.解释A.1⼀个⽤例所需要完成的功能是多个互不联系的⽤例的功能之和,那么它们之间就具备着包含关系。
A,2多个⽤例之间具有共性,就需要把共性提取出来作为⼀个新的⽤例,此时新⽤例与原来的多个⽤例之间就具备了包含关系。
B.表现形式(指向包含的⽤例)C.核⼼对于不同⽤例⽽⾔,提取公共⼦函数,在登录教务管理系统中,⽼师和学⽣都包含着⾝份信息验证这个⽤例。
对于某⼀个⽤例⽽⾔,可以采⽤拆分法,不断拆分成⼩的⽤例。
如管理图书信息这个⽤例D.例⼦图书管理系统中,管理图书信息这个⽤例就包含增加图书信息,删除图书信息,修改图书信息,查询图书信息四个⼦⽤例E.有什么⽤?1.⽅便软件开发⼈员开发出软件需的功能2.能使客户更好的表达⾃⼰的观点(错则改正)。
【最新】用例间的关系
2021/2/2
5
实例——图书馆管理系统的用例图
• 1 确定系统涉及的总体信息 • 2 确定系统的参与者 • 3 确定系统的用例 • 4 图书馆管理系统的用例图
2021/2/2
6
1 确定系统涉及的总体信息
• 读者： ① 借书 ② 还书 ③ 书籍预定
2021/2/2
7
1 确定系统涉及的总体信息
(2)支持目标软件系统的确认，需求规格说明 的各项需求应该是可测试的。
(3)控制系统进化过程，需求分析完成后，如 果用户追加需求，开发人员再次进行需求 分析，扩充需求规格说明，进行软件设计 等。
2021/2/2
22
需求规格说明
内容（见教材p97-109）
• 功能、行为需求 描述系统的输入、输出及相互关系
2021/2/2
11
3 确定系统的用例
• 1. 借阅者请求服务的用例 • 2. 图书馆管理员处理借书、还书等的用例 • 3. 系统管理员进行系统维护的用例
2021/2/2
12
1. 借阅者请求服务的用例
① 登录系统 ② 查询自己的借阅信息 ③ 查询书籍信息 ④ 预定书籍 ⑤ 借阅书籍 ⑥ 归还书籍
31
需求评审
(6)可理解性。 追求上述目标不应妨碍需求规格说明书
对于用户、设计人员和测试人员的易理解 性。特别是对于非计算机专业的用户而言， 不宜在说明书中使用太多的专业化
词汇。
2021/2/2
32
需求评审
(7)可修改性。 需求规格说明的格式和组织方式应支持内
容的增、删和修改。
2021/2/2
33
3
扩展关系
• 扩展用例被定义为基础用例的增量扩展。 • 基础用例提供扩展点以添加新的行为。 • 扩展用例提供插入片段以插入到基础用例的扩展
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1．用例间常见的关系有几种？
①包含关系：指基用例在它的内部说明的某个位置上显式的合并了另一个用例的行为。
在棋牌馆用例图中，用例预定座位就包含了用例检查座位信息。
可以设想，当客户预定座位时，当然需要知道座位的信息（是否有空座位，有那些空座位），因此这两个用例的事件流执行顺序如下图。
也就是说，被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现。
也只有当某个事件流片段在多个用例中出现的时候（本例中，在客户预定座位和总台服务员安排座位时都需要检查座位的详情），才将这个事件流片段抽取出来，放在一个单独的用例中，这样就可以简化基本用例的事件流描述，同时也使得整个系统的描述更加清晰。
（2）包含(includes)：用例A includes 用例B，表示没有了用例B，用例A本身也就不完整了。
例如：还是老王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城用例与上厕所用例的关系就应该是包含关系了。
②扩展关系：指基用例在由扩展用例间接说明的一个位置上隐式的合并了另一个用例的行为。
在棋牌馆用例图中，用例处理等候队列就是对用例预定座位的一个扩展。
可以设想，当客户预定座位时，如果没有空座位或者客户想要的座位时，客户就有两种选择：一是取消预定操作，二是进入等侯队列，等系统通知；如果有客户想要的座位，就无需进入等候队列了。
也就是说，用例处理等候队列中的事件流并不是在每次预定座位的时候都会发生。
因此这两个用例的事件流执行顺序如下图。
所以说，基本用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展。
在实际建模中，只有对那些表示用户看作可选的系统行为的用例才使用扩展关系来建模。
通过这种方式，可以把可选行为从必须的行为中分离出来。
扩展(extends)：用例B extends 用例A，表示用例B是用例A在某种特定情况下可能会出现的扩展用例。
例如：老王进城办事，2小时就可以回去，在这2小时内内急时就会去
上厕所。
上厕所用例是进城用例的扩展，因为不上厕所老王进城办事也可完成。
③泛化关系：在用例图中引入泛化关系。
对于参与者而言，泛化关系的引用可有效降低模型的复杂度。
如在棋牌馆用例图中，我们可以引入“迎宾员”的角色，并且为了缓解总台压力，希望让迎宾员也能完成“安排座位”的职责，那么可以通过参与泛化来更有效的组织这个用例图。
下图表述了：总台服务员是一种“特殊”的迎宾员，他不仅可以安排座位，还能够办理结账。
用例之间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为，更可以出现在父用例出现的任何位置。
如：在棋牌馆用例图中，用例收款只只定义了收款的一般过程，而处理现金结账和处理银行卡结账则是两个子用例，他们完成不同情况下的收款工作。
如图
（3）泛化：泛化关系指的是同一业务目的的不同技术实现。
例如：老王进城，他可以坐飞机，可以坐火车，还可以走路，那么进城用例就泛化为坐飞机、坐火车和走路三个用例了，它们之间存在层级关系。
总的来看，扩展可以“冻结”基本用例以保持稳定（因为扩展用例通常是不确定的）；包含可以提供公共交互，提高“复用”；泛化是同一业务目的的不同技术实现。
用例之间除了上述三种关系不再有其他关系，用例之间不能通讯。