本文主要是介绍umlの类图，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
类图class diagram用来表述系统内部的静态结构。具体来说，开发人员可以通过类图的设计，把代码分类构成系统内部的静态结构。
以前，程序员在开发过程中，需要分模块、定功能、定义变量，这些过程在面向对象的技术中也会得以体现。下面是一个表格用来区分一般面向过程的方法和面向对象方法。
| 面向过程 | 面向对象 |
| 模块 | 类 |
| 功能 | 操作 |
| 变量 | 属性 |
| 自上而下 | 自下而上 |
在设计类图的时候应该注意的几点如下：
通过找名词可以找到类，进一步的是确定属性和操作。在这个过程中要注意状态信息、动作行为操作集合动态信息，行为属于行为的实施者。另外需要注意的是，类图不是一蹴而就的，在类的抽象的过程中可以抽象出一些新的类。同时也要注意建立关系的时候尽量用最准确的关系建模，并且注意对关系进行修饰包括名称、角色名、多重性的修饰。类图的分类如下
边界类〈Boundary Classes〉：
l 可用来塑造操作者与系统之间的交互；
l 可用来理清用户在系统边界上的需求；
l 可设计抽象的用户界面对象。
控制类〈Control Classes〉：
l 可协调对象之间的交易；
l 可将使用案例的细节部分封装起来；
l 可将复杂的计算或商务逻辑封装起来。
实体类〈Entity Classes〉：
l 代表永久保存的信息；
l 代表E-R模型之中人、事、时、地、物或概念的信息及行为。
接下来就是实战阶段了。在浏览别人的博客时发现一个特点，很多人都忽视了类图一个重要的特性：类图是从不同的角度进行系统静态结构进行描述的。并且在每一次描述的过程中，必须根据不同的角度有不同的侧重点。不能要求一幅图做到面面俱到，那样的类图会没有重点，表达也不会很清晰。下面是我在吸取这个经验之后改进的用例图，有哪里可以改进的地方，欢迎大家指出，共同交流。
在画类图的时候比较纠结的一点是，看到很多童鞋都是直接画的三个角色之间的继承关系。思考了一下，发现只有三者之间的操作可以有继承关系，但是三者的属性关系并没有类似的关系。经过多方面的考虑就画了一张这样的类图。但是我知道自己的图也不完善，因为学长说类的操作必须是最简化的操作，也就是直接输入参数就可以完成动作的操作。我写的那些都不能算是真正的操作。但是因为水平有限只能盲人摸象，画出自己目前阶段理解的层次，待以后随着学习的加深再一步步的不断完善吧。
最后的改进，敬请参看uml图验收问题集锦。
这篇关于umlの类图的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
