UML 还有用吗？ 第1页

UML是给一些没什么特别需求的项目的架构师用的。。。

非常专业的项目，有时候会自创一些元语言符号进行精确的系统描述。UML亏就亏在U这个字上。

另外UML其实一点都不U，因为只能描述OO

比如我用OCaml写的东西就没法用UML来描述。。（一般直接给mli就完事了，人家也是ML嘛。。）

也有用，也没用。

UML是各种类型图的结合体，UML的支持者（以及商业机构）宣称UML有很多能力。

比如UML图直接生成代码。这种时候，这种UML模型设计自己本身也可以看作是某种“编程语言“了。在某些特定领域，这种模型设计自动产生代码其实经常见到的。比如Visual Studio的表单设计器就可以大致被理解为一种“模型设计”，随着拖拽，相应的代码被产生出来。

但是，UML到底能不能等价于“编程语言“？他的表达能力能不能足够胜任编程工作？现实的情况是几乎不可能。UML只能粗略描述类关系、时序图、流程等。而复杂的逻辑即便写出来，会比直接写代码还难看。如果是这样，为何不直接写代码呢？如果同时修改代码和UML图，怎么保证二者同步呢？早期Eclipse有专门做UML到代码之间同步的工具，而现在几乎没有人用。此外，有些UML的图是专门给人看的，比如“用例图”。这些图和生成代码没任何关系。

但是反过来，写了一些代码，然后直接看代码本身很难搞清楚关系，自动产生个类图看看是否可以呢？这个现实一些。目前各种IDE也会多少提供一下这个功能。但是需要强调的是，设计的思路本身并不一定能被类图等这样可以自动生成的东西展现出来。所以用来看个大概还行，但如果真想要让业务代码和本身的设计逻辑对照起来，还是要找到原始的，给人看的设计文档。

再比如表现高层的设计意图。这点没有问题。即便不用UML，也会用其他某种形式的图。UML之所以“Unified”，是希望能统一一套符号（比如表示继承的箭头，表示1对多关系的关联等）。不同的人给出的设计可以相互理解。但是，这就涉及到行业本身对图标准性的要求。写代码有编译器可以帮你检查错误，写错了就不过。但是图形本身并没有什么硬性的东西卡你。只有这个组织/行业的规定能够强制，比如画错了就降级降薪甚至开除。因此，如果一个行业并不对此有过多要求（比如互联网），你就不要指望大家能画出多标准的图。此时，你会发现大部分情况下画出来的都是方块，箭头之类的随心所欲的符号，再配合一些简单的文字解释。

但一般这种随便画画的图基本上并不会影响理解，反而可能更高效。在一个互相熟悉的团队，做着比较熟悉的事情，随便在白板或者纸上画画就完全能够表达设计意图。并且这还避免了因为画图工具带来的思维上的干扰。讨论后落纸面时，因为代码总是能反生成图的，所以不会把UML模型设计画得很细，而是把当时设计思路写得比较多显得更加有用。

像跨团队，跨公司分享设计的情况现在我很少见到。不都做接口吗，不都隐藏了吗，看接口文档啊。到了开源界，都是share代码，没人会画图的……

最后，UML宣称能够从模型上能提前验证系统是正确的。像医学、航天等出了篓子就是大事这种领域，提前验证正确性是非常必要的。早年像CSP理论、 演算等也希望能提供一套形式化的方式来验证比如“有没有死锁“等。但UML并非是形式化语言，它能做的也只是为人工的分析提供依据，nothing more。因此它的验证能力比较粗。实际上我们天天用流程图、状态机之类的东西和PM交流，说明产品设计中可能的漏洞和矛盾。只不过没有宣称这就是UML，也没有画的很标准而已，反正都能看懂。

基于上述讨论，我对UML的各项能力打个分，分值0～5（完全基于我熟悉的领域，其他领域也许会不同，欢迎分享那个领域的UML应用情况）。

• 代码自动生成：0（几乎没用，要有代码时我就写代码）
• 代码高层设计和交流： 4 （我们的确会用类图、时序图等来交流设计思想，怼PM的“人类思路”）
• 验证正确性：2 （基本上就是粗略的讨论能不能说得通，但要做精确的验证，必须用专门的工具）
• 统一大家对设计的交流方式：2 （我身边大多数人能看懂UML，但是不喜欢画标准的UML，有点类似于繁体字的感觉；沟通时以把一件事说明白为最根本目标，形式上的“统一”往往造成不够贴切灵活，反而让沟通更困难。）

