【UML】例析UML类图的几种关系

    最近在学习UML，别的先不提，英文单词到是学会了不少。。既然Rational Rose就是英文版的，索性我就所有东西都按照英文意思来理解，慢慢来，当初学VB的时候我也不是一下子就能记住Label的。。

  来说主题，UML系列第一篇我就要说说这个让我头大的几种关系，真的是剪不断理还乱啊。后来在网上搜了很多的例子来看，帮助我理解这几种关系。下面我就来用生活中的事物给大家讲解一下这几种类图关系，然后再对Ta们进行一下对比。

    

    先来看一下整个类图关系的分类，如上图，类图关系分为关联、泛化、依赖、实现四大重要的关系。关联中有两种特殊的关联，就是聚合和组合。

一、各种关系的基本概念

    （一）关联关系 Association

     关联关系表示一个类“知道”另一个类的属性和方法。关联关系形容的是一种静态关系，与运行时的状态没有关系，而是由规则，常识来定义的，因此说，关联关系是一种“强关联”。

    如图是一个关联关系，公司和员工之间的关系。

    如图是乘客和车票之间的关系。乘客和车票之间的一对一关系是符合“规则”的关系。

    就像这两个例子一样，关联关系是定义了两个对象之间的天然的、静态的关系。

    （二）泛化关系 Generalization

     泛化关系就是我们在面向对象中学到的继承，“is a kind of”关系。继承意味着对于父类的定义，对子类也是有效的。泛化关系由小辈儿类到其长辈儿类的关系。如下两个例子。

    老虎和小猫都是动物的一种（is a kind of），他两个都拥有动物的属性和方法，并且可以根据父类（animal）new出新的子类（tigger & cat）。

    （三）依赖关系 Dependency

    依赖我们可以称其为“Use”的关系，表示一个类对另一个类的属性或者方法的使用关系。依赖关系是一种临时性的关系，这种关系是具有生命周期的。随着软件运行状况的改变，可能这种关系就不存在了。例如：在C++中是一种局部变量或者是函数的调用，比如说A依赖于B，如果B发生了变化，那么A也就跟着变化。

    如下面的例子，人使用车，一个或者多个学生使用一个教室。

         

    因为人只有在开车的时候是依赖于车子的，学生只有在上课的时候是依赖于教室的，所以这种随着时间会改变的关系，就认为它是很“弱”的一种关系。

    （四）实现关系 Realization

    实现关系描述的是一个类元的实现是另一个类元实现的“保证契约”。一般会用来表示接口和类之间的关系，一个接口的实现，要先实现对应的类。

    如图，如果我想实现营业厅缴费的这个接口，我必须先保证我有交话费（类）这个动作才行。一个类可以实现多个接口，我交话费这个动作可以有多个实现的方法。

    （五）聚合关系 Aggregation

     聚合是一种“has a”的关系，是用来表示实体对象之间的整体和部分的关系。 整体和部分可以相互的独立存在。例如：书架子上边有0个或者多个书。

   

    （六）组合关系 Composition

    组合是一种强的依赖关系，它表示“contains a” 的关系。如果整体没有了，部分也不能存在。例如：如果书没了，每一页书也没有存在的意义了。

二、比较几种关系

    （一）聚合VS组合

    二者都是在说整体和部分的关系。最大的区别在于聚合中的整体与部分可以单独存在，他们的生命周期是分别计算的。组合中的整体与部分具有相同的生命周期，是不可分割的。例如雁群和大雁是聚合关系，大雁和大雁的翅膀是组合关系。

   （二）关联VS聚合

    表现在代码层面，二者关系一致的。从语义级别上区别关联的双方一般是平等的，例如你是我的朋友。而聚合关系的两个实例对象不是一个级别的，例如车轮和汽车的关系。

    （三）关联VS依赖

    关联关系是一种强依赖关系，不存在依赖关系的偶然性，关系也不是临时的，一般是长期性的。而依赖关系不仅仅是知道它所要依赖的类，而且还要进一步的使用它。

三、综合分析

    综合分析这几种关系，都是语义级别的不同。他们所表现的强弱程度依次为：

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

    能用继承来描述的关系就使用泛化关系，当描述接口和类的实现时一定用实现来描述，两个类之间如果有结构关系的时候一定用关联来描述。除此之外用依赖来描述。

四、小结

    通过对UML类关系的学习，我更是体会到了对比学习的重要性。越是相近的东西就要对比，不要怕分不清楚，要找到共同点，着重记Ta们不一样的地方，这样才有所收获。