详解UML图之类图

产品经理的必备技能之一是画UML图，本文就告诉你怎么画标准的类图吧。本文结合网络资料和我的心得所成，不当之处，请多指教。

一、为何须要类图？类图的做用

咱们作项目的需求分析，最开始每每获得的是一堆文字，请看下面这堆文字：

本项目是在一期的基础上增长对电缆、通信工程的管理和施工详细数据的记录和统计，使整个系统更好的管理各工程项目从中标开始到竣工验收的所有过程和资料和分析施工过程的数据。 本系统将一条或一个标段的架空电力线路工程定为一个单位工程，即系统中的一个工程项目；每一个单位工程分为若干个分部工程；每一个分部工程分为若干个分项工程；每一个分项工程中又分为若干相同单元工程。

这是关于系统状况的一段概述，里面充斥了大量的术语、概念，若是你不是专业人士，恐怕难以读懂上述文字。

项目初期，咱们每每对业务一无所知，咱们最急迫须要解决的问题就是理清楚这些业务概念以及它们的关系，若是能用好类图，你将能深刻地剖析系统业务。

用下面这个UML图来描述是否清晰了许多呢？

在上图中，各个类之间是关联关系，也就是拥有的关系。

类图(Class diagram)主要用于描述系统的结构化设计。类图也是最经常使用的UML图，用类图能够显示出类、接口以及它们之间的静态结构和关系。

二、怎么画类图？用什么工具？

使用工具：Visio或者processon在线做图  在类图中一共包含了如下几种模型元素，分别是：类（Class）、接口（Interface）以及类之间的关系。 2.1 类（Class)   在面向对象（OO) 编程中，类是对现实世界中一组具备相同特征的物体的抽象。

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

2.三、类图中关系（relation） 在UML类图中，常见的有如下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency) 1. 泛化（Generalization） 【泛化关系】：是一种继承关系，表示通常与特殊的关系，它指定了子类如何特化父类的全部特征和行为。 例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头指向】：带三角箭头的实线，箭头指向父类

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

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

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

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

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

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

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

类图绘制的要点

1类的操做是针对类自身的操做，而不是它去操做人家。好比书这个类有上架下架的操做，是书本身被上架下架，不能由于上架下架是管理员的动做而把它放在管理员的操做里。

2两个相关联的类，须要在关联的类中加上被关联类的ID，而且箭头指向被关联类。能够理解为数据表中的外键。好比借书和书，借书须要用到书的信息，所以借书类需包含书的ID，箭头指向书。

3因为业务复杂性，一个显示中的实体可能会被分为多个类，这是很正常的，类不是越少越好。类的设计取决于怎样让后台程序的操做更加简单。好比单看逻辑，借书类能够不存在，它的信息能够放在书这个类里。然而借还书和书的上架下架彻底不是一回事，借书类对借书的操做更加方便，不须要去重复改动书这个类中的内容。此外，若是书和借书是1对多的关系，那就必须分为两个类。 4类图中的规范问题，好比不一样关系须要不一样的箭头，可见性符号等。

三、类图的分类

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

领域UML类图vs实现UML类图

上文提到，在软件分析与设计过程当中，会由两种角色产生两套UML类图。通常状况下，分析师绘制的UML类图叫作“领域UML类图”，而设计师绘制的UML类图叫作“实现UML类图”。这里要声明，这两个名词是个人习惯性叫法，并非你们都认同的通用叫法。下面，我对这两种UML类图给出个人定义：
领域UML类图：产生于分析阶段，由系统分析师绘制，主要做用是描述业务实体的静态结构，包括业务实体、各个业务实体所具备的业务属性及业务操做、业务实体之间具备的关系。

虽然这个UML类图也叫“UML类图”，可是说实话，它和编程中的“类”实在是没啥关系，由于最后的系统中可能根本没有类和它们对应，并且不少最后系统中的类如控制类和界面类这套UML类图中也没有。也就是说这套图和具体技术无关，也不是画给程序员看的，它只是表达业务领域中的一个静态结构。下面给个例子：

这是一个选课系统的简单领域分析UML类图。能够看到，主要实体有教师、学生、课程和开课安排。每一个实体标注了其在业务上具备的属性和方法。并且图中还标明了实体间的关系。

可是，最终系统中可能没有一个学生类和其对应。由于最终系统中有哪些类、各个类有什么属性、方法依赖于所选择的平台和架构。例如，若是使用了Struts2，则会存在不少Action类，而使用了ASP.NETMVC，则会有不少Controller类等，因此，领域UML类图只于业务有关，和具体实现及编码等计算机技术无关。

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

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

总结

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