第一、 必须明确uses和
extends是
UML1.1中的stereotypes（构造），它们在
UML1.3（Rose2003中已经舍弃了uses关系）中被修订为
include（代替了原有的uses）和extend；
第二、 需要明确的是 include和extend用于表示use cases之间的关联（associations）？？依赖关系；
第三、 有一个例子可以解释 include和extend的用法：在一个eCommerce系统中，有三个用例
Browse Catalog
Place Order
Authorize Credit Purchase这个用例来自外部系统。
其中“Browse Catalog”用例《extend》“Place Order”用例，因为“Place Order”是“Browse Catalog”的特殊情况，用户在browse的时候，可以随时place order。
而“place order”用例《 include》“Authorize Credit Purchase”用例，这是因为用户必须用credit card来支付order，这就存在一个验证credit card的问题，所以“place order”用例一定包含“Authorize Credit Purchase”用例。
用尤克滨先生的话来说就是：比如你上楼,你也许必须要走楼梯( include),当然你有可能在中途去一下洗手间(extend)。
Extend扩展关系，最常用的关系之一（并联）
定义 表示两个用例间有扩展关系，后者是前者信息或者业务功能的扩展。如果A extend B，那么B是A一个条件性执行用例。
格式 表示NewUseCase（A）每次被调用，系统也有可能会调用NewUseCase2（B），但并不是每次都调用NewUseCase2。表示NewUseCase2只是NewUseCase1的一个扩展用例，关系不像 Include那么紧密
例子 比如登录是一个用例，如果我们把登录失败当成一个用例，那么这个用例和登录就是Extend的关系。（当然登录失败我们一般处理为一个备选流）。
说明 是指额外的用力插入，基用力对此扩展不知情扩展关系是处理用例的变体，如果把变体的内容放在同一个用例的可选过程中， 会使得问题变得复杂，难于理解。通常建立基本过程在基本用例中，不同的变体建立成不同的用例扩展基本用例。是对基本的流程进行建模，然后通过扩展用例进行扩展。基本用例不知道扩展用例，扩展用例通常是在基本用例的某一点和特定的条件激发。扩展用例通常是对基本用例的补充和可选的行为建模。扩展关系可以看作是中断。（例如：“查询人员信息”是一个用例，“修改人员信息”是一个用例，则“查询人员信息”extend“修改人员信息”，表明修改人员信息涉及到查询人员信息，这可以使得传统的 audi设计更为精确）
使用条件 if usecase A is mixed into usecase B ( it can be said B allows optional functionality of A to be incorporated into itself),but A is not added as a whole ,it is divided as some parts but all the parts are all added to B . I think this relation can be described as extension .
使用基本原则 1.基用例（即被扩展用例）与扩展用例应该是 相互独立的，换句话说，基用例必须是完整的，扩展的用例与其相分离的。先描述基本行为（或特性）--强制的 再描述添加的额外行为--强制的或可选的 2.扩展依赖的层次深度，一般不应该再去扩展一个扩展用例。
Include是包含关系，最常用的关系之一（串连）
定义 表示两个用例间有包含关系，后者是前者的一部分。如果A Include B，那么A Case就有可能执行B Case，如果A执行B得话，就必须完全执行。
格式 表示NewUseCase1每次被调用，系统也都会调用NewUseCase2。表示NewUseCase2其实是NewUseCase1的一个附属用例。当然，NewUseCase2也可能是另外一个用例的附属用例。
例子 例如看病是个用例，挂号是另一个用例，挂号包含于看病。但是看病时并不一定挂号，因为急诊是无需挂号的（即是说看病用例不包含挂号用例），但如果挂号的话，那就必须完成这个用例。
说明 使用关系是在多个用例包含了重复的内容，避免重复，把这部分共同的用例片断抽出来，可以被多个用例使用。比如取款和转账都需要用户身份验证。 是对多个用例中重复的部分的抽取，并通过用例的 Include关系来表达出来。 包含用例知道被包含用例，通常在文字描述中通过下划线的方式来引用被包含用例。被包含用例的动作流被插入到包含用例的动作流中通常，被包含用例不是一个真正意义上的用例，只是一个片断。 可以命名为Sub Use Case。包含关系可以看作是调用或者引用。
使用条件 the use case being included is known as the inclusion use case , and the use case doing the including as the base use case . the include relationship is appropriate if a complete sequence diagram for the base case would include the sequence diagram for the inclusion case ,and the interactions in the inclusion case are performed without interruption
如何在画用例的时候使用Extend 和 Uses (和 Include似乎并无本质 区别？？姑且先等价二者uses＝ Include)
如果你学过电路的基本知识，这个比喻有用
被使用的用例是多条串联电路中的公共的串联电路。
箭头从使用的主电路指向被使用的公共电路。
扩展关系正好和并联电路有关系。
扩展用例就是一条带有并联和串联电路的电路中，并联部分除一条基本支路以外的所有其他的并联支路。被扩展的用例是，在并联处用基本支路连接的整条串联电路。——每一条并联支路都是对这条基本支路的一个扩展（可替换路径），在这条电路中，串联部分的电路是公共的。
箭头从并联支路指向整条带基本支路的串联电路。
总之，
使用关系是多条路经共享串联路径上的相同部分；
扩展关系是一条带并联路径的通路，并联部分对串联部分的共享。
都是重用机制。
开始建立用例模型时，关注点是主角，要仔细分析主角以及主角的需求。主角要达到什么目的，需要提供什么服务。
把所有向主角提供的服务项目都找到，每个服务项目就是一个用例。
然后就是用例优化
看看用例之间有没有公共部分，把公共部分提出来当作公共服务。
找公共部分时用两种思路：
1.发现多个服务之间有没有相同的服务内容，在发现有的情况下，把相同的部分提出来，看看是否可以当作一个独立的公共服务存在，如果可以，就用使用关系来表达多个服务和这个公共服务的关系。
2.发现一个服务项目内部是否有局部的服务内容有多种可替代的服务供主角选择，在发现有的情况下，把可供选择的服务内容提取出来，看看是否可以当作一个独立的个性化服务存在，如果可以，就用扩展关系表达它和原来服务的关系，它扩展了原来那个服务。它和可被它替换的服务内容，共享了其他没有被替换部分的服务。
总之：
使用关系对应不同流程上的公共功能点；
扩展关系对应公共流程上的个性化功能点。
Rose98中有use这个关系，如果是A use B，那么可以理解为A调用 B。
在Rose2000以后，就没有这个关系了，分别有下面三种关系：
泛化（这个可以理解为继承，Generalize是对于若干类似的动作进行建模，即“some kind of”,比如取款，存款，转账，付费都是ATM上执行的事务。这是一个比较容易混淆的概念。从面向对象的角度来看，父用例和子用例存在isa关系，即子用例isa父用例。也就是说凡是父用例都可以由子用例来替代，其在概念上的意义更强一些。）
Include
Extend
这些解释来源与RUP。
补充：
UML 1.4的规范中定义了三种UC和UC之间的关系，其语义解释是这样的：
1）Extend: 从Use Case A 到Use Case B的一个Extend关系表明B的一个实例是从A所定义的行为中（偶然地或可选地）扩展增加出来的。虚线＋箭头＋stereotype符号
2）Generalization：从UC C到UC D的一个generalization关系表示C是D的一个特例（specialization）。实线＋空心箭头符号。
3） Include：从E到F的一个 include关系表明E的一个实例也包含了F的行为。虚线＋箭头＋stereotype符号。
首先，从1.4的规范中我没有看出二义性。如果遵循这个规范，我觉得自己理解了。但是，我们接着看：
在1.4的规范中，我没有看到uses关系，也可能是我看得不够仔细。我在Rational Rose（2000e）的使用帮助中看到了这个关系，其解释是这样的：
“Uses”是Generalize规范的一种（a stereotype set on Generalize specification）,用于表明一个use case使用了另一个use case的功能。
uses的一个例子（E1）是这样举的：“UC：提款”uses了“UC:验证帐号”, 由于“UC:验证帐号”可能会被其他UC调用（例如：存款，查账等）。
但是E1的uses是一种Generalization关系吗？“UC:提款”是“UC:验证帐号”的一个specialization吗？我一时没能理解。
再来看在Rational Rose帮助中的一个关于 Include的一个例子（E2）：
“UC:购买商品”includes了“UC:把订单加入仓库系统”，因为要“买东西”就要“在系统中增加订单”，前者包含了后者的行为描述。那么E1中不也是类似吗？
Rose 2000e的另外一个 include例子是：
“Fill Customer Order” include “Ship Customer Order”，而“Ship Customer Order”至“Delivery Carrier”有一个单向关联。
但是Fill Customer order怎会包含Ship Customer Order的行为呢？这两者之间可能有前后道工序的联系。要么 include有一种用法用于表示此意的。这是和uses之间的差异？但是这个例子的关系似乎更应该使用extend关系。
在这么多糊涂的分析之后，我一般的做法是不去同时使用uses和 include关系，我一般就用 include关系和extend关系。
关于extend关系的概念还是比较明确的，当从A的某个行为可能发生到另一系列行为的时候（注意这种可选性），就可以把另一系列行为加入B。如果B非常简单的时候，也不会由其他行为扩展到B的话，往往这种扩展我就把它写成一种分支流程了。
至于Generalization关系，应该注重的是C至D的generalization关系含有D共享了C的结构和属性的概念，D可能更加泛化。但从教科书中除了上面没有搞得比较清楚的uses关系外，一般很少会使用到。所以我也的确用得非常少。包括从 UML 1.4 Spec中也没有看到过这方面的例子。
当语义上出现含混的时候，我找过不少资料，感觉这些资料说法各异，因此还是建议以 UML 1.4规范为准，其他资料作为一种辅助。实际上，如果我没有记错，uses、 extends在Rose 98中使用的符号和2000e就不同。因此感觉比较不可靠。当然也可能这两个版本遵循的规范版本不一样，这一点我也不想去深究了。
第二、 需要明确的是 include和extend用于表示use cases之间的关联（associations）？？依赖关系；
第三、 有一个例子可以解释 include和extend的用法：在一个eCommerce系统中，有三个用例
Browse Catalog
Place Order
Authorize Credit Purchase这个用例来自外部系统。
其中“Browse Catalog”用例《extend》“Place Order”用例，因为“Place Order”是“Browse Catalog”的特殊情况，用户在browse的时候，可以随时place order。
而“place order”用例《 include》“Authorize Credit Purchase”用例，这是因为用户必须用credit card来支付order，这就存在一个验证credit card的问题，所以“place order”用例一定包含“Authorize Credit Purchase”用例。
用尤克滨先生的话来说就是：比如你上楼,你也许必须要走楼梯( include),当然你有可能在中途去一下洗手间(extend)。
Extend扩展关系，最常用的关系之一（并联）
定义 表示两个用例间有扩展关系，后者是前者信息或者业务功能的扩展。如果A extend B，那么B是A一个条件性执行用例。
格式 表示NewUseCase（A）每次被调用，系统也有可能会调用NewUseCase2（B），但并不是每次都调用NewUseCase2。表示NewUseCase2只是NewUseCase1的一个扩展用例，关系不像 Include那么紧密
例子 比如登录是一个用例，如果我们把登录失败当成一个用例，那么这个用例和登录就是Extend的关系。（当然登录失败我们一般处理为一个备选流）。
说明 是指额外的用力插入，基用力对此扩展不知情扩展关系是处理用例的变体，如果把变体的内容放在同一个用例的可选过程中， 会使得问题变得复杂，难于理解。通常建立基本过程在基本用例中，不同的变体建立成不同的用例扩展基本用例。是对基本的流程进行建模，然后通过扩展用例进行扩展。基本用例不知道扩展用例，扩展用例通常是在基本用例的某一点和特定的条件激发。扩展用例通常是对基本用例的补充和可选的行为建模。扩展关系可以看作是中断。（例如：“查询人员信息”是一个用例，“修改人员信息”是一个用例，则“查询人员信息”extend“修改人员信息”，表明修改人员信息涉及到查询人员信息，这可以使得传统的 audi设计更为精确）
使用条件 if usecase A is mixed into usecase B ( it can be said B allows optional functionality of A to be incorporated into itself),but A is not added as a whole ,it is divided as some parts but all the parts are all added to B . I think this relation can be described as extension .
使用基本原则 1.基用例（即被扩展用例）与扩展用例应该是 相互独立的，换句话说，基用例必须是完整的，扩展的用例与其相分离的。先描述基本行为（或特性）--强制的 再描述添加的额外行为--强制的或可选的 2.扩展依赖的层次深度，一般不应该再去扩展一个扩展用例。
Include是包含关系，最常用的关系之一（串连）
定义 表示两个用例间有包含关系，后者是前者的一部分。如果A Include B，那么A Case就有可能执行B Case，如果A执行B得话，就必须完全执行。
格式 表示NewUseCase1每次被调用，系统也都会调用NewUseCase2。表示NewUseCase2其实是NewUseCase1的一个附属用例。当然，NewUseCase2也可能是另外一个用例的附属用例。
例子 例如看病是个用例，挂号是另一个用例，挂号包含于看病。但是看病时并不一定挂号，因为急诊是无需挂号的（即是说看病用例不包含挂号用例），但如果挂号的话，那就必须完成这个用例。
说明 使用关系是在多个用例包含了重复的内容，避免重复，把这部分共同的用例片断抽出来，可以被多个用例使用。比如取款和转账都需要用户身份验证。 是对多个用例中重复的部分的抽取，并通过用例的 Include关系来表达出来。 包含用例知道被包含用例，通常在文字描述中通过下划线的方式来引用被包含用例。被包含用例的动作流被插入到包含用例的动作流中通常，被包含用例不是一个真正意义上的用例，只是一个片断。 可以命名为Sub Use Case。包含关系可以看作是调用或者引用。
使用条件 the use case being included is known as the inclusion use case , and the use case doing the including as the base use case . the include relationship is appropriate if a complete sequence diagram for the base case would include the sequence diagram for the inclusion case ,and the interactions in the inclusion case are performed without interruption
如何在画用例的时候使用Extend 和 Uses (和 Include似乎并无本质 区别？？姑且先等价二者uses＝ Include)
如果你学过电路的基本知识，这个比喻有用
被使用的用例是多条串联电路中的公共的串联电路。
箭头从使用的主电路指向被使用的公共电路。
扩展关系正好和并联电路有关系。
扩展用例就是一条带有并联和串联电路的电路中，并联部分除一条基本支路以外的所有其他的并联支路。被扩展的用例是，在并联处用基本支路连接的整条串联电路。——每一条并联支路都是对这条基本支路的一个扩展（可替换路径），在这条电路中，串联部分的电路是公共的。
箭头从并联支路指向整条带基本支路的串联电路。
总之，
使用关系是多条路经共享串联路径上的相同部分；
扩展关系是一条带并联路径的通路，并联部分对串联部分的共享。
都是重用机制。
开始建立用例模型时，关注点是主角，要仔细分析主角以及主角的需求。主角要达到什么目的，需要提供什么服务。
把所有向主角提供的服务项目都找到，每个服务项目就是一个用例。
然后就是用例优化
看看用例之间有没有公共部分，把公共部分提出来当作公共服务。
找公共部分时用两种思路：
1.发现多个服务之间有没有相同的服务内容，在发现有的情况下，把相同的部分提出来，看看是否可以当作一个独立的公共服务存在，如果可以，就用使用关系来表达多个服务和这个公共服务的关系。
2.发现一个服务项目内部是否有局部的服务内容有多种可替代的服务供主角选择，在发现有的情况下，把可供选择的服务内容提取出来，看看是否可以当作一个独立的个性化服务存在，如果可以，就用扩展关系表达它和原来服务的关系，它扩展了原来那个服务。它和可被它替换的服务内容，共享了其他没有被替换部分的服务。
总之：
使用关系对应不同流程上的公共功能点；
扩展关系对应公共流程上的个性化功能点。
Rose98中有use这个关系，如果是A use B，那么可以理解为A调用 B。
在Rose2000以后，就没有这个关系了，分别有下面三种关系：
泛化（这个可以理解为继承，Generalize是对于若干类似的动作进行建模，即“some kind of”,比如取款，存款，转账，付费都是ATM上执行的事务。这是一个比较容易混淆的概念。从面向对象的角度来看，父用例和子用例存在isa关系，即子用例isa父用例。也就是说凡是父用例都可以由子用例来替代，其在概念上的意义更强一些。）
Include
Extend
这些解释来源与RUP。
补充：
UML 1.4的规范中定义了三种UC和UC之间的关系，其语义解释是这样的：
1）Extend: 从Use Case A 到Use Case B的一个Extend关系表明B的一个实例是从A所定义的行为中（偶然地或可选地）扩展增加出来的。虚线＋箭头＋stereotype符号
2）Generalization：从UC C到UC D的一个generalization关系表示C是D的一个特例（specialization）。实线＋空心箭头符号。
3） Include：从E到F的一个 include关系表明E的一个实例也包含了F的行为。虚线＋箭头＋stereotype符号。
首先，从1.4的规范中我没有看出二义性。如果遵循这个规范，我觉得自己理解了。但是，我们接着看：
在1.4的规范中，我没有看到uses关系，也可能是我看得不够仔细。我在Rational Rose（2000e）的使用帮助中看到了这个关系，其解释是这样的：
“Uses”是Generalize规范的一种（a stereotype set on Generalize specification）,用于表明一个use case使用了另一个use case的功能。
uses的一个例子（E1）是这样举的：“UC：提款”uses了“UC:验证帐号”, 由于“UC:验证帐号”可能会被其他UC调用（例如：存款，查账等）。
但是E1的uses是一种Generalization关系吗？“UC:提款”是“UC:验证帐号”的一个specialization吗？我一时没能理解。
再来看在Rational Rose帮助中的一个关于 Include的一个例子（E2）：
“UC:购买商品”includes了“UC:把订单加入仓库系统”，因为要“买东西”就要“在系统中增加订单”，前者包含了后者的行为描述。那么E1中不也是类似吗？
Rose 2000e的另外一个 include例子是：
“Fill Customer Order” include “Ship Customer Order”，而“Ship Customer Order”至“Delivery Carrier”有一个单向关联。
但是Fill Customer order怎会包含Ship Customer Order的行为呢？这两者之间可能有前后道工序的联系。要么 include有一种用法用于表示此意的。这是和uses之间的差异？但是这个例子的关系似乎更应该使用extend关系。
在这么多糊涂的分析之后，我一般的做法是不去同时使用uses和 include关系，我一般就用 include关系和extend关系。
关于extend关系的概念还是比较明确的，当从A的某个行为可能发生到另一系列行为的时候（注意这种可选性），就可以把另一系列行为加入B。如果B非常简单的时候，也不会由其他行为扩展到B的话，往往这种扩展我就把它写成一种分支流程了。
至于Generalization关系，应该注重的是C至D的generalization关系含有D共享了C的结构和属性的概念，D可能更加泛化。但从教科书中除了上面没有搞得比较清楚的uses关系外，一般很少会使用到。所以我也的确用得非常少。包括从 UML 1.4 Spec中也没有看到过这方面的例子。
当语义上出现含混的时候，我找过不少资料，感觉这些资料说法各异，因此还是建议以 UML 1.4规范为准，其他资料作为一种辅助。实际上，如果我没有记错，uses、 extends在Rose 98中使用的符号和2000e就不同。因此感觉比较不可靠。当然也可能这两个版本遵循的规范版本不一样，这一点我也不想去深究了。
5156
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
