产品经理的必备技能之一是绘制UML图。 在这篇文章中，我来教你如何画标准的类图。 本文是结合网络资料和个人心得撰写的，有不妥当之处，请多多关照。

1、为什么需要类图？ 类图的作用我们正在做项目的需求分析。 首先往往会得到很多文字。 请看下面的文字。

本项目在一期基础上增加电缆、通信工程管理和施工详细数据的记录和统计，更好地管理各工程项目从中标到竣工验收的全过程和资料，分析施工过程的数据。 本系统将一个或一个基准段架空电力线工程作为一个单位工程，即系统中的一个工程项目； 各单位工程分为几个分部工程每个分部工程分为几个分项工程； 每个分项工程又分为几个相同的单元项目。

这是系统情况的概要，充斥着大量的术语、概念，如果不是专家，可能很难阅读上述文字。

在项目初期，我们经常对业务一无所知。 我们最迫切需要解决的问题是分清这些业务概念和它们之间的关系。 搞好类图，可以深入分析系统业务。

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

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

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

2、怎么画类图？ 你用什么工具？ http://www.Sina.com/:在visio或processon的在线绘图中，类图包含类(Class )、接口)和类之间的关系等模型元素。 类2.1 ) Class )在面向对象(OO )编程中，类抽象出现实世界中一组具有相同特征的物体。

2.2接口(接口)接口是一个特殊类，有类结构但不能实例化，只能实现(继承)。 在UML中，接口用命名的小圆表示。

2.3、类图中的关系(relation ) UML类图中，常见的有以下关系：泛化(Generalization )、实现关系(Realization )、关联(Association )、 )的依存(Dependency )1.泛化(Generalization )【泛化关系】:表示一般和特殊关系，是指定子类如何专用于父类所有特征和行为的继承关系。 例如，老虎是动物的一种，既有老虎的特性，也有动物的共性。 【箭头指向】:带三角箭头的实线，箭头指向父类

2 .实现(Realization )【实现关系】:一种接口关系，表示类是接口的所有特征和行为的实现。 【箭头指向】:带三角箭头的虚线，箭头指向界面

3 .关联(关联)【关联关系】:使一个类知道另一个类的属性和方法的拥有关系； 例如，老师和学生、丈夫和妻子的关联可以是双向的，也可以是单向的。 双向关联可以有两个箭头，也可以有一个箭头用于单向关联。 【代码表示】:成员变量【箭头与指向】:在普通箭头实线、指向被业主的上图中，师生是双向关联的，老师可能有多名学生，学生也可能有多名老师。 但是，学生和某门课的关系是单方面的关系，一个学生可能上多门课。 课程是抽象的，他没有学生。 下图是自己的关联。

4 .聚合(聚合)【聚合关系】:整体与部分的关系，部分可以独立于整体存在。 只要车和轮胎是整体和部分的关系，轮胎即使离开车也可以存在。 聚合关系是一种关联关系，是强关联关系； 关联和聚合在语法上分不开，必须考察具体的逻辑关系。 【代码表示】:成员变量【箭头和指向】:带中空菱形的实线，菱形指整体

5 .组合【组合关系】:整体与部分的关系，但部分不能脱离整体而单独存在。 如果公司和部门是整体和部分的关系，那么没有公司就没有部门。 组合关系是一种关联关系，强于聚合关系，通常的聚合关系要求代表整体的对象负责代表部分的对象的生命周期。 【代码表示】:成员变量【箭头和指向】:带实心菱形的实线，菱形指整体复制代码

6 .依赖关系(依赖关系) :一个类的实现需要另一个类的合作，因此尽量避免使用双向的相互依赖。 【代码表示】:局部变量、方法参数或对静态方法的调用【箭头和指向】:带箭头的虚线，指复制给用户的代码

各种关系的强弱顺序：泛化=组合聚合关联的实现依赖于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.NETMVC，则会有很多Controller类等，所以，领域UML类图只于业务有关，和具体实现及编码等计算机技术无关。

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

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

总结

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

转载于:https://juejin.im/post/5a5b246b6fb9a01cbd588f43