因此，我建议题主可以看看UML，了解一下，但不用花过多时间，也不用把精力放在“把UML用到极致“这种事上，除非你所在的行业/公司真的有很严格的要求，有非标准UML不可的环境。

如果题主有空的话，可以把更多的精力放在比如“怎么样OOP才是合理的“，”如何设计好的接口“之类的设计思想上，或者是业务领域知识上。即便用了UML，也不能把渣设计变成好设计。工具，能用就可以啦。不要舍本求末。

P.S. 除去技术交流，UML在甲方乙方之间扯皮甩锅时特别有用。这也许是UML创建者没有预料到的吧……

UML本质上也是一种语言……就算画成图也是……

UML的问题在于，作为图型这货太复杂，作为语言这货没卵用，没有编译器和IDE支持或者说相较于程序设计语言支持就是个渣渣……

其实是一个很奇怪的东西，这货对于程序员来说，程序员会觉得画这玩意儿还不如写代码来生成这玩意儿。

对于非程序员的领域建模人员来说，这货的各种符号和箭头过于专业，很多东西与程序实现强相关与领域关系不大。在不同的领域所需要的东西又没有标准化……

就是个上不上下不下的东西……

你非说没用可能过于绝对，但就是个聊胜于无的东西，而且画图这玩意儿最看肚子里有没有货，把符号用的天花乱坠是没有用的……

====================================================

补充几点评论中讨论的：

我认为UML是不符合程序员思维的。

程序员的任务是用最简单最方便的方式把让计算机理解自己的意图。所以说，为什么高级前端开发人员很少用设计器？不是因为设计器不直观，而是因为写代码更快。如果你要直观的看到效果，打开浏览器就可以了……

这就是程序员的思维。

所以，我为什么要画图？画图不是最快表达我的想法的方式，写代码才是。代码和图是等价的，UML图形完全可以用一种类SGML语言或是JSON或者YAML语言来描述，而且写这种东西比拖拽UML图形更快。为什么没有出现这种东西？恰恰说明UML没用。

因为，有一种东西比UML表现能力更强，更通用，那就是代码。

大多数人印象中的代码可能是这样的：

但是代码当然也可以是这样的：

也可以长这样：

在程序员思维里面，这个图怎么显示好看，那是一个presentation的问题。这个图的部件怎么来的才是我架构设计的问题。

让图好看，完全可以写个Viewer来实现，所以我为什么要去纠结符号箭头以及摆放的问题呢？

对于程序员来说，UML类图本质上就是这么个玩意儿：

       <class name="XXX">   <inherit class="YYY" />   <properties>     <property name="ABC" type="MyType" />   </properties> </class>     

回头一看，特么写这么蛋疼的东西为啥不直接写伪代码：

       class XXX : YYY {   ABC : MyType }     

你说UML可以描述关联关系？喵喵喵？

       class XXX : YYY {   #rel-type: ZZZ    ABC : MyType }     

我为什么不画图？我写这么个东西给计算机去画图快多了啊……

「画图有用」不等于「UML 有用」。

也不要用反对二分法来抹稀泥。UML 本来就是一个边界明确的学究式标准化。对于这种打着实用性幌子，搞形式化 shit work 的行为，不用二分法一棍子打死绝不罢休。

这是 Uber 的架构师对 UML 以及其它「标准化」架构方法的评价

Let me start with a few things that might sound surprising.First, none of these designs used any of the standard software architecture planning tools.We did not useUML, nor the4+1 model, norADR, norC4, nordependency diagrams. We created plenty of diagrams, but none of them followed any strict rules. Just plain old boxes and arrows, similarthis one describing information floworthis one outlining class structure and relationships between components. Two diagrams within the same design document often had a different layout and were often added and modified by different engineers.
…… 不用任何标准化的软件架构工具。不用 UML …… 我们画了许多图，但是没有一个按照严格的标准绘制。只用最朴素的框图和箭头。……

我自己就是学术界的，也教过UML，也看过一些标准文档。

我的建议是不要学的太细。当然，估计也不太可能学的太细。UML2.5的标准化文档有差不多800页，跟Java的标准文档基本上差不多。完整可生成代码的UML，要比同样情况下的Java程序还要难编写的多，工作量大得多，在大多数情况下是完全没有必要的。

但是UML不同图里隐含着对建模的一种视角上的思考，值得学习一下。我觉得对提升工程能力是很有好处的，可以更加从不同角度去理解软件系统。

学习UML的重点不要放在词法语法上，这些能大概使用就行了。重点去理解UML如何体现需求，总体设计，业务逻辑设计，验证和测试，具体实现等等不同角度的异同，协调和平衡软件系统里不同的考虑。