详解UML图之类图 （转）

原址：

https://www.jianshu.com/p/4cd95d4ddb59

2.  怎么画类图？用什么工具？

使用工具：Visio或者processon在线作图
　在类图中一共包含了以下几种模型元素，分别是：类（Class）、接口（Interface）以及类之间的关系。

2.1 类（Class)
　　在面向对象（OO) 编程中，类是对现实世界中一组具有相同特征的物体的抽象。

2.2 接口（Interface）
　　接口是一种特殊的类，具有类的结构但不可被实例化，只可以被实现（继承）。在UML中，接口使用一个带有名称的小圆圈来进行表示。

2.3、类图中关系（relation）
在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

1. 泛化（Generalization）
【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
【箭头指向】：带三角箭头的实线，箭头指向父类

泛化

2. 实现（Realization）
【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.
【箭头指向】：带三角箭头的虚线，箭头指向接口

实现

3. 关联（Association)
【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，
丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者

关联

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。
但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。

自身关联

4. 聚合（Aggregation）
【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体

聚合

5. 组合(Composition) 【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。 如公司和部门是整体和部分的关系，没有公司就不存在部门。 组合关系是关联关系的一种，是比聚合关系还要强的关系， 它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。 【代码体现】：成员变量 【箭头及指向】：带实心菱形的实线，菱形指向整体

作者：南宫七洛
链接：https://www.jianshu.com/p/4cd95d4ddb59
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

5. 组合(Composition) 【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。 如公司和部门是整体和部分的关系，没有公司就不存在部门。 组合关系是关联关系的一种，是比聚合关系还要强的关系， 它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。 【代码体现】：成员变量 【箭头及指向】：带实心菱形的实线，菱形指向整体

作者：南宫七洛
链接：https://www.jianshu.com/p/4cd95d4ddb59
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

5. 组合(Composition) 【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。 如公司和部门是整体和部分的关系，没有公司就不存在部门。

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

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

组合

6. 依赖(Dependency)
    【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，
      所以要尽量不使用双向的互相依赖.
    【代码表现】：局部变量、方法的参数或者对静态方法的调用
    【箭头及指向】：带箭头的虚线，指向被使用者

依赖

各种关系的强弱顺序：
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
下面这张UML图，比较形象地展示了各种类图关系：

类图绘制的要点
1.   类的操作是针对类自身的操作，而不是它去操作人家。比如书这个类有上架下架的操作，是书自己被上架下架，不能因为上架下架是管理员的动作而把它放在管理员的操作里。

2.  两个相关联的类，需要在关联的类中加上被关联类的ID，并且箭头指向被关联类。可以理解为数据表中的外键。比如借书和书，借书需要用到书的信息，因此借书类需包含书的ID，箭头指向书。

3.  由于业务复杂性，一个显示中的实体可能会被分为多个类，这是很正常的，类不是越少越好。类的设计取决于怎样让后台程序的操作更加简单。比如单看逻辑，借书类可以不存在，它的信息可以放在书这个类里。然而借还书和书的上架下架完全不是一回事，借书类对借书的操作更加方便，不需要去重复改动书这个类中的内容。此外，如果书和借书是1对多的关系，那就必须分为两个类。

4.  类图中的规范问题，比如不同关系需要不同的箭头，可见性符号等。

 

 

 

 

 

3、类图的分类

软件在分析与设计两个阶段各自会绘制一套UML类图，而且是由分析师和设计师两个不同的角色绘制的。那么这两套UML类图有什么异同呢？下面将解释这个问题。

领域UML类图vs实现UML类图
上文提到，在软件分析与设计过程中，会由两种角色产生两套UML类图。一般情况下，分析师绘制的UML类图叫做“领域UML类图”，而设计师绘制的UML类图叫做“实现UML类图”。这里要声明，这两个名词是我的习惯性叫法，并不是大家都认同的通用叫法。

下面，我对这两种UML类图给出我的定义：
领域UML类图：产生于分析阶段，由系统分析师绘制，主要作用是描述业务实体的静态结构，包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。
虽然这个UML类图也叫“UML类图”，但是说实话，它和编程中的“类”实在是没啥关系，因为最后的系统中可能根本没有类和它们对应，而且很多最后系统中的类如  控制类  和  界面类  这套UML类图中也没有。也就是说这套图和具体技术无关，也不是画给程序员看的，它只是表达业务领域中的一个静态结构。下面给个例子：

 

 

这是一个选课系统的简单领域分析UML类图。可以看到，主要实体有教师、学生、课程和开课安排。每个实体标注了其在业务上具有的属性和方法。而且图中还标明了实体间的关系。
但是，最终系统中可能没有一个学生类和其对应。           因为最终系统中有哪些类、各个类有什么属性、方法依赖于所选择的平台和架构。

例如，如果使用了Struts2，则会存在很多Action类，而使用了ASP.NET / MVC，则会有很多Controller类等，所以，领域UML类图只于业务有关，和具体实现及编码等计算机技术无关。

 

 

 

 

实现UML类图：
实现UML类图：产生于设计阶段，由系统设计师绘制，其作用是描述系统的架构结构、指导程序员编码。它包括系统中所有有必要指明的实体类、控制类、界面类及与具体平台有关的所有技术性信息。

就像上面的领域UML类图，如果你把它交给程序员编码，我想程序员会疯掉，因为它没有提供任何编码的依据。假如我们使用的是.NET平台分层架构，并使用ASP.NET   /  MVC，则设计师应该在实现UML类图中绘制出所有的实体类、数据访问类、业务逻辑类和界面类，    界面类又分为视图类、控制器类等等，还要表示出IoC和Aop等信息，并明确指出各个类的属性、方法，不能有遗漏，因为最终程序员实现程序的依据就是实现UML类图。

 

总结
最后，我们总结一下要点：
1.软件分析与设计是编码前的两个阶段，其中分析仅与业务有关，而与技术无关。设计以分析为基础，主要与具体技术有关。
2.分析阶段由分析师绘制领域UML类图，设计阶段由设计师绘制实现UML类图。
3.领域UML类图表示系统的静态领域结构，其中的类不与最终程序中的类对应；设计UML类图表示系统的技术架构，是程序员的编码依据，其中的类与系统中的类对应。
4.领域UML类图中类的属性与操作仅关注与业务相关的部分，实现UML类图中的属性与操作要包括最终需要实现的全部方法与操作。