UML用例图之泛化(generalization)、扩展(extend)和包含(include)关系--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。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。

需求1：客户响应用户和国际客服可以进行割接通知查询，在页面上有骨干割接查询、省间割接查询、省级割接查询的Tab。
分析：可以很容易看出割接查询和不同的割接子查询Tab之间是继承的关系，所以此处用泛化。用户和客户响应、国际客服也是继承的Actor关系。

需求2：客户响应用户和国际客服可以查看某条割接通知信息，可以在页面上导出割接信息Excel格式，可以查询和该条割接相关联的故障单信息。
分析：因为导出割接和查看相关联的故障单信息都是可选的，就是说我查看割接的时候，也可以不进行这些操作，所以这里用extend关系。也就是导出割接和查看故障单信息扩展了查看割接信息。

需求3：客户响应用户可以以网管系统为来源创建割接通知，在创建割接通知时可以保存为草稿，也可以直接发布割接通知。
分析：由于创建割接通知时，发布割接通知可以同时进行，也可以先存为草稿，所以发布割接是可选的，用extend就比较合适。也就是发布割接扩展了创建割接通知。

需求4：用户在进行业务开通、发布割接通知、发布重保通知及相关跨省的业务时需要进行数据分发。
分析：由于业务开通、重保、割接及其它跨省的业务都需要用到数据分发用例，我们可以将数据分发用例单独抽出来，供各业务使用，这里用include就比较合适。实际的系统中数据分发也是单独抽出来用jms和webservice实现的接口服务。

其它需求：可以看到删除割接通知和查看割接明细也可以做为割接通知查询用例的扩展，因查询列表时，一般可以选择继续查看明细或者删除操作。但在实际化图中，这两个extend可以不画，这里只是为了让大家理解概念。

用例图：大家可以参照着图，好好理解。




加深理解
我们再用另外一个场景的用例说明一下include和extend,因为就这两个玩意比较容易搞混。
销户：因为销户必需先进行账户结算，所以这里用include
停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend.




经过以上的分析，相信大家对三种关系已经有比较好的理解了。大家有什么其它想法或好的见解，欢迎拍砖。

PS：以上用例图用Enterprise Architect 7.5所画，在此推荐一下EA,非常不错。可以替代Visio和Rose了。Visio功能不够强大，Rose太重。唯有EA比较合适。

评论

45 楼 wcy001 2011-04-15  

建模是辅助分析现实世界的，不是用它来实现代码的，用例和代码绝大多数情况下说的是同一件事情。但为什么还要建模呢
就是要跳出来全局审视，避免一头扎入进系统而忽略了一些东西。不过做一些CMS,IMS,HIS之类的都有太多成型的东西了，好多门道都门清了，实在没必要做这样严谨的建模。做大型创新项目才需要这样的建模。

44 楼 walkalone 2011-04-05  

ozzzzzz 写道

如果你有兴趣，看看本版我以前关于用例的发言，就会知道我跟你的看法基本一致。

好的。

ozzzzzz 写道

但是本贴的一个大问题，在于他们试图描绘一些内容，这些内容很类似在编写代码，但是又不能保证这些工作最终能反应到代码中去。而不管你是用文字的方式，还是用图式，对此都是一样的。

赞同。

43 楼 peterwei 2011-04-05  

walkalone 写道

ozzzzzz 写道

用例这个东西自从发明以来就快速发展了，而且逐渐的分成了两派。一个是这个帖子里面反应的，uml用例图的这派。另外一派，则是完全抛开图式，只有文字表达的那派。有两本书可以做代表，一个是你说的这本，另外一本是有效用例模式。其中你的这本的作者就是这派人的代表。

以用例文本描述为核心，辅以图示是我比较认同的做法。

ozzzzzz 写道

