软件工程中,用例间常见的几种关系
用例图元素之间的关系
用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
包括：角色之间的关系、用例之间的关系、用例和角色之间的关系。
角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：(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.泛化关系：一个用例可以泛化到其他用例的行为中，即一个用例的行为可以适用于其他用例的情况。
例如，一个用例可以泛化到其他用例的功能中，或者一个用例可以在其他用例的基础上进行修改和扩展。
总之，用例是软件需求分析中的重要输入，用例之间的关系可以描述用例之间的依赖关系和扩展关系。
通过正确理解用例之间的关系，可以帮助开发人员更好地理解系统的需求，并确保系统的正确性和稳定性。
- 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）泛化：泛化关系指的是同一业务目的的不同技术实现。
例如：老王进城，他可以坐飞机，可以坐火车，还可以走路，那么进城用例就泛化为坐飞机、坐火车和走路三个用例了，它们之间存在层级关系。
总的来看，扩展可以“冻结”基本用例以保持稳定（因为扩展用例通常是不确定的）；包含可以提供公共交互，提高“复用”；泛化是同一业务目的的不同技术实现。
用例之间除了上述三种关系不再有其他关系，用例之间不能通讯。