用例之间的关系
3、4用例之间得关系1、泛化关系Ｇｅneralｉzａｔioｎ代表一般与特殊得关系。
（类似于继承）在用例泛化中，子用例表示父用例得特殊形式，子用例继承了父用例得行为与属性，也可以增加新得行为与属性或覆盖父用例中得行为。
例子：一个租赁或销售系统用例得部分内容，在此,父用例就是“预定",其两个子用例分别就是“网上预定”与“电话预定”,这两个用例都继承了父用例得行为,并可以添加自己得行为。
2、包含关系Inｃluｄe一个用例（基用例,基本用例）可以包含其她用例(包含用例）具有得行为，并把它所包含得用例行为作为自身用例得一部分，这被称为包含关系.在UML中，包含关系表示为虚线箭头加版型《inｃludｅ》，箭头从基本用例指向包含用例。
例子：一个租赁或销售系统中，“填写电子表格”得功能在“网上预定”得过程中使用，不管如何处理“网上预定”用例，总就是要运行“填写电子表格”用例,因此具有包含关系.3、扩展关系Extenｄ一个用例也可以定义为基本用例得增量扩展,这称作扩展关系,即扩展关系就是把新得行为插入到已有得用例中得方法。
在ＵML中,包含关系表示为虚线箭头加版型《eｘtｅnｄ》,箭头从扩展用例指向基本用例。
基本用例提供了一组扩展点，在这些新得扩展点中可以添加新得行为,而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例得扩展点上.扩展关系可以有控制条件,当用例实例执行到达一个扩展点时，控制条件决定就是否执行扩展。
一般情况下,基本用例得执行不会涉及到扩展用例，只有满足用例得控制条件时,扩展用例才被执行，因此扩展关系处理事件流得异常或者可选事件。
同一个基本用例得几个扩展可以在一起使用。
基本用例不知道扩展得任何细节、没有扩展用例，基本用例就是完整得。
例子：一个汽车租赁系统用例图得部分内容。
在此，基本用例就是“还车"，扩展用例就是“交纳罚金”。
如果一切顺利汽车可以被归还,那么执行“还车"用例即可。
但就是如果超过了还车得时间或汽车受损，按照规定客户要交纳一定得罚金，这时就不能执行提供得常规动作。
若研讨修改用例“还车",势必会增加系统得复杂性,因此可以在用例“还车"中增加扩展点，即特定条件为超时或损坏,如果满足条件，将执行扩展用例“交纳罚金"，这样显然可以使系统更容易被理解。
4、参与者与用例之间得关系：关联关系Aｓsociaｔiｏn关联关系描述参与者与用例之间得关系，在ＵMＬ中它就是两个或多个类元之间得关系,它描述了类元得实例间得联系.（类元,一种建模元素,常见类元包括类、参与者、构件、数据类型、接口、结点、信号、子系统以及用例等，其中类就是最常见得类元。
）关联关系表示参与者与用例之间得通信。
在ＵML中，关联关系用直线或箭头表示。
关联中municates版型就是参与者与用例之间唯一得版型,一般省略不写。
如果参与者启动了用例，箭头指向用例；如果参与者利用了用例提供得服务，箭头指向参与者。
如果二者就是互动得，则就是直线。
关联关系表示参与者与用例之间得通信。
不同得参与者可以访问相同得用例，一般说来它们与该用例得交互就是不一样得，如果一样得话，说明她们得角色可能就是相同得。
如果两种交互得目得也相同，说明她们得角色就是相同得，就应该将她们合并。
例子：一个汽车租赁系统用例图得部分内容.这个例子显示得就是“客户”参与者以及与她交互得3个用例,“预定”、“取车”、“还车”。
“客户”可以启动这３个用例。
３、5用例图1、阅读用例图用例图就是显示处于同一系统中得参与者与用例之间得关系得图。
一个用例图就是一个包括参与者、由系统边界封闭得一组用例、参与者与用例之间得关联、用例间得联系以及参与者得泛化等模型元素得图。
例子：棋牌馆管理系统用例模型局部系统主要功能：以inｔernｅｔ得形式向客户提供座位预定得服务，并且如果暂时无法获取座位得饿信息,允许客户进入“等候队列”,当有人退订之后及时通知客户.另外,该系统还将为总台服务员提供作座位安排以及结账得功能，要求能够支持现金与银行卡两种结账方式.(1)系统边界图中有4种元素:参与者、用例、一个方框与一些表示关系得连接线.其中,参与者有3个,分别就是客户、总台服务员、与银联POＳ系统，还包括预定座位、安排座位、办理结账等8个用例。
图中有一个方框,所有得用例都在这个方框内，并且它还有一个名字：棋牌馆管理系统。
在UML表示法中，这个方框称为“系统边界”，或者“系统范围",它用来定义系统得界限,系统用例都置于其中,参与者则在边界之外。
通过这个系统边界可以很清晰得表述出正在开发得系统得范围。
例如，图中明确得指出了该系统在处理银行卡结账时将通过系统外得“银联系统"来完成,银联系统就是位于系统外得。
(2)参与者与用例之间得关系一个参与者表示用例得使用者在与这些用例进行交互时所扮演得角色。
如：当通过Inte ｒｎeｔ预定座位时，这些系统得使用者就就是棋牌馆得客户，而只有“总台服务员"具有安排座位与结账得操作权限。
(3)用例之间得关系用例之间得包含与扩展关系就是分解与组织用例得有效工具.一个用例就是一个事件流得集合（包括基本事件流、扩展事件流等)，而包含与扩展表示得跨用例间得事件流就是不一样得。
[基本事件流：就是对用例中常规、预期路径得描述,这就是大部分时间所遇到得场景,它体现了系统得核心价值.］［扩展事件流：主要就是对一些异常情况、选择分支进行描述。
］①包含关系:指基用例在它得内部说明得某个位置上显式得合并了另一个用例得行为。
在棋牌馆用例图中,用例预定座位就包含了用例检查座位信息。
可以设想,当客户预定座位时，当然需要知道座位得信息(就是否有空座位,有哪些空座位)，因此这两个用例得事件流执行顺序如下图。
也就就是说，被包含得用例（此例中得检查座位详情)不就是孤立存在得，它仅作为某些包含它得更大得基用例（此例中得预订座位、安排座位）得一部分出现。
也只有当某个事件流片段在多个用例中出现得时候(本例中，在客户预定座位与总台服务员安排座位时都需要检查座位得详情)，才将这个事件流片段抽取出来,放在一个单独得用例中，这样就可以简化基本用例得事件流描述,同时也使得整个系统得描述更加清晰。
②扩展关系：指基用例在由扩展用例间接说明得一个位置上隐式得合并了另一个用例得行为。
在棋牌馆用例图中,用例处理等候队列就就是对用例预定座位得一个扩展。
可以设想，当客户预定座位时，如果没有空座位或者客户想要得座位时,客户就有两种选择:一就是取消预定操作，二就是进入等侯队列,等系统通知；如果有客户想要得座位,就无需进入等候队列了。
也就就是说，用例处理等候队列中得事件流并不就是在每次预定座位得时候都会发生。
因此这两个用例得事件流执行顺序如下图。
所以说，基本用例就是可以独立于扩展用例存在得，只就是在特定得条件下,它得行为可以被另一个用例得行为所扩展。
在实际建模中，只有对那些表示用户瞧作可选得系统行为得用例才使用扩展关系来建模。
通过这种方式，可以把可选行为从必须得行为中分离出来。
③泛化关系:在用例图中引入泛化关系.对于参与者而言，泛化关系得引用可有效降低模型得复杂度。
如在棋牌馆用例图中,我们可以引入“迎宾员”得角色，并且为了缓解总台压力，希望让迎宾员也能完成“安排座位”得职责，那么可以通过参与泛化来更有效得组织这个用例图。
下图表述了：总台服务员就是一种“特殊”得迎宾员，她不仅可以安排座位，还能够办理结账.用例之间得泛化则表示子用例继承了父用例得行为与含义；子用例还可以增加或覆盖父用例得行为,更可以出现在父用例出现得任何位置。
如：在棋牌馆用例图中,用例收款只定义了收款得一般过程,而处理现金结账与处理银行卡结账则就是两个子用例，她们完成不同情况下得收款工作。
如图(4)读图小结通过以上几部分得讲解，不难得出棋牌馆用例图所表示得含义。
这张用例图首先定义了三个基本用例:预订座位、安排座位与处理结账。
●客户通过Inteｒnet启动“预订座位”用例，在“预订座位”用例得执行过程中，将“检查座位信息"（被包含用例）,如果没有空闲得座位或满意得座位，可以选择进入等候队列,这样就将启动扩展用例“处理等候队列".●总台服务员在客户到棋牌馆时，启动“安排座位"用例，在执行过程中，将启动被包含用例“检查座位信息”.●当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款"用例，一个就是“处理现金结账”,另一个就是“处理银行卡结账”，而后一个用例将通过与外部系统“银联ＰOS系统"交互来完成。
3、6用例得描述正如前面得例子所示,只有棋牌馆用例图（《棋牌馆管理系统用例模型局部》），很多细节信息都没有明确得表示出来，只就是勾勒了一个大致得系统功能轮廓，这样对于软件开发活动就是不够充分得.一个完整得用例模型不仅包括用例图，更重要得就是它得用例描述部分，它就是后续交互图分析与类图分析不可缺少得部分。
用例描述得就是一个系统做什么（what）得信息（即功能需求）,并不说明怎么做（how）,怎么做就是设计模型得事。
（1）一般来说，用例描述采用自然语言描述参与者与系统进行交互时得行为.它一般包括以下内容:●用例得目标●用例就是怎么启动得●参与者与用例之间得消息就是如何传送得●用例中除了主路径，其她路径就是什么●用例结束后得系统状态●其她需要描述得内容（2)用例描述得格式（用例模板)注：表格中加粗就是必须编写部分例子：四种常见得错误：P３1 ，例子3、５——－—3、8分别对应了这4种错误与修改。
编写要点：（１）使用简单得语法：主语明确,语义易于理解，能清晰表述动作即可；(2)明确写出“谁控制球”：也就就是在事件流描述中,让读者直观地了解就是参与者在控制还就是系统在控制；（3)从俯视得角度来编写：指出参与者得动作，以及系统得响应,也就就是从第三者观察得角度;（4)显示过程向前推移:也就就是每一步都有前进得感(例如,用户按下taｂ键作为一个事件就就是不合适得）；如果过程繁杂,超过了9步,那么考虑提高目标层次,即“向前推移"（５）显示参与者得意图而非动作(如果只描述了动作，人们不能够很容易地直接从事件流描述中理解用例）；通过操纵系统得用户界面来描述用户得动作，这就是在编写用例时常见得一种严重错误，它使得编写得目标处于一个很低得层次，叫做“界面细节描述（interfａｃe ｄetａil dｅsｃrｉption）"。
在需求文档中，我们只关心界面所要达到得意图,总结在执行者之间传递得信息.可将这些低层次得步骤合并成一个步骤。
3、7如何绘制用例图1、用例分析技术步骤（不固定，可根据需要调整)：⑴找出系统外部得参与者与外部系统，确定系统得边界与范围。
用例图元素之间的关系
用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
包括：角色之间的关系、用例之间的关系、用例和角色之间的关系。
角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：(1)包含关系:基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。
(2)泛化关系：代表一般于特殊的关系。
它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
泛化（Generalization）在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图：在用例图中，角色和用例都能够泛化。
角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。
但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。
包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。
(3)扩展关系：扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
与包含关系一样，扩展关系也是依赖关系的版型。
用例之间的关系
3.4用例之间的关系1、泛化关系Generalization代表一般与特殊的关系。
（类似于继承）在用例泛化中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。
例子：一个租赁或销售系统用例的部分内容，在此，父用例是“预定”，其两个子用例分别是“网上预定”和“电话预定”，这两个用例都继承了父用例的行为，并可以添加自己的行为。
2、包含关系Include一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。
在UML中，包含关系表示为虚线箭头加版型《include》，箭头从基本用例指向包含用例。
例子：一个租赁或销售系统中，“填写电子表格”的功能在“网上预定”的过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。
3、扩展关系Extend一个用例也可以定义为基本用例的增量扩展，这称作扩展关系，即扩展关系是把新的行为插入到已有的用例中的方法。
在UML中，包含关系表示为虚线箭头加版型《extend》，箭头从扩展用例指向基本用例。
基本用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片段，这些片段能够被插入到基本用例的扩展点上。
扩展关系可以有控制条件，当用例实例执行到达一个扩展点时，控制条件决定是否执行扩展。
一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。
同一个基本用例的几个扩展可以在一起使用。
基本用例不知道扩展的任何细节.没有扩展用例,基本用例是完整的。
例子：一个汽车租赁系统用例图的部分内容。
在此，基本用例是“还车”，扩展用例是“交纳罚金”。
如果一切顺利汽车可以被归还，那么执行“还车”用例即可。
但是如果超过了还车的时间或汽车受损，按照规定客户要交纳一定的罚金，这时就不能执行提供的常规动作。
软件建模(卫红春)课后习题答案--归类版(全网最全)
一、简答题1. 简述模型的作用。
答：现实系统的复杂性和内隐性，使得人们难于直接认识和把握，为了使得人们能够直观和明了地认识和把握现实系统，就需要借助于模型。
2. 软件模型有什么特征？答：建模对象特殊，复杂性，多样性3. 软件建模技术有哪些因素？答：软件建模方法，软件建模过程，软件建模语言，软件建模工具4. 软件模型包括哪些方面的内容？答：从模型所反映的侧面看：功能模型，非功能模型，数据模型，对象模型，过程模型，状态模型，交互模型，架构模型，界面模型等；从软件开发工作看：业务模型，需求模型，分析模型，设计模型，测试模型等。
5. 软件建模工具应该具有哪些基本功能？答：软件模型的生成和编辑，软件模型的质量保障，软件模型管理等1. 简述UML的发展过程。
答：Rational公司在众多软件开发方法的基础上于1996年提出了UML0.9版本，1997年把UML1.0版本提交给OMG，1997年被OMG正式批准成为标准，1998年UML1.2 版，1999年UML1.3版，2001年1.4版本，2003年1.5版本，2005年2.0版本，2009年2.2版本，2010年2.3版本，现在已经上升为2.4版本。
2. 作为一种统一建模语言，UML由哪些部分构成？答：模型元素，图，语义规则，公共机制。
3. 元模型理论是UML的基础，元模型分为哪四个层次？答：元元模型，元模型，模型，对象。
4. 聚集关系与组合关系有什么区别？答：聚集松散，组合紧密；一个部分事物对象可以属于多个聚集对象,但一个部分事物对象仅能属于一个组合对象；聚集的对象生命周期可以不同,但组合对象则是同存同亡。
5. 用例和协作有什么区别？答：协作是对用例的实现。
6. 模型元素的可见性含义是什么？答：模型元素可被其他模型元素访问的程度，共分为公用，受限，私有，包四种。
7．UML的构造型有什么作用？答：给UML定义的模型元素赋予新的含义，定义新的模型符号，改换模型元素的表示形式。
用例图的泛化、扩展和包含
⽤例图的泛化、扩展和包含在画⽤例图的时候，理清⽤例之间的关系是重点。
⽤例的关系有泛化(generalization)、扩展(extend)和包含(include)。
其中include和extend 最易混淆。
下⾯我们结合实例彻底理清三者的关系。
基本概念⽤例图（Use Case Diagram）:⽤例图显⽰谁是相关的⽤户，⽤户希望系统提供什么服务（⽤例），以及⽤例之间的关系图。
⽤例图主要的作⽤是获取需求、指导测试。
⽤例图的4个基本组件：参与者(Actor)、⽤例(Use Case)、关系(Relationship)和系统。
泛化(generalization)：泛化关系是⼀种继承关系，⼦⽤例将继承基⽤例的所有⾏为，关系和通信关系，也就是说在任何使⽤基⽤例的地⽅都可以⽤⼦⽤例来代替。
泛化关系在⽤例图中使⽤空⼼的箭头表⽰，箭头⽅向从⼦⽤例指向基⽤例。
扩展(extend)： extend关系是对基⽤例的扩展，基⽤例是⼀个完整的⽤例，即使没有⼦⽤例的参与，也可以完成⼀个完整的功能。
extend的基⽤例中将存在⼀个扩展点，只有当扩展点被激活时，⼦⽤例才会被执⾏。
extend关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<extend>>)，箭头从⼦⽤例指向基⽤例。
包含(include)： include为包含关系，当两个或多个⽤例中共⽤⼀组相同的动作，这时可以将这组相同的动作抽出来作为⼀个独⽴的⼦⽤例，供多个基⽤例所共享。
因为⼦⽤例被抽出，基⽤例并⾮⼀个完整的⽤例，所以include关系中的基⽤例必须和⼦⽤例⼀起使⽤才够完整，⼦⽤例也必然被执⾏。
include关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<include>>)，箭头从基⽤例指向⼦⽤例。
实例需求场景联通客户响应OSS。
系统有故障单、业务开通、资源核查、割接、业务重保、⽹络品质性能等功能模块。
uml简答题
简答题：第六章用例图(1)试述识别用例的方法识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。
当找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者如何使用系统，需要系统提供什么样的服务。
对于这个被选出的用例模型，不仅要做到易于理解，还要做到不同的涉众对于它的理解是一致的(2)用例之间的三种关系各使用在什么场合？答：我们可以在用例之间抽象出包含、扩展和泛化这三种关系。
多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。
扩展关系往往被用来处理异常或者构建灵活的系统框架。
使用扩展关系可以降低系统的复杂度，有利于系统的扩展，提高系统的性能。
扩展关系还可以用于处理基础用例中的那些不易描述的问题，使系统显得更加清晰易于理解。
当您发现系统中有两个或者多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系。
这时，可以用一个新的（通常也是抽象的）用例来描述这些共有部分，这个新的用例就是父用例。
(3) 请问在设计系统时，绘制的用例图是多一些好还是少一些好，为什么？答：视系统的复杂度决定。
对于比较简单的系统，可以相对用的少些用例图，对于比较复杂的系统，为表示清楚系统功能必须多创建用例图。
我们应该根据每个系统的具体情况，具体问题具体分析，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。
(4)请简述为何在系统设计时要使用用例图。
他对我们有什么帮助？答：用例图是从软件需求分析到最终实现的第一步，它显示了系统的用户和用户希望提供的功能，有利于用户和软件开发人员之间的沟通。
借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
(5)使用Rose创建用例图有几个步骤？答：使用Rose创建用例图的步骤：识别参与者、创建用例，最后创建用例之间的关系。
UML软件建模教程课后习题及答案
UML软件建模教程课后习题习题 1一、简答题1. 简述模型的作用。
答：现实系统的复杂性和内隐性，使得人们难于直接认识和把握，为了使得人们能够直观和明了地认识和把握现实系统，就需要借助于模型。
2. 软件模型有什么特征？答：建模对象特殊，复杂性，多样性3. 软件建模技术有哪些因素？答：软件建模方法，软件建模过程，软件建模语言，软件建模工具4. 软件模型包括哪些方面的内容？答：从模型所反映的侧面看：功能模型，非功能模型，数据模型，对象模型，过程模型，状态模型，交互模型，架构模型，界面模型等；从软件开发工作看：业务模型，需求模型，分析模型，设计模型，测试模型等。
5. 软件建模工具应该具有哪些基本功能？答：软件模型的生成和编辑，软件模型的质量保障，软件模型管理等二、填空题1、模型是对现实的（抽象）和模拟，是对现实系统（本质）特征的一种抽象、简化和直观的描述。
2、模型具有（反映性）、直观性、（简化性）和抽象性等特征。
3、从抽象程度，可以把模型分为（概念模型）、逻辑模型和（物理模型）三种类型。
4、较之于其他模型，软件模型具有（建模对象特殊）、复杂性和（多样性）等特征。
5、软件模型是软件开发人员交流的（媒介），是软件升级和维护的（依据）。
6、软件建模技术的要素包括软件建模方法、（软件建模过程）、软件建模语言和（软件建模工具）。
7、从开发阶段看，软件建模有业务模型、（需求模型）、分析模型、（设计模型）和测试模型。
8、软件语言有软件需求定义语言、（软件设计语言）、软件建模语言、（软件结构描述语言）、软件程序设计语言等。
9、根据软件建模工具的独立性，把软件建模工具分为（独立软件）建模工具和（插件式软件）建模工具。
10、OMG在（ 1997 ）年把UML作为软件建模的标准，UML2.0版本是（ 2005 ）年颁布的。
三、选择题1、对软件模型而言，下面说法错误的是（ D ）。
A.是人员交流的媒介B.是软件的中间形态C.是软件升级和维护的依据D.是软件的标准文档2、下面说法错误的是（ B ）。
用例之间的关系有
用例之间的关系有
1. 包含关系：一个用例包含另一个用例，表示两个用例之间存在从属关系，即一个用例的执行依赖于另一个用例的执行。
2. 并行关系：两个用例同时进行，彼此之间没有依赖关系，可以独立执行。
3. 顺序关系：两个用例之间存在顺序关系，即一个用例的执行必须在另一个用例之后执行。
4. 扩展关系：一个用例可以作为另一个用例的扩展，即当某些条件满足时，执行扩展用例。
5. 交叉关系：两个用例之间存在交叉依赖关系，即一个用例的执行可能受到另一个用例的影响，或者两个用例之间存在数据传递。
以上是常见的用例之间的关系，实际上用例之间的关系可以根据具体的系统和需求进行定义和设计。
用例间的关联(泛化-包含-扩展)
➢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
测试用例 元素关系
测试用例元素关系
在软件开发过程中，测试用例是非常重要的一环。
它们是用来
验证软件系统是否符合预期行为的关键工具。
而测试用例之间的元
素关系则是决定测试用例之间如何相互作用和影响的重要因素。
首先，测试用例之间存在着依赖关系。
这意味着某些测试用例
可能需要在其他测试用例执行之后才能进行。
例如，如果一个测试
用例需要在数据库被初始化之后才能执行，那么它就依赖于数据库
初始化的测试用例。
在编写测试用例时，必须考虑到这些依赖关系，以确保测试用例能够按照正确的顺序执行。
其次，测试用例之间还存在着影响关系。
这意味着某些测试用
例的执行结果可能会影响其他测试用例的执行结果。
例如，如果一
个测试用例修改了系统的某些配置，那么后续的测试用例可能会受
到影响。
在这种情况下，需要确保测试用例之间的影响是可控的，
并且能够进行适当的清理和恢复操作，以保证测试用例的独立性和
可重复性。
此外，测试用例之间还存在着组合关系。
这意味着某些测试用
例可能需要以一定的组合方式进行执行，以验证系统的某些复杂功
能或场景。
在编写测试用例时，需要考虑到这些组合关系，并确保能够覆盖到系统的各种组合情况，以提高测试的全面性和有效性。
总之，测试用例之间的元素关系是软件测试过程中需要重点关注的问题。
只有深入理解和合理处理测试用例之间的依赖、影响和组合关系，才能够确保测试工作的顺利进行，并最终达到有效验证软件系统的预期行为的目的。
用例之间的关系
例子
一个汽车租赁系统用例图的部分内容。在此，基本
用例是“还车”，扩展用例是“交纳罚金”。如果 一切顺利汽车可以被归还，那么执行“还车”用例 即可。但是如果超过了还车的时间或汽车受损，按 照规定客户要交纳一定的罚金，这时就不能执行提 供的常规动作。若研讨修改用例“还车”，势必会 增加系统的复杂性，因此可以在用例“还车”中增 加扩展点，即特定条件为超时或损坏，如果满足条 件，将执行扩展用例“交纳罚金”，这样显然可以 使系统更容易被理解。
用例之间的关系
在画用例图的时候，理清用例之间的关系是重 点。用例的关系有泛化(generalization)、扩展 (extend)和包含(include)。其中include和 extend最易混淆。 使用关系uses(UML1.2以后已经不再使用此关 系） 下面我们结合实例彻底理清三者的关系。
基本概念
包含(include)
include为包含关系，当两个或多个用例中共用一组
相同的动作，这时可以将这组相同的动作抽出来作 为一个独立的子用例，供多个基用例所共享。因为 子用例被抽出，基用例并非一个完整的用例，所以 include关系中的基用例必须和子用例一起使用才 够完整，子用例也必然被执行。include关系在用例 图中使用带箭头的虚线表示(在线上标注 <<include>>)，箭头从基用例指向子用例。
泛化关系是一种继承关系，子用例将继承基
用例的所有行为，关系和通信关系，也就是 说在任何使用基用例的地方都可以用子用例 来代替。泛化关系在用例图中使用空心的箭 头表示，箭头方向从子用例指向基用例。
在用例泛化中，子用例表示父用例的特殊形式，子用例继承了 父用例的行为和属性，也可以增加新的行为和属性或覆盖父用 例中的行为。