而楼主的问题，其实并不是你说的那样，而是我认为的他其实是纯的用例图拉出来，而没有跟后面的代码编写结合起来看。这个问题其实也是个常见问题了，因为大家学习的时候往往是采取从前到后的顺序，比较习惯性的先解决前面的问题后解决拉的问题。

但是方法层次这样做是有问题的，因为实际的应用方法绝对不是流线化的，而仅仅是训练方法才会是流线化结构化的。或者这样说，面向使用的方法不能采取从前到后的流线方式，而这种从前到后的流线方法是面向学习的方法。

我们讨论的泛化，扩展和包含就是一个例子。比如如果我们从编码的角度看，从对象分析的角度看，很难确定这三者究竟会在最终产品层面，也就是代码层面带来什么不同。而且更多的情况是，你在这里分析了半天，结果代码完全都是一样的。这样的事情，就是在扯淡。而把面向学习的方式，使用在面向应用的方面就往往会是经常性的扯淡。结果不仅学的东西搞糊涂了，做起来也更混乱了。

所以我建议将主要精力放在用例描述上。

用例图应该很难和代码结合起来，其表达能力毕竟有限。用例的文本描述则不然。根据用例描述的用例场景所做的设计（用例实现）就比较容易契合到代码。

以前我是图派论的。在最近的项目中，我始终没能说服我们的总架构师和业务专家采用图派论。最终应用过程中是采用你说的用例描述完成需求的。在实际过程中，也比较高效。基本上是业务流程讨论+用例描述搞定需求。至于用例图只是一个总括性和整体性的东西。
ps:在项目过程中我的角色是Team Leader和系统分析师。

42 楼 ozzzzzz 2011-04-05  

walkalone 写道

ozzzzzz 写道

用例这个东西自从发明以来就快速发展了，而且逐渐的分成了两派。一个是这个帖子里面反应的，uml用例图的这派。另外一派，则是完全抛开图式，只有文字表达的那派。有两本书可以做代表，一个是你说的这本，另外一本是有效用例模式。其中你的这本的作者就是这派人的代表。

以用例文本描述为核心，辅以图示是我比较认同的做法。

ozzzzzz 写道

而楼主的问题，其实并不是你说的那样，而是我认为的他其实是纯的用例图拉出来，而没有跟后面的代码编写结合起来看。这个问题其实也是个常见问题了，因为大家学习的时候往往是采取从前到后的顺序，比较习惯性的先解决前面的问题后解决拉的问题。

但是方法层次这样做是有问题的，因为实际的应用方法绝对不是流线化的，而仅仅是训练方法才会是流线化结构化的。或者这样说，面向使用的方法不能采取从前到后的流线方式，而这种从前到后的流线方法是面向学习的方法。

我们讨论的泛化，扩展和包含就是一个例子。比如如果我们从编码的角度看，从对象分析的角度看，很难确定这三者究竟会在最终产品层面，也就是代码层面带来什么不同。而且更多的情况是，你在这里分析了半天，结果代码完全都是一样的。这样的事情，就是在扯淡。而把面向学习的方式，使用在面向应用的方面就往往会是经常性的扯淡。结果不仅学的东西搞糊涂了，做起来也更混乱了。

所以我建议将主要精力放在用例描述上。

用例图应该很难和代码结合起来，其表达能力毕竟有限。用例的文本描述则不然。根据用例描述的用例场景所做的设计（用例实现）就比较容易契合到代码。

如果你有兴趣，看看本版我以前关于用例的发言，就会知道我跟你的看法基本一致。

但是本贴的一个大问题，在于他们试图描绘一些内容，这些内容很类似在编写代码，但是又不能保证这些工作最终能反应到代码中去。而不管你是用文字的方式，还是用图式，对此都是一样的。

41 楼 walkalone 2011-04-05  

ozzzzzz 写道

用例这个东西自从发明以来就快速发展了，而且逐渐的分成了两派。一个是这个帖子里面反应的，uml用例图的这派。另外一派，则是完全抛开图式，只有文字表达的那派。有两本书可以做代表，一个是你说的这本，另外一本是有效用例模式。其中你的这本的作者就是这派人的代表。

