UML类图关系大全
UML类图五种关系与代码的对应关系
UML类图五种关系与代码的对应关系转：UML类图中的五种关系的耦合强弱⽐较：依赖<关联<聚合<组合<继承⼀、依赖关系：（⼀）说明虚线+箭头可描述为：Uses a依赖是类的五种关系中耦合最⼩的⼀种关系。
因为在⽣成代码的时候，这两个关系类都不会增加属性。
（⼆）依赖关系图与代码的对应关系（PS：依赖关系：Animal依赖于Water（动物依赖于⽔））[csharp]1. Public class Animal()2. {3. Public Animal(){}4. }5.6. Public class Water()7. {8. public Water(){}9. }可以看到⽣成的两个类的代码中什么都没有添加。
（三）思考：Animal类如何使⽤Water类呢？或者说依赖关系到底是如何体现的呢？1、表现形式1Water类是全局的，则Animal类可以调⽤它2、表现形式2Water类是 Animal类的某个⽅法中的变量，则Animal类可以调⽤它。
[csharp]1. Public class Animal {2. Public void Grownup() {3. Water water =null;4. }5. }注意1： Water类的⽣命期，它是当Animal类的GrounUp⽅法被调⽤的时候，才被实例化。
注意2：持有Water类的是Animal的⼀个⽅法⽽不是Animal类，这点是最重要的！3、表现形式3Water类是作为Animal类中某个⽅法的参数或者返回值[csharp]1. Public Animal {2. Public Water Grownup(Waterwater) {3. return null;4. }5. }注意： Water类被Animal类的⼀个⽅法持有。
⽣命期随着⽅法的执⾏结束⽽结束。
⼆、关联关系（⼀）说明实线+箭头可描述为：Has a关联关系⽤实线，表⽰类之间的耦合度⽐依赖强在⽣成代码的时候，关联关系的类会增加属性。
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而独立存在。
但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。
UML图中类之间的关系_依赖,泛化,关联,聚合,组合,实现答辩
UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现1.2.3.4.5.6.类与类图1 类(Class封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。
2 在系统中，每个类具有一定的职责，职责指的是类所担任的任务，即类要完成什么样的功能，要承担什么样的义务。
一个类可以有多种职责，设计得好的类一般只有一种职责，在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。
3 类的属性即类的数据职责，类的操作即类的行为职责一、依赖关系(Dependence依赖关系（Dependence）：假设A类的变化引起了B 类的变化，则说名B类依赖于A类。
• 依赖关系(Dependency 是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。
大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。
• 在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。
[java] view plaincopyprint?1. public class Driver2. {3. public void drive(Car car4. {5. car.move(;6. }7. ……8. }9. public class Car10. {11. public void move(12. {13. ......14. }15. ……16. }{car.move(;}……}public class Car{public void move({......}……}依赖关系有如下三种情况：1、A类是B类中的（某中方法的）局部变量；2、A类是B类方法当中的一个参数；3、A类向B类发送消息，从而影响B类发生变化；GeneralizationGeneralization A是B和C的父类，B,C具有公共类（父类）A，说明A是B,C的一般化（概括，也称泛化）• 泛化关系(Generalization也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
UML之关系详解（类图）
UML之关系详解（类图）关联、依赖、聚合、组合、泛化、实现简单解释：关联：连接模型元素及链接实例，用一条实线来表示；依赖：表示一个元素以某种方式依赖于另一个元素，用一条虚线加箭头来表示；聚合：表示整体与部分的关系，用一条实线加空心菱形来表示；组成：表示整体与部分的有一关系，用一条实线加实心菱形来表示；泛化（继承）：表示一般与特殊的关系，用一条实线加空心箭头来表示；实现：表示类与接口的关系，用一条虚线加空心箭头来表示；注意：泛化关系和实现关系又统称为一般关系；总之：一般关系表现为继承或实现(is a)；关联关系、聚合关系、合成(聚合)/组合关系表现为成员变量(has a)，依赖关系表现为函数中的参数(use a)；二、类与类之间的关系一般关系：泛化、实现特殊关系：由弱到强是: 没关系 > 依赖 > 关联 > 聚合 > 组合。
UML中讲到类之间的关系：•依赖关系：类之间使用关系•泛化关系：类之间一般/特殊关系•关联关系：对象之间结构关系•实现关系：类中规格说明和实现之间关系三、关系详解（1）聚合与组合首先说明一下不容易混淆的概念：聚合(Aggregation)•一种特殊类型的关联。
•表示整体与部分关系的关联。
•描述了“has a”的关系。
•部分事物的对象可以属于多个聚合对象。
部分事物的对象与聚合对象的生存期无关，删除了它的聚合对象，不一定就随即删除了代表部分事物的对象。
组合(Composite)•聚合关系中的一种特殊情况，是更强形式的聚合，又称强聚合。
•成员对象的生命周期取决于组合的生命周期。
•组合不仅控制着成员对象的行为，而且控制着成员对象的创建和解构。
（2）依赖依赖(dependency)：指一个模型元素的变化必影响到另一个模型元素的变化。
可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method 方法中使用（使用依赖之参数传递）。
UML类图关系
UML类图关系详解1. 依赖（Dependency）实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例。
更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。
其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。
也可利用“依赖”来表示包和包之间的关系。
由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。
2. 关联（Association）实体之间的一个结构化关系表明对象是相互连接的。
箭头是可选的，它用于指定导航能力。
如果没有箭头，暗示是一种双向的导航能力。
在Java中，关联转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。
可为一个关联附加其他修饰符。
多重性（Multiplicity）修饰符暗示着实例之间的关系。
在示范代码中，Employee可以有0个或更多的TimeCard对象。
但是，每个TimeCard只从属于单独一个Employee。
3. 聚合（Aggregation）聚合是关联的一种形式，代表两个类之间的整体/局部关系。
聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。
聚合也转换成Java中的一个实例作用域变量。
关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。
聚合还暗示着实例图中不存在回路。
换言之，只能是一种单向关系。
4. 合成（Composition）合成是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。
合成也是非共享的。
所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。
局部不可与其他整体共享。
但整体可将所有权转交给另一个对象，后者随即将承担生存期职责。
Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。
UML类图标准总结
类图(class diagram)描述了模型的静态结构，包括模型中的类的类的内部结构以及于其他类的关系，在结构化设计一个系统的时候类图可以让我们的思路更加清晰。
一个类与其他的类常见的关系(我所接触到的关系)有：1.一般化关系2.关联关系3.聚合关系4.组合关系（合成关系）5.依赖关系其中，聚合关系合成关系又属于关联关系。
一般化关系表现是与类之间是(is a)的关系。
也就是类与类之间的继承，接口于接口之间的继承或者是对一个接口的实现。
表示方法是用一个空心箭头+实线，箭头指向父类。
或用空心肩头加虚线（如果富父类是接口的话)如图1，User定义了系统中一个用户的原型，客户Customer继承了User类并且有自己特有的方法。
管理员Manager类也继承了User类，并且又自己特有的方法，而且Manager为了能够管理客户还实现了Cmanage这个接口，也就具备了Cmanage的所有功能，可以对客户的余额进行操作，而且还可以删除一个客户。
关联关系表现为类与类之间的(has a)关系。
它使一个类知道另一个类的属性和方法。
关联关系表示的是类与类之间的持久关系，这种关系一般是表示一种业务逻辑上的关系，需要保存到数据库中的。
如图2.学生Student中存在一个班级Class的引用。
在student中可以直接根据引用访问到Class.同时在数据库中存在两张表tb_student,tb_class，在表tb_student中有一个字段存储了所关联的class记录的id。
用箭头+实指向被关联的类聚合关系是关联的一种，是一种强关联关系。
聚合关系还体现了一种整体与个体的关系。
如图3：商品ShangPin是独立的，一张进货单JinHuoDan内可以又很多个商品。
可以说进货单JinHuoDan是整体，商品ShangPin是个体。
可以由进货单JinHuoDan 导航到每个进货单包含的商品。
空心菱形+实线+箭头指向部分。
依赖关系是表现为类与类之间的一种(use a）的关系。
UML类图关系
UML类图关系1、类类图是⾯向对象系统建模中最常⽤和最重要的图，是定义其它图的基础。
类图主要是⽤来显⽰系统中的类、接⼝以及它们之间的静态结构和关系的⼀种静态模型。
类图的3个基本组件：类名、属性、⽅法。
2、泛化generalization(继承)表⽰is-a的关系，是对象之间耦合度最⼤的⼀种关系，⼦类继承⽗类的所有细节。
直接使⽤语⾔中的继承表达。
在类图中使⽤带三⾓箭头的实线表⽰，箭头从⼦类指向⽗类。
3、实现(Realization)在类图中就是接⼝和实现的关系。
在类图中使⽤带三⾓箭头的虚线表⽰，箭头从实现类指向接⼝。
4、依赖(Dependency)对象之间最弱的⼀种关联⽅式，是临时性的关联。
代码中⼀般指由局部变量、函数参数、返回值建⽴的对于其他对象的调⽤关系。
⼀个类调⽤被依赖类中的某些⽅法⽽得以完成这个类的⼀些职责。
在类图使⽤带箭头的虚线表⽰，箭头从使⽤类指向被依赖的类。
5、关联(Association)对象之间⼀种引⽤关系，⽐如客户类与订单类之间的关系。
这种关系通常使⽤类的属性表达。
关联⼜分为⼀般关联、聚合关联与组合关联。
5.1、⼀般关联在类图使⽤带箭头的实线表⽰，箭头从使⽤类指向被关联的类。
可以是单向和双向。
5.2、聚合(Aggregation)表⽰has-a的关系，是⼀种不稳定的包含关系。
较强于⼀般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。
如公司和员⼯的关系，公司包含员⼯，但如果公司倒闭，员⼯依然可以换公司。
在类图使⽤空⼼的菱形表⽰。
5.3、组合(Composition)表⽰contains-a的关系，是⼀种强烈的包含关系。
组合类负责被组合类的⽣命周期。
是⼀种更强的聚合关系。
部分不能脱离整体存在。
如公司和部门的关系，没有了公司，部门也不能存在了。
在类图使⽤实⼼的菱形表⽰。
5.4、多重性(Multiplicity)通常在关联、聚合、组合中使⽤。
就是代表有多少个关联对象存在。
使⽤数字..星号（数字）表⽰。
UML类图符号 各种关系说明以及举例
UML类图符号各种关系说明以及举例UML中描述对象和类之间相互关系的方式包括：依赖（Dependency），关联（Association），聚合（Aggregation），组合（Composition），泛化（Generalization），实现（Realization）等。
∙依赖（Dependency）：元素A的变化会影响元素B，但反之不成立，那么B和A的关系是依赖关系，B依赖A；类属关系和实现关系在语义上讲也是依赖关系，但由于其有更特殊的用途，所以被单独描述。
uml中用带箭头的虚线表示Dependency关系，箭头指向被依赖元素。
∙泛化（Generalization）：通常所说的继承（特殊个体is kind of 一般个体）关系，不必多解释了。
uml中用带空心箭头的实线表示Generalization关系，箭头指向一般个体。
∙实现（Realize）：元素A定义一个约定，元素B实现这个约定，则B和A的关系是Realize，B realize A。
这个关系最常用于接口。
uml中用空心箭头和虚线表示Realize关系，箭头指向定义约定的元素。
∙关联（Association）：元素间的结构化关系，是一种弱关系，被关联的元素间通常可以被独立的考虑。
uml中用实线表示Association关系，箭头指向被依赖元素。
∙聚合（Aggregation）：关联关系的一种特例，表示部分和整体（整体has a 部分）的关系。
uml中用带空心菱形头的实线表示Aggregation关系，菱形头指向整体。
∙组合（Composition）：组合是聚合关系的变种，表示元素间更强的组合关系。
如果是组合关系，如果整体被破坏则个体一定会被破坏，而聚合的个体则可能是被多个整体所共享的，不一定会随着某个整体的破坏而被破坏。
uml中用带实心菱形头的实线表示Composition关系，菱形头指向整体。
其中依赖（Dependency）的关系最弱，而关联（Association），聚合（Aggregation），组合（Composition）表示的关系依次增强。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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、依赖依赖:指C5可能要用到C6的一些方法，也可以这样说，要完成C5里的所有功能，一定要有C6的方法协助才行。
C5依赖于C6的定义，一般是在C5类的头文件中包含了C6的头文件。
ROSE对依赖关系不产生属性。
注意，要避免双向依赖。
一般来说，不应该存在双向依赖。
ROSE生成的代码如下：// C5.h#include "C6.h"class C5...{};// C6.h#include "C5.h"class C6...{};虽然ROSE不生成属性，但在形式上一般是A中的某个方法把B的对象作为参数使用(假设A依赖于B)。
如下：#include "B.h"class A...{void Func(B &b);}那依赖和聚合\组合、关联等有什么不同呢？关联是类之间的一种关系，例如老师教学生，老公和老婆，水壶装水等就是一种关系。
这种关系是非常明显的，在问题领域中通过分析直接就能得出。
依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。
例如我和锤子，我和锤子本来是没关系的，但在有一次要钉钉子的时候，我用到了它，这就是一种依赖，依赖锤子完成钉钉子这件事情。
组合是一种整体-部分的关系，在问题域中这种关系很明显，直接分析就可以得出的。
例如轮胎是车的一部分，树叶是树的一部分，手脚是身体的一部分这种的关系，非常明显的整体-部分关系。
上述的几种关系（关联、聚合/组合、依赖）在代码中可能以指针、引用、值等的方式在另一个类中出现，不拘于形式，但在逻辑上他们就有以上的区别。
这里还要说明一下，所谓的这些关系只是在某个问题域才有效，离开了这个问题域，可能这些关系就不成立了，例如可能在某个问题域中，我是一个木匠，需要拿着锤子去干活，可能整个问题的描述就是我拿着锤子怎么钉桌子，钉椅子，钉柜子；既然整个问题就是描述这个，我和锤子就不仅是偶然的依赖关系了，我和锤子的关系变得非常的紧密，可能就上升为组合关系（让我突然想起武侠小说的剑不离身，剑亡人亡...）。
这个例子可能有点荒谬，但也是为了说明一个道理，就是关系和类一样，它们都是在一个问题领域中才成立的，离开了这个问题域，他们可能就不复存在了。
4、泛化（继承）泛化关系：如果两个类存在泛化的关系时就使用，例如父和子，动物和老虎，植物和花等。
ROSE生成的代码很简单，如下：#include "C11.h"class C12 : public C11...{};5、这里顺便提一下模板上面的图对应的代码如下：template<int>class C13...{};这里再说一下重复度，其实看完了上面的描述之后，我们应该清楚了各个关系间的关系以及具体对应到代码是怎么样的，所谓的重复度，也只不过是上面的扩展，例如A和B有着“1对多”的重复度，那在A中就有一个列表，保存着B对象的N个引用，就是这样而已。
好了，到这里，已经把上面的类图关系说完了，希望你能有所收获了，我也费了不少工夫啊（画图、生成代码、截图、写到BLOG上，唉，一头大汗）。
不过如果能让你彻底理解UML类图的这些关系，也值得了。
:)+++++++++++++++++++++++++++++++++++++++++++++++++++++在UML建模中，对类图上出现元素的理解是至关重要的。
开发者必须理解如何将类图上出现的元素转换到Java中。
以java为代表结合网上的一些实例，下面是个人一些基本收集与总结：基本元素符号：1. 类（Classes）类包含3个组成部分。
第一个是Java中定义的类名。
第二个是属性（attributes）。
第三个是该类提供的方法。
属性和操作之前可附加一个可见性修饰符。
加号（+）表示具有公共可见性。
减号（-）表示私有可见性。
#号表示受保护的可见性。
省略这些修饰符表示具有package（包）级别的可见性。
如果属性或操作具有下划线，表明它是静态的。
在操作中，可同时列出它接受的参数，以及返回类型，如下图所示：2. 包（Package）包是一种常规用途的组合机制。
UML中的一个包直接对应于Java中的一个包。
在Java 中，一个包可能含有其他包、类或者同时含有这两者。
进行建模时，你通常拥有逻辑性的包，它主要用于对你的模型进行组织。
你还会拥有物理性的包，它直接转换成系统中的Java包。
每个包的名称对这个包进行了惟一性的标识。
3. 接口（Interface）接口是一系列操作的集合，它指定了一个类所提供的服务。
它直接对应于Java 中的一个接口类型。
接口既可用下面的那个图标来表示（上面一个圆圈符号，圆圈符号下面是接口名，中间是直线，直线下面是方法名），也可由附加了<<interface>>的一个标准类来表示。
通常，根据接口在类图上的样子，就能知道与其他类的关系。
关系：1. 依赖（Dependency）实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例。
更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。
其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。
也可利用“依赖”来表示包和包之间的关系。
由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。
2. 关联（Association）实体之间的一个结构化关系表明对象是相互连接的。
箭头是可选的，它用于指定导航能力。
如果没有箭头，暗示是一种双向的导航能力。
在Java中，关联转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。
可为一个关联附加其他修饰符。
多重性（Multiplicity）修饰符暗示着实例之间的关系。
在示范代码中，Employee可以有0个或更多的TimeCard对象。
但是，每个TimeCard只从属于单独一个Employee。
3. 聚合（Aggregation）聚合是关联的一种形式，代表两个类之间的整体/局部关系。
聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。
聚合也转换成Java中的一个实例作用域变量。
关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。
聚合还暗示着实例图中不存在回路。
换言之，只能是一种单向关系。
4. 合成（Composition）合成是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。
合成也是非共享的。
所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。
局部不可与其他整体共享。
但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。
Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。
5. 泛化（Generalization）泛化表示一个更泛化的元素和一个更具体的元素之间的关系。
泛化是用于对继承进行建模的UML元素。
在Java中，用extends关键字来直接表示这种关系。
6. 实现（Realization）实例关系指定两个实体之间的一个合同。
换言之，一个实体定义一个合同，而另一个实体保证履行该合同。
对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。
像聚合还分为：非共享聚合、共享聚合、复合聚合等。
以及其它内容，下次再补充。
UML 2 中的阴和阳在 UML 2 中有二种基本的图范畴：结构图和行为图。
每个 UML 图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类，组件和（或）对象图。
另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。
行为图的实例是活动图，用例图和序列图。
大体上的结构图如同我所说的，结构图显示建模系统的静态结构。
关注系统的元件，无需考虑时间。
在系统内，静态结构通过显示类型和它们的实例进行传播。
除了显示系统类型和它们的实例，结构图至少也显示了这些元素间的一些关系，可能的话，甚至也显示它们的内部结构。