2015年快来了,你还在使用十几年前发明的uml来OOAD建模么?

[sanguorewrite]

那么,你落后了.

UML已经诞生有十几年历史了。但是从现在的种种迹象看，UML非但没有流行起来，反而有渐渐从开发领域隐退的迹象。



在过去的几年，主要的出版商（Wrox、Manning、Orielly、Apress等） 几乎没有再出版什么关于UML的专著，而国内也只看到一本UML大象书。出版界似乎对UML失去了兴趣。UML图在一些技术书籍中仍然存在，但通常只是作为类结构的辅助说明，占有的比例非常之小。在各种技术博客、论坛、用户组，也鲜见有人讨论UML。如果要说明某些技术概念，我发现绝大多数人宁愿直接给出代码。



主流的开发工具在过去几年有很多进步，但是在历次改进中，没有哪一个工具把“更好的支持UML”作为主要卖点。以UML为主导的开发方式似乎从未在实际开发中实现过。如果问哪些技术手段有助于开发更好的软件？回答大概不外乎：测试驱动、持续集成、迭代、Scrum Master、重构，诸如此类。没有人提起UML。



从我过去参与过的项目和从别的项目看到的情况看，使用了UML的结果无一例外：只要开始编码，所有UML图都被扔到一边，再也无人去维护它。

而且我发现一个很有意思的现象是；如果我把UML图拿出来给相关人员看，不论对方是技术人员还是非技术人员，基本上都是一脸茫然，说不出什么意见；反之。如果我拿出的是一份说明文档或者实际的代码，那么对方通常都能很快提出自己的一些想法。 结论：把UML作为交流手段似乎是行不通的。



那么，UML究竟存在什么问题？在项目开发中使用UML究竟有多大的帮助？UML还有再度流行的机会吗？

你的意见呢？

　然而无论直观感觉，还是多年的研究结果都表明：在企图精确描述软件世界时，模型并不比编程语言更优越——即，在深入到一定细节后，表达等量的内容，模型和编程语言同样复杂（如果前者不是更复杂的话）。
　　
　　所以以模型替代编程语言的所有努力看上去是注定会失败的。UML是所有这些徒劳无功的形象代言人。
　　
　　因此，我想，只有当我们看到那些事无巨细的类图、极端精确的时序图，看到那些双向转换模型的纷繁规则，看到那些神似编程语言的“建模语言”时，我们才可以去嘲笑UML。
　　
　　因为这些多少代表了UML/UP以为自负可以达到，但其实不可能达到的境地。

[showjim]

引用 10 楼 Z65443344 的回复:

[quote=引用 9 楼 sbwwkmyd 的回复:] UML就像XML一样鸡肋，可有可无的东西。

XML确实挺鸡肋的,我自己宁愿使用txt存放启动参数,处理起来还方便些[/quote]因为标准不是为了方便，而是为了通用，如果没有 通用 的需求，就没有标准的必要。

[sanguorewrite]

没错,uml就是一个骗子语言.业务人员不明白,开发人员也需要培训才能明白. 可笑至极. 最可笑的是10年前我还发疯了似的推广uml. 现在想来真是荒唐啊. 来看看linkedin大师们的设计文档把,除了use case有点和ooad,uml有关 , 半点uml图都没有. 这就很能说明问题了. https://issues.apache.org/jira/secure/attachment/12666096/DESIGN-SAMZA-402-0.pdf 望大家相互转告.

[threenewbee]

如同结构化语言出现以后，流程图显得多余，而编程语言抽象能力不足才有了设计模式一样，UML很大程度上是编程语言的可读性太差抑或缺乏有效的重构机制才需要引入的辅助工具。

[於黾]

10年前推广,不代表现在也必须推广,这不是什么可笑的事情 好比10年前推荐大家用日光灯,而不是白炽灯 10年后,已经有了节能灯和LED灯,还推广日光灯干嘛

[以专业开发人员为伍]

新人至少需要有半年时间去认真学习UML，这是有好处的。就好像说中学学地理课、小学学算术课、幼儿园学手工课，以后我们不再学了，有了许多高级的方法进行相关处理，甚至我们人人都有了GPS、科学计算器、保姆，但是基本的概念还是要有。 一帮工程师在一起讨论系统架构，结果这帮人连基本的文档、符号体系都不会写，都胡乱画，这不是可笑和成事不足败事有余的教育造成的吗？所以总之是要找到一种启蒙的知识来建立起统一的符号表达体系的，UML就是一种不错的系统。虽然其80%都是多余的，但是剩下的那10~20%是非常基础和重要的。没有这10%作为基础，进一步深化了的工程课程就无法开展。 有人说整个软件工程课程都是多余的，然后又说紧接着如数家珍般地吐出了4、5个最近20年的软件工程流派名词儿，这其实就是自相矛盾的。忘记了基础而仅仅列举高大上的名词儿，就是成事不足败事有余的。

