UML中几种类间关系
UML中几种类间关系：继承、实现、依赖、关联、聚合、组合的联系与区别
继承
指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性；
实现
指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性；
依赖
可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method 方法中使用；
关联
他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；
聚合
聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；
组合
组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；
对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、
或者类与接口间的纵向关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别的，所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖
UML 关系
UML定义的关系主要有6种：依赖，泛化，关联，实现，聚合和组合。
泛化(Generalization)：通常所说的继承关系。UML中用带空心箭头的实线表示Generalization关系，箭头指向一般个体。
实现(Realize)：元素A定义一个约定，元素B实现这个约定，则B 和A的关系实Realize，B realize A。这个关系最常用于接口。UML 中用空心箭头和虚线表示Realize关系，箭头指向定义约定的元素。依赖(Dependency)：元素A的变化会影响B，但反之不成立，那么B 和A是依赖关系，B依赖A；类属关系和实现关系在语义上讲也是依赖关系，但由于其有更特殊的用途，所以被单独描述。UML中用带箭头的虚线表示Dependency关系，箭头指向被依赖元素。
关联(Association)：元素间的结构化关系，是一种弱关系，被关联的元素间通常可以被独立的考虑。
聚合(Aggregation)：关联关系的一种特例，表示部分和整体的关系。UML中通常用带空心菱形头的实线表示Aggregation关系，菱形头指向整体。
组合(Composition)：组合是聚合关系的变种，表示元素间更强的组合关系。如果是组合关系，如果整体被破坏则个体一定会被破坏，而聚合的个体则可能是被多个整体所共享的，不一定会随着某个整体的
破坏而被破坏。UML中用带实心菱形头的实线表示Compositon关系，菱形头指向整体。
下面将以实例来展示各种关系。
依赖(Dependency)
实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例。更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用，或者对一个类的静态方法的引用。也可利用“依赖”来表示包与包之间的关系。由于包中含有类，可以根据那些包中各个类之间的关系，表示出包与包之间的关系。
关联(Association)
实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。多重度(Multiplicity)修饰符暗示着实例之间的关系。在示范代码中，
Employee可以有0个或更多的TimeCard对象；但是，每个TimeCard 只从属于单独一个Employee。
聚合(Aggregation)
聚合是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上比局部更高的一个级别，而关联暗示两个类上位于相同的级别。
关联和聚合的区别粗纯粹是在概念上的，而且严格反应在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。
合成(Compositon)
合成是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。局
部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。
Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。
(以下代码private TimeCard tc; 应改成TimeCard tc = new TimeCard;)
泛化(Generalization)
泛化表示一个更泛化的元素和一个更具体的元素之间的关系。泛化是用于对继承进行建模的UML元素。
实现(Realization)
实现关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。
UML中的“关系”总结
UML中，事物之间的联系方式，无论是物理上的，还是逻辑上的，都用“关系（relationship）”来建模。在面向对象的建模中，将“关系”细分为三种：依赖、泛化、关联。下面分别说明。
1、依赖（dependency）
依赖是一种使用关系。它表示一个事物的变化会影响到所有使用它的事物的行为。在UML图形表示法中，依赖用一个带方向的虚线来表示，箭头指向被依赖的事物。
针对面向对象的“类”来说，如果一个类A使用另外一个类B作为其函数的参数，或者作为本地变量，那么就说A依赖于B。
事实上，“依赖”关系不仅仅在类之间存在，UML中的“包”之间也经常存在这种关系。
2、泛化
泛化是一种“is-a”的关系，它表示一般事务（父类）和该事物的更具体更特殊的类（子类）之间的一种关系。
在图形上，泛化用一条带有空心大箭头的有向实线来表示，箭头方向指向父类。
作为延伸，或者说是一种特殊的“泛化”, 出现了事务之间的另外一种关系，即“实现（realization）”。在类的实现关系中，一个类描述了另外一个类必须实现的契约，即接口。
也有人说，实现是一种和泛化、依赖都不同的另外一种关系，但不可否认的是，实现和泛化、依赖有着千丝万缕的联系，它是泛化和依赖在语义上的结合；从某种程度上说，可以认为实现是一种泛化，也可以认为实现是一种“依赖”。因此，在图形上，实现就用泛化和依赖的结合形式来表示：用带有空心大箭头的虚线来表示，箭头指向描述契约的那个类。
以上这种形式是实现的规范描述形式，另外针对实现关系，还有一种省略方式：用接口的棒棒糖型表示法——你看到那个大大的棒棒糖了吗？
3、关联（association）
关联表示的是一种结构关系。它描述了一个事物与另外一个事物的对象之间的拥有关系。例如Library类和Book类之间具有一个一对多的关联关系，它表明一个Library可以有多个Book，但是一个Book仅仅只能被一个Library所拥有。
在图形上，关联使用细的实线来表示。
一般地，用细实线连接起来的两个类是双向导航的，也就是说可以从一个类导航到另外一个类。举例来说，Person类和Company类就是双向导航的。但是，有时也可以讲导航限制为单项的，例如User 类和Password类——我们可以从User类导航到Password类，但是不能从Password类导航到User类。这种单向的导航关系，在图形上用带有箭头的实现来表示，箭头的方向表示导航的方向。
上述的简单关联，表示被关联的两个类在概念上其地位是相等的，谁也不比谁中要。然而，有些类之间具有“整体/部分”的关系，也就是说，一个大的整体由较小的部分组成。在UML中，表示这种“组成”关系的建模方式有两种：聚合和组合。
聚合（aggregation）
聚合表示一种has-a的关系，暗示着较大的对象拥有这较小的对象，然而这种拥有关系不是那种一损俱损的强拥有关系，也就是说，“大对象”的生命期结束的时候，“小对象”的生命期并不受影响。举例来说，机场和飞机就是这种聚合关系。
在图形上，聚合用一个空心的菱形加上实线来表示，菱形放置在表示整体的类的那端。
组合（composition）
组合关系是对聚合关系的加强，它说明大对象不仅仅拥有小对象，而且他们是一个有机体，具有共同的生命周期，一损俱损。例如汽车和车轮就是这种关系。
在图形上，组合使用实心的菱形和实线来表示。
UML类图关系
1．关联
A -> B关联表示相识关系，实际表现为类A知道类B的存在，它可以调用类B的公共属性和方法，但没有生命周期的依赖。代码表现为：
Class A
{
Public:
B *b;
}；
Class B
{
};
类图为表现为：
# 存在双向关联和自身关联
2．组合/聚合
组合/聚合是整体与部分的关系。
类A聚合类B，类B可以脱离类A独立存在。代码表现为：
Class A
{
Public: B b;
};
Class B
{
};
类图表现为：
类A组合类B，类A需要知道类B的生存周期，即类A可能控制类B的生成和释放，或者通过某种方式知道类B的生成和释放。
代码表现与聚合相同，类图表现为：
3．依赖
类A依赖类B，那么类A可能需要用到类B的一些方法，要完成类A的所有功能，一定要类B的方法的协助才行，不产生属性，一般是类A的头文件中包含类B的头文件，实际表现为类A的一些方法可能需要把类B作为参数使用。代码表现为：
//A.h
#include “B.h”
Class A
{
Void Func(B *b);
};
//B.h
Class B
{
}
类图表现为：
关联是类之间的一种关系，例如老师教学生，老公和老婆，水壶装水等就是一种关系。这种关系是非常明显的，在问题领域中通过分析直接就能得出。
依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。例如我和锤子，我和锤子本来是没关系的，但在有一次要钉钉子的时候，我用到了它，这就是一种依赖，依赖锤子完成钉钉子这件事情。
组合是一种整体-部分的关系，在问题域中这种关系很明显，直接分析就可以得出的。例如轮胎是车的一部分，树叶是树的一部分，手脚是身体的一部分这种的关系，非常明显的整体-部分关系。
上述的几种关系（关联、聚合/组合、依赖）在代码中可能以指针、引用、值等的方式在另一个类中出现，不拘于形式，但在逻辑上他们就有以上的区别。
这里还要说明一下，所谓的这些关系只是在某个问题域才有效，离开了这个问题域，可能这些关系就不成立了。
4．泛化（继承）
继承关系，动物与狮子老虎大象的关系。代码表现为：
//A.h
#include “B.h”
Class A: public B
{
};
类图表现为：
UML中各种图的画法(全)
UML中各种图的画法(全) 一、UML中基本的图范畴： 在 UML 2 中有二种基本的图范畴：结构图和行为图。每个 UML 图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类，组件和（或）对象图。另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。行为图的实例是活动图，用例图和序列图。 二、UML中的类图： 1.类图的表示： 类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。 描述： 顶部区域显示类的名字。中间的区域列出类的属性。底部的区域列出类的操作。当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。 ·类名：如果是抽象类，则采用斜体 ·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式 n ame : attribute type = default value 如balance : Dollars = 0，这是带有默认值的表达形式 ·类方法列表：name(parameter list) : type of value returned
注意： 在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。 2.继承的表示： 为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。 类名BankAccount和withdrawal操作使用斜体。这表示，BankAccount 类是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount 类使用withdrawal规定抽象操作，并且CheckingAccount 和 SavingsAccount 两个子类都分别地执行它们各自版本的操作。 3.接口的表示： 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。
UML类图符号简介
UML类图符号简介 1. 类（Class）：使用三层矩形框表示。 第一层显示类的名称，如果是抽象类，则就用斜体显示。 第二层是字段和属性。 第三层是类的方法。 注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。 2. 接口：使用两层矩形框表示，与类图的区别主要是顶端有<
UML中继承实现依赖关联聚合组合的联系和区别_线条箭头
UML中几种类间关系：继承、实现、依赖、关联、聚合、组合的联系与区别 继承 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性； 实现 指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性； 依赖 可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过
河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用； 关联 他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我与我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量； 聚合 聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，与关联关系是一致的，只能从语义级别来区分； 组合
UML用例图三种关系详解
1UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend) 扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。 对于一个扩展用例，可以在基用例上有几个扩展点。 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
UML各种图详解
父用例通常是抽象的。
1 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在 UML 2 中，一个接口被认为是类建模元素的特殊化。因此，接口就象类那样绘制，但是长方形的顶部区域也有文本“interface”。 2》UML 支持的可见性类型的标志 3》多重值和它们的表示
4》类图之间的关系有：泛化（继承），依赖，关联，聚合/组合。 1.聚合/组合 聚合是一种特别类型的关联，用于描述“总体到局部”的关系。在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。 举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期-- 这称为合成聚合。举例来说，考虑公司与部门的关系。公司和部门都建模成类，在公司存在之前，部门不能存在。这里Department类的实例依赖于Company类的实例而存在。 ·基本聚合（聚合） 有聚合关系的关联指出，某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父类存在更长的时间。为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。 图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。 ·组合聚合（组合） 组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。 注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。 2.依赖 依赖可以说是要完成C5里的所有功能，一定要有C6的方法协助才行 3.关联 可以分为单向关联，双向关联
uml中的关系
uml中的关系 1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。 单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下：
class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。 自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下： class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。
聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。 代码如下： class C9 ...{ public: C10 theC10; }; class C10 ...{ }; 组合（也有人称为包容）：一般是实心菱形加实线箭头表示，如上图所示，表示的是C8被C7包容，而且C8不能离开C7而独立存在。但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里，就算轮胎离开了汽车，它也是有意义的，这就可以用聚合了。在《敏捷开发》中还说到，A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B 的生成和释放。 他们的代码如下： class C7 ...{ public: C8 theC8; }; class C8 ...{ }; 可以看到，代码和聚合是一样的。具体如何区别，可能就只能用语义来区分了。 3、依赖
UML中的六大关系
在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency) 1. 泛化（Generalization） 【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头指向】：带三角箭头的实线，箭头指向父类 2. 实现（Realization） 【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现. 【箭头指向】：带三角箭头的虚线，箭头指向接口
3. 关联（Association) 【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】：成员变量 【箭头及指向】：带普通箭头的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 下图为自身关联：
4. 聚合（Aggregation） 【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。 聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。 【代码体现】：成员变量 【箭头及指向】：带空心菱形的实心线，菱形指向整体 5. 组合(Composition) 【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。 组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
UML中类图实例
UML中类图实例 接口：空心圆+直线（唐老鸭类实现了…讲人话?）； 依赖：虚线+箭头（动物和空气的关系）； 关联：实线+箭头（企鹅需要知道气候才迁移）； 聚合：空心四边形+实线+箭头（雁群和大雁的关系）； 合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化/继承：空心三角形+实线（动物和鸟的继承关系）；实现：空心三角形+虚线（实现大雁飞翔的接口）； UML类图 解释UML类图：
1. 首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称，如果 是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。 注意前面的符号，…+?表示public, …—? 表示private, …#?表示protected. 2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第 一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。 interface IFly interface Ilanguage { { void Fly(); void Speak(); } } 3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表 示。
4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中应为 空心三角形） class Bird:Animal class WideGoose:IFly { { //继承动物类 //实现飞翔接口 } } 5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。当一 个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。 class Penguin :Bird { private Climate climate;//在企鹅Penguin中，引用到气候Climate对象 } 6. “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个雁群可 以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有” 关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+ 实线箭头表示。
UML类图关系大全
1、关联 双向关联： C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。 在 GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。 使用ROSE 生成的代码是这样的： class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。
单向关联: C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下： class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。 自身关联（反身关联）： 自己引用自己，带着一个自己的引用。 代码如下：
class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合。 聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。 代码如下： class C9 ...{ public: C10 theC10; }; class C10 ...{
UML用例图三种关系详解
. 和泛化(extend)(include)、扩展1UML用例图中包含(generalization）三种关系详解 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。 ;. . (extend)、扩展2 ）用扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）上进行扩展，Extension Point例加以封装，再让它从基用例中声明的扩展点（扩展扩展用例为基用例添加新的行为。从而使基用例行为更简练和目标更集中。因此它能根据基用例中扩展点的当前状态来判断是用例可以访问基用例的属性，但
UML用例图中的包含、扩展、泛化关系
UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解 共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 1、包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend) 扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。 对于一个扩展用例，可以在基用例上有几个扩展点。 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
UML中类图实例
创作编号： GB8878185555334563BT9125XW 创作者：凤呜大王* UML中类图实例 接口：空心圆+直线（唐老鸭类实现了‘讲人话’）； 依赖：虚线+箭头（动物和空气的关系）； 关联：实线+箭头（企鹅需要知道气候才迁移）； 聚合：空心四边形+实线+箭头（雁群和大雁的关系）； 合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化/继承：空心三角形+实线（动物和鸟的继承关系）； 实现：空心三角形+虚线（实现大雁飞翔的接口）； UML类图
解释UML类图： 1. 首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称， 如果是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。 注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected.
2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显 示，第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。 interface IFly interface Ilanguage { { void Fly(); void Speak(); } } 3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实 现来表示。 4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中 应为空心三角形）
class Bird:Animal class WideGoose:IFly { { //继承动物类 //实现飞翔接口 } } 5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。 当一个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。 class Penguin :Bird { private Climate climate;//在企鹅Penguin中，引用到气候Climate对象 } 6. “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个 雁群可以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+ 实线箭头表示。
Uml 类图中六种关系
Uml 类图中六种关系 1.泛化（继承） 泛化也就是继承，A是父类，B是子类，就称B泛化（继承）了A。在这里泛化可以理解成，是功能的一种延伸，因为B拥有A的特性，并且可以在自己的类中增加新的方法。 2. 实现 这个关系用于定义接口和实现类之间的关系。 3. 关联 关联关系表示两个类之间有持久的联系,会增加被依赖对象的成员变量（如下代码），不过关联对象的赋值是在调用某种方法的时候。
class A{ B b; public void XXX(B b){ this.b=b; }; } 上述代码表示：A关联B。例子：关联关系就好像电脑和鼠标，电脑的配置是包括鼠标的，但是到了具体需要鼠标的时候，才会用到鼠标。所以说：类A 关联类B，B则是A中不可或缺（成员变量）但是不急着使用（延迟赋值）的一部分。 4. 依赖 依赖关系不会产生成员变量，往往就是某个方法调用的时候，传入的参数会有被依赖的对象。 class A{ public void XXX(B b){}; } 上述代码表示：A依赖B 例子：依赖关系就好比人和鼠标，人的配置当然不可能包括鼠标，但是人要玩电脑的时候，就需要鼠标。 所以说：类A依赖类B，则B不是A的配件（成员变量），但是A在需要实现某个功能的时候需要B（作为参数传递进来）。
5. 聚合 class A{ B b; A(B b){ this.b=b } } 聚合可以称作为强关联关系，当一个类聚合另一个类的时候，这个类A在自己实例化时就会给关联的这个对象B赋值。不过，这里关联对象B的实例化不是在A中，所以，B的生存与否，不是由A决定。 例子：汽车和轮胎，汽车必须有轮胎才能跑，但是轮胎的生产，可以不在汽车厂而是在别处，轮胎离开这辆汽车，也可以安到其他同型号的汽车上。 所以说：类A聚合类B，B则是A不可或缺的一部分，B的赋值在A实例化的时候，但是B的实例化在A的外部，B的生存周期与A无关。 6.组合 class A{ B b; A(){ this.b=new B() }
UML如何描述类之间的关系
UML中类之间的关系 UML(The Unified Modeling Language)就是统一建模语言，不论它是怎么发展来的，也不论最新的官方Specification或工业标准是哪个版本，我想总结一下工作中最常用的一些知识：用UML语言描述类的关系。 1，关联关系(Association) 关联关系是类(也可以说是对象)之间特定的对应关系。按照对象的数量对比，可以分为： A 一对一 比如公民和公民身份卡之间的对应关系。 B 一对多 一个部门对应0或者多位员工，一般而言一位员工只能属于某一个部门。 C 多对多 用户和服务是多对多的关系，一个用户可以注册0个或多个服务，一个服务则可以被0个或者多个用户复用。比如Windows Live用户可以激活邮件服务、Space服务等，而这些服务不是被一个用户所专有的。
关联的实质 从A类型到B类型的关联是指在A类型中定义了B类型作为属性。如下列代码：package uml; public class Citizen { private CitizenshipCard card; //其他属性 public CitizenshipCard getCard() { return card; } public void setCard(CitizenshipCard card) { this.card = card; } } 上述代码演示了从Citizen 到CitizenshipCard 的关联。注意下图箭头方向： 同样可以建立CitizenshipCard 到Citizen 的关联： 代码表示为： package uml; public class CitizenshipCard { private Citizen citizen; //其他属性
UML类图中的几种关系总结
UML 类图中的几种关系 区分 UML 类图中的几种关系 UML 类图中的”关联关系(association) “、”聚合关系(aggregation) “、”合成关系(compostion)“ 和”依赖关系(dependency)“ 不是很容易区分清楚，《UML distilled》对这几个关系也没有解释的特别清楚。近日翻阅《Java 与模式》，发现其中对这些关系有较为清晰的描述，特摘录如下： 关联关系 (association)： (1)关联关系是类与类之间的联结，它使一个类知道另一个类的属性和方法。 (2)关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 (3)在 Java 或 c++ 中，关联关系是通过使用成员变量来实现的。 class 徒弟 { }; class 唐僧 { protected: list<徒弟> tdlist; }; 聚合关系 (aggregation)： 1、聚合关系是关联关系的一种，是强的关联关系。 2、聚合是整体和部分之间的关系，例如汽车由引擎、轮胎以及其它零件组成。 3、聚合关系也是通过成员变量来实现的。但是，关联关系所涉及的两个类处在同一个层次上，而聚合关系中，两个类处于不同的层次上，一个代表整体，一个代表部分。 4、关联与聚合仅仅从 Java 或 C++ 语法上是无法分辨的，必须考察所涉及的类之间的逻辑关系。 class 引擎 { }; class 轮胎 { };
class 汽车 { protected: 引擎 engine; 轮胎 tyre[4]; }; 合成关系 (composition)： 1、合成关系是关联关系的一种，是比聚合关系还要强的关系。 2、它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。 1 class 肢 { }; class 人 { protected: 肢 limb[4]; }; 依赖关系 (dependency)：
UML中的4种关系
UML中的4种关系 在UML中共有四种关系，这些关系主要描述类和类之间的联系，当然也可以表示用例和用例之间，角色和角色之间的联系。 这四种关系分别是： 关联，依赖，泛化，实现。 下面对这几种关系分别进行介绍。 关联 普通关联 普通关联是最常见的关联关系，如下图所示
注：其中job叫做关联名，employee和employer是角色名；这些都是对关联的修饰 关联关系在具体编程中通常这样表示：一个类作为另一个类的一个属性，如下图所示 关联按照相互性又可分为单向关联（A类是B类的一个属性，而B类却不是A类的属性）和双向关联（A是B得属性，B也是A的属性）
两个类之间可以有多种关系，一个类也可以与多个类发生关系 如果一个类的一个实例对象和另一个实例对象有关联关系，那么我们称之为内部关联
除了普通关联外，还有两种关联是表示整体与部分之间的关系的，他们分别叫做聚合和组合 聚合 聚合表示的总体和部分之间的关系比较弱，部分可以脱离总体而单独存在，二者在时间先后上没有必然关系。
在上图中书和书架都是单独存在的。 组合 组合表示的整体和部分之间的关系比较强，部分不能脱离总体而单独存在，在时间上先有整体才能有部分。
上图中人上提上的任何一部分都不能脱离整体而单独存在，所有的部分都必须属于一个整体。 依赖 依赖关系用一个英文单词可以形象的表示，这个单词是“Using”，即依赖描述的是一种使用关系。 在代码实现时，通常是一个类是另一个类的某个方法的形参，或者在方法的具体实现中用到了那个类。 1中通过“Course”类作为“Professor”类“teach”方法的参数类型来实现
UML中的五种关系
UML中的五种关系（转） 关于设计模式的总结没有落实到代码上，而且设计模式自己确实动手实现的非常少。所以在这一周里，除了看网站开发的视频，着手开始对设计模式进行实现以下。设计模式非常经典，每次看都有不同的收获，写一下自己的收获吧，请大家指正。 在实现设计模式之前，首先来复习以下UML中的五种关系图 <1>依赖 依赖关系用虚线加箭头表示,如图所示: 上图表示:Animal类依赖于Water类（动物依赖于水）。 依赖是类的五种关系中耦合最小的一种关系。因为依赖关系在生成代码的时候，这两个关系类都不会增加属性。这种微弱的关系可以用类之间的相互了解的程度来说明。(下图为代码生成图) 由上图可见生成的代码中Animal类的属性中没有增加Water类。那么Animal 类如何使用Water类呢，有三种方式： 依赖关系的三种表现形式： ①Water类是全局的，则Animal类可以调用它 ②Water类是Animal类的某个方法中的变量，则Animal类可以调用它。代码演示如下：
PS：Animal有一个长大（GrownUp）方法，Water类作为该方法的变量来使用。请注意Water类的生命期，它是当Animal类的GrounUp方法被调用的时候，才被实例化。 持有Water类的是Animal的一个方法而不是Animal类，这点是最重要的。 ③Water类是作为Animal类中某个方法的参数或者返回值时。代码演示如下 无用多说，Water类被Animal类的一个方法持有。生命期随着方法的执行结束而结束。 在依赖关系中，必须采用这三种方法之一。 <2>关联 关联是实线加箭头表示。表示类之间的耦合度比依赖要强。 例：水与气候是关联的，表示图如下 生成代码如下：
UML类图关系(泛化、继承、实现、依赖、关联、聚合、组合)
继承、实现、依赖、关联、聚合、组合的联系与区别 分别介绍这几种关系： 继承 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java 中此类关系通过关键字extends明确标识，在设计时一般没有争议性； 实现 指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性； 依赖 可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method 方法中使用；
关联 他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量； 聚合 聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分； 组合 组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联关系是一致的，只能从语义级别来区分； 对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别的，所以从代码层面并不能完全区分各种关系； 但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖；
UML类之间的关系总结
在UML图中，类之间的关系有如下几种： ①关联关系：Association ②聚合关系：Aggregation ③组合关系：Composition ④依赖关系：Dependency ⑤泛化关系：Generalization ⑥实现关系：Realization 下面对每个关系做简要说明并配上UML类图： ①关联关系：关联关系是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。在UML类图中，用实线连接有关联的对象所对应的类，在使用C#、C++和Java等编程语言实现关联关系时，通常将一个类的对象作为另一个类的属性。下面是UML类图： Person类拥有自行车Bicycle，两个类之间为关联关系 ②聚合关系：聚合关系表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。在聚合关系中，成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。在UML中，聚合关系用带空心菱形的直线表示。UML类图如下： 雁群里面包含了大雁，所以大雁与雁群间是聚合关系 ③组合关系：组合关系也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。在组合关系中，成员类是整体类的一部分，而且整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。在UML中，组合关系用带实心菱形的直线表示。UML类图如下：
人由大脑组成，所以人跟大脑是组合关系。 注意：聚合关系和组合关系非常类似，他们都表示类与类之间部分与整体的关系，但是区别也很明显：聚合关系中成员对象类可以脱离整体类而独立存在（如上面的例子中，大雁可以脱离雁群而独立存在），但组合关系中，成员类与整体类具有相同的声明期，如大脑不可以脱离人独立存在。 ④依赖关系：依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。UML类图如下： 动物的生存离不开氧气，所以动物类与氧气类之间为依赖关系 ⑤泛化关系（继承关系）：泛化关系也就是继承关系，也称为“is-a”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。 在代码实现时，使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C++ 、C#中使用冒号“：”来实现。UML类图如下： 鸟是动物的子类，所以鸟和动物类之间是泛化关系。 ⑥实现关系：接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。UML类图如下： 鸟可以叫，所以鸟实现了叫的接口，则鸟和叫之间是实现关系。 下面给出一个综合了上面六大关系的类图：