以用例文本描述为核心，辅以图示是我比较认同的做法。

ozzzzzz 写道

而楼主的问题，其实并不是你说的那样，而是我认为的他其实是纯的用例图拉出来，而没有跟后面的代码编写结合起来看。这个问题其实也是个常见问题了，因为大家学习的时候往往是采取从前到后的顺序，比较习惯性的先解决前面的问题后解决拉的问题。

但是方法层次这样做是有问题的，因为实际的应用方法绝对不是流线化的，而仅仅是训练方法才会是流线化结构化的。或者这样说，面向使用的方法不能采取从前到后的流线方式，而这种从前到后的流线方法是面向学习的方法。

我们讨论的泛化，扩展和包含就是一个例子。比如如果我们从编码的角度看，从对象分析的角度看，很难确定这三者究竟会在最终产品层面，也就是代码层面带来什么不同。而且更多的情况是，你在这里分析了半天，结果代码完全都是一样的。这样的事情，就是在扯淡。而把面向学习的方式，使用在面向应用的方面就往往会是经常性的扯淡。结果不仅学的东西搞糊涂了，做起来也更混乱了。

所以我建议将主要精力放在用例描述上。

用例图应该很难和代码结合起来，其表达能力毕竟有限。用例的文本描述则不然。根据用例描述的用例场景所做的设计（用例实现）就比较容易契合到代码。

40 楼 ozzzzzz 2011-04-05  

<div class="quote_title">walkalone 写道</div>
<div class="quote_div">
<div class="quote_title">ozzzzzz 写道</div>
<div class="quote_div">
<br>你推荐的书很好，但是非常可惜你的推荐跟本讨论一点关系都没有。<br><br>而且你第二本书说的用例，跟我们讨论的东西根本就不是一个东西。</div>
<p> </p>
<p>何出此言？这2本书是我据主贴内容所荐。</p>
<p> </p>
<p>因为，楼主似乎过于执着用例图和用例关系了。这样并不能带来多少益处，反而带来不少弊端。用例描述才是其核心。</p>
<p> </p>
<p>对于用例分析，一般应该尽可能简化用例关系。特别是要慎用扩展关系，尽量不用泛化关系。其弊大于利。这2本书都给予了不错的指导。</p>
<p> </p>
<p>我们应该将主要精力放在用例描述上。第二本书提供了不错的指导。</p>
</div>
<p>用例这个东西自从发明以来就快速发展了，而且逐渐的分成了两派。一个是这个帖子里面反应的，uml用例图的这派。另外一派，则是完全抛开图式，只有文字表达的那派。有两本书可以做代表，一个是你说的这本，另外一本是有效用例模式。其中你的这本的作者就是这派人的代表。</p>
<p> </p>
<p>而楼主的问题，其实并不是你说的那样，而是我认为的他其实是纯的用例图拉出来，而没有跟后面的代码编写结合起来看。这个问题其实也是个常见问题了，因为大家学习的时候往往是采取从前到后的顺序，比较习惯性的先解决前面的问题后解决拉的问题。</p>
<p> </p>
<p>但是方法层次这样做是有问题的，因为实际的应用方法绝对不是流线化的，而仅仅是训练方法才会是流线化结构化的。或者这样说，面向使用的方法不能采取从前到后的流线方式，而这种从前到后的流线方法是面向学习的方法。</p>
<p> </p>
<p>我们讨论的泛化，扩展和包含就是一个例子。比如如果我们从编码的角度看，从对象分析的角度看，很难确定这三者究竟会在最终产品层面，也就是代码层面带来什么不同。而且更多的情况是，你在这里分析了半天，结果代码完全都是一样的。这样的事情，就是在扯淡。而把面向学习的方式，使用在面向应用的方面就往往会是经常性的扯淡。结果不仅学的东西搞糊涂了，做起来也更混乱了。</p>