[sanguorewrite]

照您这么说, 学习使用windows 7还得从dos 1.0 , dos 2.0 dos 3.3 如何使用学起么?

[於黾]

我也觉得基础是基础,工具是工具 虽然工具里体现了一些基础,但是不代表必须掌握某种工具

[software_artisan]

工具就是工具！UML之类的工具可以很好的帮助我们整理思路和尽可能少失真地传递想法，这就是这些工具存在的意义。期望这些工具能够自动生产出代码来，是你想太多了。

[xxoo2007]

UML的最大用处是大家用同一种语言表述思想，这样其他人才不需要先了解你用的语言，再了解你要表达的内容。其他再先进的方式，不通用就没有意义

[moonwrite]

uml只是用来表达的内容的工具。 你首先要有好文章的思路，然后选择用中文，英文，日文来表达

[wanghui0380]

其实不管是UML 还是其他滴也罢。最终是个交流工具，而非设计工具 另外模型其实是多维滴，现在滴东西，都只能反应2维方向，所以他们开始使用各种“视图”去表现（包括类图，时序图其实都是2维方向），所以最终滴问题，你只能去拟合成多维滴，问题就在于在拟合过程中，多少都有缺失，这个就得看设计的人自己的个人本事了，所以又引出另外滴问题，所有传教滴号称他是神仙，但是设计的人不是神仙（所以很多被传教滴人给带滴人我就神仙，我UML了我就能设计了，其实不是，这只是个假象，如果你是神仙，你不UML也是神仙，如果你不是神仙，那么你就是用了UML也还只是个凡人）

[wanghui0380]

当然其实OOAD，UML本身都没错。错就错在，不管是设计的，推广滴都会给人一个良好的感觉，认为一旦这样了自己就是神仙 博客园有位写大话UML滴曾经叫冤，你们干嘛都反对我？？我不过就是想给人以自信！！额，我们表示他们是自信了，但是他们依然是凡人，不是神仙。你给他这个自信其实是让他们反的错更多，心灵鸡汤这玩意除了让写滴人成功，至于其他人还能成靠心灵鸡汤成功不？？所以我们不反对心灵鸡汤，但是我们要多写一句“本故事纯属虚构，如有雷同纯属巧合”

[bluedoctor]

在企图精确描述软件世界时，模型并不比编程语言更优越——即，在深入到一定细节后，表达等量的内容，模型和编程语言同样复杂（如果前者不是更复杂的话）。 ------ 楼主讲道点子上了!

[software_artisan]

楼上说得好，工具本身并不存在对错，只有合适不合适。在软件生产的不同环节里面，适用的工具是有区别的。UML适用的场景真的非常有限，我也认为他很鸡肋。我们在讨论业务的时候，一般还是画BPMN流程图加上思维导图。因为BPMN流程图可以很保真地描述业务的流程及其边界，而思维导图则能够很清晰地展示细节。

[SmileSkyNet]

我觉得工具用起来根本就不方便，我喜欢用本子和笔来，那快多了。

[flatbean]

我觉得在分析与设计阶段，用UML建模工具（例如：Enterprise Architect） 画出领域模型，抽象出关键类，一边画顺序图，一边完善类，思路非常清晰。循序渐进，图画好了，类也就设计好了。

[莫聆]

自己没用过和没见过别人用 不代表UML用处不大，国际上有个ISA95标准，这个标准里就用了大量的UML图来说明，还有Eclipse的插件体系基于的OSGI的标准说明文档，里面也有大量的UML，这种级别的文档，不懂UML根本就看不懂里面讲的是啥。

[qq_28906729]

引用 28 楼 yutao051 的回复:

自己没用过和没见过别人用 不代表UML用处不大，国际上有个ISA95标准，这个标准里就用了大量的UML图来说明，还有Eclipse的插件体系基于的OSGI的标准说明文档，里面也有大量的UML，这种级别的文档，不懂UML根本就看不懂里面讲的是啥。

OSGI和UML一样，都是垃圾设计出来的垃圾货。还有捧臭脚的。

[畅想者]

鸡肋，不够方便，画个类图，我代码都写完了

[莫聆]

引用 29 楼 qq_28906729的回复:

[quote=引用 28 楼 yutao051 的回复:] 自己没用过和没见过别人用 不代表UML用处不大，国际上有个ISA95标准，这个标准里就用了大量的UML图来说明，还有Eclipse的插件体系基于的OSGI的标准说明文档，里面也有大量的UML，这种级别的文档，不懂UML根本就看不懂里面讲的是啥。

OSGI和UML一样，都是垃圾设计出来的垃圾货。还有捧臭脚的。[/quote] 那你有贡献过什么标准吗，可以分享给出来给大家看看，看看你设计的好在哪里。