用例之间的扩展、泛化、包含三种关系有什么异同,请分别举例说明

包含关系和扩展关系的联系和区别

用例之间的关系 如何确定用例之间的关系

用例之间的关系 如何确定用例之间的关系

用例之间的关系 如何确定用例之间的关系

用例之间的关系 如何确定用例之间的关系

用例之间的关系 如何确定用例之间的关系

联系：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。区别：扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。

泛化侧重表示子用例间的互斥性；

用例之间的关系 如何确定用例之间的关系

包含侧重表示被包含用例对Actor提供服务的间接性；

扩展侧重表示扩展用例的触发不定性

如何理解用例和参与者

参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成： 参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。 用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 通讯关联(Communication Association)通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。 以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。 通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。

参考：

用例之间的关系有哪几种？

用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。

4.2.1 包含在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。

在基础用例的流中，我们只需要引用被包含用例即可。

查询-基本流

1. 用户插入

2. 输入密码

用例之间的关系 如何确定用例之间的关系

3. 选择查询

4. 查看帐号余额

5. 包含用例"打印回执"

6. 退出系统，取回

在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。

有时当某一个用例的流过于复杂时，为了简化用例的描述，我们也可以把某一段流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

4.2.2 扩展(extend)

例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。4.2.3 泛化(generalization)

用例，参与者之间有哪些关系

用例与用例之间都有哪些关系。

用例之间的关系 如何确定用例之间的关系

1.关联关系

定义：参与者与用例之间通常用关联关系来描述。

表示方法：带箭头的实线，箭头指向用例。

如图所示：

2. 泛化关系

定义：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。

泛化关系在类间也有。

子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。

表示方法：带空心箭头的实线，箭头指向被泛化（被继承）的用例，即父用例。（PS：泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程，继承是从上到下，从一般到特殊的过程。）

机房收费系统中可以这样应用：

当系统中具有一个或多个用例是一般用例的特化时，就使用用例泛化。

3.包含关系

定义：其中一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为。基础用例可以看到包含用例，并依赖于包含用例的执行结果。但是二者不能访问对方的属性。

表示方法：虚线箭头+<>字样，箭头指向被包含的用例。

使用情况：

（1）如果两个以上用例有重复的功能，则可以将重复的功能分解到另一个用例中。其他用例可以和这个用例建立包含关系。

（2）一个用例的功能太多时，可以用包含关系创建多个子用例。

4.扩展关系（extend）

定义：是把新行为插入到已有用例的方法。

个人感觉可以叫做特殊情况处理。比如去食堂用饭卡打饭，绝大部分人是刷卡，拿饭，两个步骤就完成了。但是如果某个学生的饭卡里没钱了，定不用或者借钱或者赊账等等其他的方式来打饭，而是必须用自己的饭卡来打饭。那么他就要先去给饭卡充值。“饭卡充值”就是“刷卡”的一个扩展用例。“饭卡充值”与“刷卡”就是扩展关系。

表示方法：虚线箭头+<>字样，箭头指向被扩展的用例（即基础用例）。

作用：为处理异常或构建灵活系统框架提供了一种有效的方法。

对比：

包含与扩展的区别。在扩展关系中，基础用例没有扩展也是完整的，而在包含关系中，基础用例依赖于包含用例的执行结果。

总结：

所有的箭头指向都是“被”的一端。

找关系，是一件挺复杂的事儿。从不同的角度看会有不同的结果。找到大前提，再理顺特定环境下的关系，会更加顺手。

标准uml模型中，用例之间的关系有几种类型

一、几个概念

1.组成：用例（Use Case）、参与者（Actor）、系统边界、关联。

2.参与者：用户或者其他系统；

用例：用例是参与者可以感受到的系统服务或功能单元，简单可以理解成功能模块；

系统边界：即系统与系统之间的界限；

关联：即你所谓的各种关系。

二、关系类型

在用例之间，有三种关系（参与者与用例之间有一种关联关系，但应该不是你要的）：

包含（include）关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，注意箭头指向分解出来的功能用例。

扩展关系（extends）：在一定条件下，把新的行为加入到已有的用例中，获得的新用例称为扩展用例（Extension），原有的用例称为基础用例（Base）。注意此时箭头指向基础用例。

泛化关系（Inheritance）：指一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。我感觉也可以理解成继承，此时子用例拥有所有父用例的功能。注意箭头指向父用例。

以上。