UML类图与类的关系详解

来源：http://www.uml.org.cn/oobject/201104212.asp

来源：http://blog.csdn.net/longronglin/article/details/1454329

来源：http://www.cnblogs.com/mimime/p/5827895.html

plantuml 官网：http://plantuml.com/

PlantUML语言参考手册中文版：http://download.csdn.net/detail/freeking101/9917766

统一建模语言(UML:Unified Modeling Language)

1．能够从不同的角度来看待系统的结构，行为，功能（需求）。

2．能够在不同抽象程度上考虑系统，而仅仅是源代码是不够的。源代码是非常细化的内部结构，不能用来建造复杂的系统。

UML图及其目的
当你……	使用UML图……
在分析阶段	用例图，它们包含和系统交互的实体以及需要实现的功能点。
	活动图，它们将焦点集中于问题域（人们以及其它主体工作的实际空间，程序的主题域）的工作流而不是程序的逻辑流。
观察对象交互	交互图，它们展示特定的对象彼如何此交互。由于它们处理特定案例而不是一般情况，因此它们在检验需求和检验设计时都能有所帮助。最流行的交互图是顺序图。
在设计阶段	类图，它们详述类与类之间的关系。
观察对象的行为，这些行为因对象所处的状态而不同	状态图，它们详述一个对象可能处于的不同状态以及这些状态之间的过渡。
在布署阶段	布署图，它们展示了不同的模块将被如何部署。我不会在此讨论它们。

在画类图的时候，理清类和类之间的关系是重点。类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。其中关联又分为一般关联关系和聚合关系(Aggregation)，合成关系(Composition)。下面我们结合实例理解这些关系。

基本概念

类图（Class Diagram）: 类图是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。

类图的3个基本组件：类名、属性、方法。 

1、泛化（继承）

泛化(generalization)：表示is-a的关系，是对象之间耦合度最大的一种关系，子类继承父类的所有细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表示，箭头从子类指向父类。

【箭头指向】：带三角箭头的实线，表示继承一个基类，CutoverNotice类 继承 Notice类、BizEnsureNotice类 也 继承 Notice类。

【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。

【泛化例子】：老虎是动物的一种，既有老虎的特性也有动物的共性。

2、实现

实现（Realization）:在类图中就是接口和实现的关系。这个没什么好讲的。在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。

【箭头指向】：带三角箭头的虚线，箭头指向接口，表示  NoticeServiceImpl类  实现  NoticeService类中的 接口 定义。

【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

3、依赖

依赖(Dependency)：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。

【箭头指向】：带箭头的虚线，指向被使用者，

【依赖关系】：是一种使用关系，表示类之间的调用关系，即一个类的实现需要另一个类的协助，所以尽量不使用互相依赖。

【代码体现】：类NoticeServiceImpl访问类Notice或者类BaseDao的属性或者方法，或者类NoticeServiceImpl负责实例化类Notice或者实例化类BaseDao，可以说类NoticeServiceImpl依赖类Notice 和 BaseDao（局部变量、方法的参数或者对静态方法的调用）。

【依赖PK关联】：和关联关系不同，无须在类NoticeServiceImpl中定义类Notice 和 类BaseDao 类型的属性。

4、关联

关联(Association) : 对象之间一种引用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联又分为一般关联、聚合关联与组合关联。后两种在后面分析。在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。可以是单向和双向。

【箭头指向】：带普通箭头的实线，指向被拥有者。

【关联关系】：是一种拥有的关系，它使一个类知道另一个类的特征和行为，关联分为单项关联和双向关联两种；双向关联可以用俩头带箭头的实现表示，也可以不要箭头。

【3.1】、单向关联：仅能从一个类访问到另一个类（前者的属性中有后者），B类单项关联A类（B中有属性a为类A的对象）；如：学生与课程的单向关联。

【3.2】、双向关联：两个类之间能相互访问（两个类的属性中都有对方），B类关联A类（B中有属性a为类A的对象），A类关联B类（A中有属性bs为Set，Set包含B的对象），A和B是1对n（n>0）的关联；如老师与学生的双向关联。

【3.3】、自身关联：... ...

【代码体现】：成员变量

5、聚合

聚合(Aggregation) : 表示has-a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系，公司包含员工，但如果公司倒闭，员工依然可以换公司。在类图使用空心的菱形表示，菱形从局部指向整体。

【箭头方向】：带空心菱形的实线，菱形指向整体；Employee类  聚合 到 Company 对象里面去。

【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如Company 和Employee是整体与部分的关系，Employee离开Company 仍然可以存在，并不随Company 的创建而创建，销毁而销毁。

【代码体现】：成员变量

【聚合PK关联】：聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

6、组合

组合(Composition) : 表示contains-a的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。

【箭头方向】：带实心菱形的实线，菱形指向整体；Company对象完全由Department对象组成。

【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如Company和Department是整体与部分的关系，没有Company就没有Department，Department随Company的创建而创建，销毁而销毁。

【代码体现】：成员变量

【组合PK关联】：组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

7、多重性(Multiplicity)

通常在关联、聚合、组合中使用。就是代表有多少个关联对象存在。使用数字..星号（数字）表示。如下图，一个割接通知可以关联0个到N个故障单。

重数性关联: 重数性关联关系又称为多重性关联关系(Multiplicity)，表示一个类的对象与另一个类的对象连接的个数。在UML中多重性关系可以直接在关联直线上增加一个数字表示与之对应的另一个类的对象的个数。

表示方式	多重性说明
1..1	表示另一个类的一个对象只与一个该类对象有关系
0..*	表示另一个类的一个对象与零个或多个该类对象有关系
1..*	表示另一个类的一个对象与一个或多个该类对象有关系
0..1	表示另一个类的一个对象没有或只与一个该类对象有关系
m..n	表示另一个类的一个对象与最少m、最多n个该类对象有关系 (m<=n)

聚合和组合的区别

这两个比较难理解，重点说一下。聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。

实例分析

联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。

大家可以参照着类图，好好理解。

1． 通知分为一般通知、割接通知、重保通知。这个是继承关系。

2． NoticeService和实现类NoticeServiceImpl是实现关系。

3． NoticeServiceImpl通过save方法的参数引用Notice,是依赖关系。同时调用了BaseDao完成功能，也是依赖关系。

4． 割接通知和故障单之间通过中间类(通知电路)关联，是一般关联。

5． 重保通知和预案库间是聚合关系。因为预案库可以事先录入，和重保通知没有必然联系，可以独立存在。在系统中是手工从列表中选择。删除重保通知，不影响预案。

6． 割接通知和需求单之间是聚合关系。同理，需求单可以独立于割接通知存在。也就是说删除割接通知，不影响需求单。

7． 通知和回复是组合关系。因为回复不能独立于通知存在。也就是说删除通知，该条通知对应的回复也要级联删除。

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

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

各种关系的强弱顺序

泛化 == 实现 > 组合 > 聚合 > 关联 > 依赖

下面这张UML图，比较形象地展示了各种类图关系 ：