39 楼 peterwei 2011-04-05  

<div class="quote_title">walkalone 写道</div>
<div class="quote_div">
<div class="quote_title">ozzzzzz 写道</div>
<div class="quote_div">
<br>你推荐的书很好，但是非常可惜你的推荐跟本讨论一点关系都没有。<br><br>而且你第二本书说的用例，跟我们讨论的东西根本就不是一个东西。</div>
<p> </p>
<p>何出此言？这2本书是我据主贴内容所荐。</p>
<p> </p>
<p>因为，楼主似乎过于执着用例图和用例关系了。这样并不能带来多少益处，反而带来不少弊端。用例描述才是其核心。</p>
<p> </p>
<p>对于用例分析，一般应该尽可能简化用例关系。特别是要慎用扩展关系，尽量不用泛化关系。其弊大于利。这2本书都给予了不错的指导。</p>
<p> </p>
<p>我们应该将主要精力放在用例描述上。第二本书提供了不错的指导。</p>
</div>
<p><br>我并没有过于执着，其实就是相当于一个教程总结一样的东西。实际的项目过程中基本上就是文档描述每个用例就完事了。</p>

38 楼 walkalone 2011-04-05  

<div class="quote_title">ozzzzzz 写道</div>
<div class="quote_div">
<br>你推荐的书很好，但是非常可惜你的推荐跟本讨论一点关系都没有。<br><br>而且你第二本书说的用例，跟我们讨论的东西根本就不是一个东西。</div>
<p> </p>
<p>何出此言？这2本书是我据主贴内容所荐。</p>
<p> </p>
<p>因为，楼主似乎过于执着用例图和用例关系了。这样并不能带来多少益处，反而带来不少弊端。用例描述才是其核心。</p>
<p> </p>
<p>对于用例分析，一般应该尽可能简化用例关系。特别是要慎用扩展关系，尽量不用泛化关系。其弊大于利。这2本书都给予了不错的指导。</p>
<p> </p>
<p>我们应该将主要精力放在用例描述上。第二本书提供了不错的指导。</p>

37 楼 peterwei 2011-04-05  

<div class="quote_title">walkalone 写道</div>
<div class="quote_div">
<p>用例分析，最核心的不是用例图，也不是它们之间的关系，而是用例描述。<br><br><a href="http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/0321193687/ref=sr_1_5?s=books&amp;ie=UTF8&amp;qid=1302001897&amp;sr=1-5">UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd Edition</a></p>
<p> </p>
<p><a href="http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/ref=sr_1_1?ie=UTF8&amp;s=books&amp;qid=1302002002&amp;sr=1-1">Writing Effective Use Cases</a></p>
<p> </p>
<p>这两本书讲得比较清楚了。推荐之！</p>
</div>
<p><br><a href="http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/ref=sr_1_1?ie=UTF8&amp;s=books&amp;qid=1302002002&amp;sr=1-1"><span style="color: #006699;">Writing Effective Use Cases</span></a> 这本我有看过的,还行。但确实我们是在说画用例图的时候以及用例的关系。</p>

36 楼 ozzzzzz 2011-04-05  

[quote=&quot;walkalone&quot;]
用例分析，最核心的不是用例图，也不是它们之间的关系，而是用例描述。

UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd Edition


Writing Effective Use Cases


这两本书讲得比较清楚了。推荐之！


你推荐的书很好，但是非常可惜你的推荐跟本讨论一点关系都没有。

而且你第二本书说的用例，跟我们讨论的东西根本就不是一个东西。

35 楼 walkalone 2011-04-05  

