解释和比较用例图中的<<extend>>和<<include>>两种关系

1. 解释和比较用例图中的<<extend>>和<<include>>两种关系

扩展(extend)： extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注>)，箭头从子用例指向基用例。
包含(include)： include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注>)，箭头从基用例指向子用例。

2. 用例图extend include怎么使用

用例图中的扩展和包含，是指用例和用例之间的一种关系。
如下图是一个项目的用户管理系统用例图，其中就有扩展和包含关系：

用户基本信息维护，就包含了个人信息修改和个人资料查询这两个用例，也就是用户基本信息维护这个用例是由个人信息修改和个人资料查询这两个用例组成。
而用户资料维护和导出资料之间是扩展关系，也就是我们不一定必须导出资料，但是系统提供可以导出资料的功能。

3. 用例图extend include怎么使用

用例图中的扩展和包含，是指用例和用例之间的一种关系。如下图是一个项目的用户管理系统用例图，其中就有扩展和包含关系：用户基本信息维护，就包含了个人信息修改和个人资料查询这两个用例，也就是用户基本信息维护这个用例是由个人信息修改和个人资料查询这两个用例组成。而用户资料维护和导出资料之间是扩展关系，也就是我们不一定必须导出资料，但是系统提供可以导出资料的功能。

4. UML系列——用例图中的各种关系（include、extend）

 原文地址:  https://www.cnblogs.com/wolf-sun/p/3413072.html 
    一、参与者与用例间的关联关系 
   参与者与用例之间的通信，也成为关联或通信关系。   
                                           
   包含关系（include）   扩展关系（extend）
    (1)  概念 
   包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。
    (2)表示符号>    
                                                                                   
    控制台程序 
    用例图：    
                                           
   图书管理员处理借书或者还书时的用例图，借书与还书都要考虑是否有overtime的书。   
                                                                                   
   a.如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。
   b.一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统的用例图）
    实例：学生管理系统    
                                           
    注意 ：执行基用例时，每次都必须调用被包含用例。
    （1）概念 
   用一个用例（可选）扩展另一个用例（基本例）的功能。
    （2）符号表示>    
                                           
    控制台程序 
    用例图    
                                           
    （3）使用场合    对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。
   通过上面的例子，怎么区分它们，你心里也有数了，其实在扩展关系中的使用场合也说明了，扩展关系的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。在使用的时候，你考虑这点就可以区分它们。
    1.包含关系 
   a.如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。
   b.一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统的用例图）
    2.扩展关系 
   对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。
   在分析的时候，参考他们的使用场合，你就会豁然开朗......
    系列文章：     [UML]UML系列——用例图Use Case 

5. 一文读懂 UML 用例图

当你脑子里有一个商业案例时，你该怎么向老板介绍呢？一大段文字，或是动手写个 Demo？老板很忙，老板也不见得懂你所说的“高大上”技术，有没有那种实现成本较低但又包含较多信息的表现方式呢？有，画张图呗！
  
 今天起再开个专题，谈谈我们开发中常用到的一些图形建模手段。前言结束，我们从 UML 视图启航。
  
 UML——Unified Modeling Language——统一建模语言，是业务建模阶段最常用和最重要的一种视图。由于它简单易懂，常常用于跨组织的文档或演示的说明中；这里所谓的跨组织指的不仅仅是开发部门间，而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中，第一张图一般都是用例图：是的，就是那个有“小人”的图。
  
 用例图主要有三个部分组成：用例（Use Case）、参与者（Actor），以及它们互相间的关系（Relationship）；形式上就是用椭圆、小人，以及箭头的连线组合。
                                          
 我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP，它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。
  
 画用例图的第一步通常是拖出一个巨大的矩形块，并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System，之后我们会把所有该系统相关的是功能（“用例”）放置在系统内部，系统的相关方（“参与者”）放置在系统的左右两侧。
                                          
 第二个绘制元素就是参与者，即系统相关方，可以是人、组织、外部设备，或是其他系统。在我们这个银行案例里，该 App 的相关方有两个：就是客户（Customer）和银行（Bank）。
                                          
 通常来说，一个用例图中会有两三个参与者，我们会把主要参与者放在系统左侧，次要参与者（主要参与者的回应方）放在右侧；显然我们的 App 主要是面向客户的，所以把客户放在了左边。
  
 第三步就是在系统内添加具体的用例，也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单，只提供如下业务：
                                          
 第四步，我们再把参与者与用例串联起来，就是我们所说的关系（Relationships）。用例图中，关系还可以继续细分：
                                                                                                                          
 最后，所有 UML 视图事实上都可以加注释，专业术语叫延伸（Extension points）和批注（Note）；这两种注释性质形同，都是起说明作用：
                                          
 好了，UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景，在产品设计阶段，我们可以使用用例图为用户、系统和功能服务建立起抽象关系，以便描述产品所呈现的外部动态特征。在一些大厂中，通常由产品经理或是设计师来首先绘制 UML 用例图，再交于开发团队实现。
  
 我们举了一个银行 App 的例子，事实上有点大了；现实开发中，一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时，也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case，然后逐步地为这些较大的功能模块画出细分 Case 的用例图。