UML中几种类间关系
UML类图中关联关系的三种导航方式
UML类图中关联关系的三种导航方式在软件开发中，UML（统一建模语言）类图是一种常用的建模工具，用于描述系统中的类和它们之间的关系。
其中，关联关系是类图中最基本的一种关系，描述了类之间的连接。
在关联关系中，导航方式是指一个类如何访问与之相关联的其他类的对象。
在UML类图中，有三种常见的导航方式：单向导航、双向导航和自关联导航。
1. 单向导航单向导航是指一个类可以访问与之关联的其他类的对象，而被关联的类不能直接访问该类的对象。
这种导航方式常见于一对多的关联关系，其中一个类是主导类，而另一个类是从属类。
举个例子，考虑一个图书馆管理系统，图书馆类与图书类之间存在一种关联关系，一个图书馆可以管理多本图书。
在这种情况下，图书馆类可以通过关联关系访问图书类的对象，但是图书类无法直接访问图书馆类的对象。
2. 双向导航双向导航是指两个类可以互相访问对方的对象。
这种导航方式常见于一对一或多对多的关联关系，其中两个类都可以主动访问对方的对象。
继续以图书馆管理系统为例，考虑一个借阅记录类与读者类之间的关联关系。
一个借阅记录可以关联一个读者，同时一个读者也可以关联多个借阅记录。
在这种情况下，借阅记录类和读者类可以通过关联关系互相访问对方的对象。
双向导航可以提供更灵活的访问方式，但也需要注意双向关联的管理和维护。
在设计时，需要考虑到两个类之间的依赖关系和业务逻辑，避免出现循环依赖或不一致的情况。
3. 自关联导航自关联导航是指一个类与自身存在关联关系，可以访问自身的对象。
这种导航方式常见于树状结构或层级结构的模型。
举个例子，考虑一个组织机构管理系统，组织类与自身存在一种关联关系，一个组织可以包含多个子组织。
在这种情况下，组织类可以通过关联关系访问自身的对象，实现对组织结构的层级管理。
自关联导航可以用于描述递归结构或层级结构，提供了一种方便的方式来处理复杂的关系。
但是，在使用自关联导航时需要注意循环引用的问题，避免出现无限循环或死循环的情况。
类之间的几种关系
类之间的⼏种关系类之间的关联关系UML类图中的关系分为四种：泛化、依赖、关联、实现；关联关系⼜可以细化为聚合和组合。
⼀、泛化（Generalization）泛化是⽗类和⼦类之间的关系，⼦类继承⽗类的所有结构和⾏为。
在⼦类中可以增加新的结构和⾏为，也可以覆写⽗类的⾏为。
⼀般⽤⼀个带空⼼箭头的实线表⽰泛化关系，UML图如下：泛化对应Java中继承关系，即⼦类继承⽗类中出private修饰外的所有东西（变量、⽅法等）。
⽰例代码：public class Animal {}public class Tiger extends Animal {}Tiger继承Animal，因此Tiger与Animal之间是泛化（继承）关系。
这个很好理解。
⼆、依赖（Dependency）依赖关系是⼀种使⽤关系，特定事物的改变有可能会影响到使⽤该事物的事物，反之不成⽴。
在你想显⽰⼀个事物使⽤另⼀个事物时使⽤。
⼀般⽤⼀条指向被依赖事物的虚线表⽰，UML图如下：通常情况下，依赖关系体现在某个类的⽅法使⽤另⼀个类作为参数。
代码⽰例：public class Screwdriver { //螺丝⼑，作为⼈类的⼯具，是⽤来被⼈类使⽤的}public class Person{public void screw(Screwdriver src){ //拧螺丝，需使⽤螺丝⼑}}Person类的screw()⽅法在使⽤时就得传⼊⼀个Screwdriver类型的参数，这样Screwdriver的改变就会影响到Person，因此Person与Screwdriver之间就是依赖关系（Person依赖于Screwdriver）。
三、关联（Association）是⼀种结构关系，说明⼀个事物的对象与另⼀个事物的对象相联系。
给定有关联的两个类，可以从⼀个类的对象得到另⼀个类的对象。
关联有两元关系和多元关系。
两元关系是指⼀种⼀对⼀的关系，多元关系是⼀对多或多对⼀的关系。
UML中的四种关系总结
UML中的四种关系总结UML中的关系主要包含四种：关联关系、依赖关系、泛化关系、实现关系。
当中关联关系还包含聚合关系和组合关系。
1、关联关系（Association）关联关系式⼀种结构化的关系，是指⼀种对象和还有⼀种对象有联系。
给定关联的两个类。
能够从当中的⼀个类的对象訪问到还有⼀个类的相关对象。
关联关系⽤⼀条实线表⽰。
演⽰样例1.1、聚合关系（Aggregation）聚合是关联的特例。
聚合是表⽰总体与部分的关系，即has a 关系。
聚合关系中的总体和部分是能够分离的，他们能够具有各⾃的⽣命周期，部分能够数据多个总体对象。
演⽰样例1.2、组合关系（Composition）组合关系式关联关系的⼀种特例。
他体现的是⼀种contains a的关系。
这样的关系⽐聚合更强。
它相同也体现了总体与部分的关系。
此时总体与部分是不可分的，总体的⽣命周期结束也就意味着部分的⽣命周期结束。
演⽰样例`2、依赖关系（Dependency）依赖关系式类与类之间的连接，表⽰⼀个类依赖于还有⼀个类的定义。
当中⼀个类元素是独⽴的，还有⼀个类元素不是独⽴的，它依赖与独⽴的那个类。
假设独⽴的类改变，将影响依赖与它的那个类。
演⽰样例3、泛化关系（Generalization）泛化关系式⼀个类（⼦类、⼦接⼝）继承另外⼀个类（⽗类、⽗接⼝）的功能。
⼦类还能够添加⾃⼰的新功能。
继承是类与类或者接⼝与⼏⼝之间最常见的关系之中的⼀个。
4、实现关系（Realization）实现关系指的是⼀个class类实现interface接⼝（能够是多个）的功能；实现是类与接⼝之间最常见的关系。
演⽰样例：⽐較聚合关系VS组合关系组合跟聚合差点⼉同样，唯⼀差别就是“部分”不能脱离“总体”⽽单独存在。
关联关系VS聚合关系关联关系中两个类是出于同样的层次。
⽽聚合关系中两个类是出于不平等的层次，⼀个表⽰总体，⼀个表⽰部分。
UML类图关系泛化、继承、实现、依赖、关联、聚合、组合
继承、实现、依赖、关联、聚合、组合的联系与区别分别介绍这几种关系：继承实现指的是一个class 类实现interface 接口（可以是多个）的功能；实现是类与接口之间最常 见的关系；在Java 中此类关系通过关键字implements 明确标识，在设计时一般没有争 议性；依赖可以简单的理解，就是一个类A 使用到了另一个类B ，而这种使用关系是具有偶然性的、、 临时性的、非常弱的，但是B 类的变化会影响到A ；比如某人要过河，需要借用一条船， 此时人与船之间的关系就是依赖;表现在代码层面，为类B 作为参数被类A 在某个method 方法中使用；Inte rfare指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可 以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java 中此类关系通过关键字extends 明确标识，在设计时一般没有争议性；b lnterface_BQlass_A ClaSs_B关联他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这 种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而 且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B 以类属性的形式出现在关联类A 中，也可能是关联类A 引用了一个类型为被关联类B 的全 局变量；聚合聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a 的关系，此 时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象， 也可以为多个整体对象共享；比如计算机与CPU 、公司与员工的关系等；表现在代码层面， 和关联关系是一致的，只能从语义级别来区分；组合组合也是关联关系的一种特例，他体现的是一种contains-a 的关系，这种关系比聚合更强， 也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生 命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联 关系是一致的，只能从语义级别来区分；对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向 关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区 分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别Cl3ss A 十 depend<Qlass.B classBJ ；:；；VoidClass_B的，所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的强弱程度依次为：组合＞聚合＞关联》依赖；聚合跟组合其实都属于关联只不过它们是两种特殊的关联因为本是同根生所以它们之间难 免会有相似之处下面让我们一起来看一下它们之间有何不同聚合与组合的概念相信不用我在此赘述大家就已经了解了下面直接上例子 程老师的《大话》里举大那个大雁的例子很贴切在此我就借用一下大雁喜欢热闹害怕孤独所 以它们一直过着群居的生活这样就有了雁群每一只大雁都有自己的雁群每个雁群都有好多 大雁大雁与雁群的这种关系就可以称之为聚合另外每只大雁都有两只翅膀大雁与雁翅的关 系就叫做组合有此可见聚合的关系明显没有组合紧密大雁不会因为它们的群主将雁群解散 而无法生存而雁翅就无法脱离大雁而单独生存一一组合关系的类具有相同的生命周期聚合关系图：构造函数不同雁群类:[csharp] view plaincopypublic class GooseGroup { public Goose goose; public GooseGroup(Goose goose) { this .goose = goose;} 10. }[csharp] view plaincopy1. 2. 3.4.5. 6.7. 8.9. 组合关系图:从从代码上看这两种关系的区别在于:1.public class GooseGroup2.{3.public Goose goose;4.5.6.public GooseGroup(Goose goose)7.{8.this.goose = goose;9.}10.}大雁类：[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}[csharp] view plaincopy1.public class Goose2.{3.public Wings wings;4.5.public Goose()6.{7.wings=new Wings();8.}9.}聚合关系的类里含有另一个类作为参数雁群类（GooseGroup）的构造函数中要用到大雁（Goose）作为参数把值传进来大雁类（Goose）可以脱离雁群类而独立存在组合关系的类里含有另一个类的实例化大雁类（Goose）在实例化之前一定要先实例化翅膀类（Wings）两个类紧密耦合在一起它们有相同的生命周期翅膀类(Wings)不可以脱离大雁类(Goose)而独立存在信息的封装性不同在聚合关系中，客户端可以同时了解雁群类和大雁类，因为他们都是独立的而在组合关系中，客户端只认识大雁类，根本就不知道翅膀类的存在，因为翅膀类被严密的封装在大雁类中。
10 UML类目关系
2泛化（generalization） 泛化（ ） 定义： 定义： 泛化是一般性事物（称为超类或父类） 泛化是一般性事物（称为超类或父类）和它的较为特殊种类 （称为子类）之间的一种关系，有时称为“is-a-kind-of”关 称为子类）之间的一种关系，有时称为“is- kind-of 关 系。 4点说明： 点说明： 点说明 子类可继承父类的属性和操作，并可有更多的属性和操作； 子类可继承父类的属性和操作，并可有更多的属性和操作； 子类可以替换父类的声明； 子类可以替换父类的声明； 若子类的一个操作的实现覆盖了父类同一个操作的实现， 若子类的一个操作的实现覆盖了父类同一个操作的实现， 这种情况被成为多态性， 这种情况被成为多态性，但两个操作必须具有相同的名字 和参数。 和参数。
注：在大多数情况中，用类和接口之间的泛化来表明继承关系。在UML 在大多数情况中，用类和接口之间的泛化来表明继承关系。 中，也可在其他类目之间创建泛化，例如在结点之间。 也可在其他类目之间创建泛化，例如在结点之间。
表示： 表示： 分离表示法
共享表示法
3细化（realization） 细化（ ） 定义：细化是类目之间的一种语义关系， 定义：细化是类目之间的一种语义关系，其中一个类目规 约了保证另一个类目执行的契约。 约了保证另一个类目执行的契约。 说明：在以下2个地方会使用实现关系： 说明：在以下2个地方会使用实现关系： •接口与实现它们的类和构件之间； 接口与实现它们的类和构件之间； •用况与实现它们的协作之间。 用况与实现它们的协作之间。 表示： 表示：
左图的限定符有一个属性account#，表明：在一个银行中， 左图的限定符有一个属性account#，表明：在一个银行中， account# 一个帐户对应一个用户，或没有对应人员。 一个帐户对应一个用户，或没有对应人员。 右图的限定符有两个属性，它们与Chessboard Chessboard一起确定了 右图的限定符有两个属性，它们与Chessboard一起确定了 Square， Square是其组成部分 是其组成部分。 Square，且 Square是其组成部分。
UML类图的关联与依赖关系的应用举例
UML类图的关联与依赖关系的应用举例在软件开发中，UML（Unified Modeling Language）类图是一种常用的建模工具，用于描述系统中的类、对象以及它们之间的关系。
其中，关联和依赖是两种常见的关系类型，它们在类图中的应用非常广泛。
本文将通过一些实际的示例，介绍关联和依赖关系在UML类图中的应用。
关联关系是指两个类之间的连接，表示一个类与另一个类之间的关系。
这种关系可以是一对一、一对多或多对多的关系。
举个例子来说，假设我们要设计一个图书馆管理系统，其中包含图书和读者两个类。
图书和读者之间存在一个关联关系，即读者可以借阅多本图书，而一本图书也可以被多个读者借阅。
在类图中，可以使用一个带箭头的实线来表示这种关联关系。
箭头指向被关联的类，表示关联的方向。
另一个常见的关系类型是依赖关系。
依赖关系表示一个类依赖于另一个类的情况，即一个类的实现需要另一个类的支持。
举个例子来说，假设我们要设计一个在线购物系统，其中包含商品和购物车两个类。
购物车类需要使用商品类的信息来完成添加商品、删除商品等操作。
在类图中，可以使用一个带箭头的虚线来表示依赖关系。
箭头指向被依赖的类，表示依赖的方向。
除了关联和依赖关系，类图中还可以描述其他类型的关系，如继承、实现和聚合等。
这些关系可以更加细化地描述类与类之间的联系，提供更全面的系统设计信息。
在实际的软件开发过程中，合理使用这些关系类型可以帮助开发人员更好地理解系统的结构和功能。
在现实生活中，关联和依赖关系的应用也非常广泛。
以关联关系为例，我们可以考虑一个学校管理系统。
学校中的学生和教师两个类之间存在一个关联关系，即一个教师可以教授多个学生，而一个学生也可以接受多个教师的教育。
这种关系可以帮助学校管理系统更好地管理学生和教师的信息，实现教学资源的合理分配。
另外，依赖关系在软件开发中也有着重要的应用。
以一个电子邮件系统为例，邮件发送类需要依赖于网络连接类来进行邮件的发送操作。
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类图及类与类之间的关系原⽂地址：类图⽤于描述系统中所包含的类以及它们之间的相互关系，帮助⼈们简化对系统的理解，它是系统分析和设计阶段的重要产物，也是系统编码和测试的重要模型依据。
1. 类类(Class)封装了数据和⾏为，是⾯向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。
在系统中，每个类都具有⼀定的职责，职责指的是类要完成什么样的功能，要承担什么样的义务。
⼀个类可以有多种职责，设计得好的类⼀般只有⼀种职责。
在定义类的时候，将类的职责分解成为类的属性和操作（即⽅法）。
类的属性即类的数据职责，类的操作即类的⾏为职责。
设计类是⾯向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。
在软件系统运⾏时，类将被实例化成对象(Object)，对象对应于某个具体的事物，是类的实例(Instance)。
类图(Class Diagram)使⽤出现在系统中的不同类来描述系统的静态结构，它⽤来描述不同的类以及它们之间的关系。
在系统分析与设计阶段，类通常可以分为三种，分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)，下⾯对这三种类加以简要说明：(1) 实体类：实体类对应系统需求中的每个实体，它们通常需要保存在永久存储体中，⼀般使⽤数据库表或⽂件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。
实体类来源于需求说明中的名词，如学⽣、商品等。
(2) 控制类：控制类⽤于体现应⽤程序的执⾏逻辑，提供相应的业务操作，将控制类抽象出来可以降低界⾯和数据库之间的耦合度。
控制类⼀般是由动宾结构的短语（动词+名词）转化来的名词，如增加商品对应有⼀个商品增加类，注册对应有⼀个⽤户注册类等(3) 边界类：边界类⽤于对外部⽤户与系统之间的交互对象进⾏抽象，主要包括界⾯类，如对话框、窗⼝、菜单等。
在⾯向对象分析和设计的初级阶段，通常⾸先识别出实体类，绘制初始类图，此时的类图也可称为领域模型，包括实体类及其它们之间的相互关系。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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.hClass B{}类图表现为：关联是类之间的一种关系，例如老师教学生，老公和老婆，水壶装水等就是一种关系。