<p>用例分析，最核心的不是用例图，也不是它们之间的关系，而是用例描述。<br><br><a href="http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/0321193687/ref=sr_1_5?s=books&amp;ie=UTF8&amp;qid=1302001897&amp;sr=1-5">UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd Edition</a></p>
<p> </p>
<p><a href="http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/ref=sr_1_1?ie=UTF8&amp;s=books&amp;qid=1302002002&amp;sr=1-1">Writing Effective Use Cases</a></p>
<p> </p>
<p>这两本书讲得比较清楚了。推荐之！</p>

34 楼 housheng33 2011-04-05  

。。。。。。。加油看～～～

33 楼 ozzzzzz 2011-04-02  

to peterwei
建模就是建模啊，建模不是编码啊。既然是模型，肯定就不是实际的产品。也就是说既然是模型，就不能也不应该，也不可能过细。而用例是可以做的很细的，细到在很多时候联代码都不能反应出这些细节。当然我不能说这样的用例分析就没有用，毕竟在业务分析的观点下，这样可以更清晰的解释业务的全景和业务原子，但是很遗憾你不是业务分析人员。

其次你说的什么用例在需求分析之中的用途等等，我建议你看看我以前发布在本版的关于用例和UP的讨论，那里面写的很详细了。

32 楼 peterwei 2011-04-02  

ozzzzzz 写道

to peterwei

你理解错了。我的意思是，你做的事情全都没有错误，但是你做的事情没有价值。

其次，我注意到你用到了建模这个词。但是我认为，你现在根本就不是在建模。

最终我最奇怪的是你究竟是在做什么，因为我根本就看不出你到底是要做什么？是要编程，还是要分析，还是要。。。。。？？？？？

说实话，我并没有在任何一个项目中完全的uml建模。实际的项目中一般就是需求获取、用例分析、类图、时序图，进入迭代开发。我很想知道你眼中的建模是什么概念。
其实在实际的工作中，分析这个用例的时候，需求基本上已经从客户那边获取完毕。这个阶段算是分析细化阶段，进一步是从用例分析中为了工作任务的细化和分解。好吧，我也承认为了让我的文档里更好看些。当然也算是写一下小教程，让完全不知道的人学习一下。

31 楼 ozzzzzz 2011-04-01  

to peterwei

你理解错了。我的意思是，你做的事情全都没有错误，但是你做的事情没有价值。

其次，我注意到你用到了建模这个词。但是我认为，你现在根本就不是在建模。

最终我最奇怪的是你究竟是在做什么，因为我根本就看不出你到底是要做什么？是要编程，还是要分析，还是要。。。。。？？？？？

30 楼 peterwei 2011-04-01  

玲cc 写道

EA还是一个很强大的工具的
lz什么时候发这方面的文章？

因为下周要入职新公司了，所以时间上不能保证连续。一有空闲就会写一些总结。

29 楼 peterwei 2011-04-01  

ozzzzzz 写道

说真的，如果use case谈到这一步，基本就全是扯淡了。

希望大家回去面壁几天，把我的意思好好理解一下。

好吧，o6z喷我了,果断迎喷。我又认真看了一下我的用例分析，应该是没有什么错误的。如果真有，请指正。
那么我来面壁一下o6z说的扯谈，这两个字应该是重点。
1.他是不是说uml建模无用论？这个应该各有各的说法。
2.他是不是说用例分析的粒度太细了？这个可能性倒是很大。我来推断他认为合理的粒度：在做需求分析的时候，只要捕获到某个功能点和说明就行了，不必去管这些include,extends之类的事情，他认为是扯淡的。那么是否意味着他的意思是得到用例list后，尽快进入开发，细化的问题不用管，在开发中不断迭代完善？

28 楼 玲cc 2011-04-01  

EA还是一个很强大的工具的
lz什么时候发这方面的文章？

27 楼 ozzzzzz 2011-04-01  

说真的，如果use case谈到这一步，基本就全是扯淡了。

希望大家回去面壁几天，把我的意思好好理解一下。

26 楼 lgstarzkhl 2011-03-31  

怎么这帖子跑项目管理里边来了？