在计算复杂的数学题时，我们必然会打草稿计算
在绘画课中，我们可以素描出来看到的事物
那么在程序设计中呢？
如何描绘传达你脑海中的关于这个程序 ，设计的蓝图草稿？
OOP的程序设计中，最多的自然是类、接口层次接口的设计
简单的设计，可能在脑海中想象下就过了，比如A继承B
但是复杂的呢？
对于OOP程序设计中，类的层次、关系设计如何描绘？
用文字么? A继承B A实现C，A中有一个D的引用
显然，图形化的方式更加直观，简洁
那么到底如何表示OOP中的事物与关系？每个人有每个人的书写方式，如何进行交流？
你画了一个三角形说这是一个接口，我花了一个圆形，跟你讲这个是接口？这其中的问题不言而喻。
原文地址:
而我们看到的UML图也就是如同一整块已经搭建好的积木
当然
UML肯定不会向积木那样简单，所以自然还会有很多的规则、限制、要求，这些一起构成了完整的UML
但是根本是事物和关系，这两者是UML的主体
事物就是面向对象程序设计中的元素
关系则是他们的相互联系形式
图则是按照不同事物的组织形式进而产生的分类
