umlの类图

版权声明：本文为博主原创文章，若要转载请注明出处！^_^ https://blog.csdn.net/u010892841/article/details/24844825

类图class diagram用来表述系统内部的静态结构。详细来说，开发者能够通过类图的设计，把代码分类构成系统内部的静态结构。

    曾经，程序猿在开发过程中，须要分模块、定功能、定义变量。这些过程在面向对象的技术中也会得以体现。以下是一个表格用来区分一般面向过程的方法和面向对象方法。 

面向过程	面向对象
模块	类
功能	操作
变量	属性
自上而下	自下而上

当中须要说明的是表格中的最后一行，也就是两者划分方法的不同例如以下图：

     在设计类图的时候应该注意的几点例如以下：

         通过找名词能够找到类。进一步的是确定属性和操作。

在这个过程中要注意状态信息、动作行为操作集合动态信息，行为属于行为的实施者。

另外须要注意的是，类图不是一蹴而就的。在类的抽象的过程中能够抽象出一些新的类。同一时候也要注意建立关系的时候尽量用最准确的关系建模，而且注意对关系进行修饰包含名称、角色名、多重性的修饰。

类图的分类例如以下

边界类〈Boundary Classes〉：

l  可用来塑造操作者与系统之间的交互。

l  可用来理清用户在系统边界上的需求；

l  可设计抽象的用户界面对象。

控制类〈Control Classes〉：

l  可协调对象之间的交易；

l  可将使用案例的细节部分封装起来；

l  可将复杂的计算或商务逻辑封装起来。

实体类〈Entity Classes〉：

l  代表永久保存的信息；

l  代表E-R模型之中人、事、时、地、物或概念的信息及行为。

接下来就是实战阶段了。在浏览别人的博客时发现一个特点。非常多人都忽视了类图一个重要的特性：类图是从不同的角度进行系统静态结构进行描写叙述的。而且在每一次描写叙述的过程中，必须依据不同的角度有不同的側重点。不能要求一幅图做到面面俱到，那样的类图会没有重点，表达也不会非常清晰。以下是我在吸取这个经验之后改进的用例图，有哪里能够改进的地方，欢迎大家指出，共同交流。

在画类图的时候比較纠结的一点是，看到非常多童鞋都是直接画的三个角色之间的继承关系。

思考了一下。发现仅仅有三者之间的操作能够有继承关系。可是三者的属性关系并没有相似的关系。

经过多方面的考虑就画了一张这种类图。可是我知道自己的图也不完好，由于学长说类的操作必须是最简化的操作，也就是直接输入參数就能够完毕动作的操作。我写的那些都不能算是真正的操作。可是由于水平有限仅仅能盲人摸象。画出自己眼下阶段理解的层次，待以后随着学习的加深再一步步的不断完好吧。

     最后的改进。敬请參看uml图验收问题集锦。