UML（统一建模语言）是软件建模的表示法标准。我从2002年开始专门从事研究和推广UML的工作，在为软件组织提供UML相关需求和设计技能服务时，经常会发现软件开发人员对UML建模存在种种误解。本文归纳了最典型的八个误解加以剖析。 误解一：UML是开发团队用来和客户沟通的 UML模型是开发团队内部高效沟通的手段，但不是用来和涉众沟通的。拿音乐中的五线谱类比，五线谱是音乐专业人士交流的工具，作曲要懂、编曲要懂、乐手要懂、指挥要懂、歌手要懂（注意：是懂五线谱，不是人人都要用五线谱作曲），但听音乐的人不需要懂。UML只是在“软件开发人员”圈子里面的统一表示法，强迫开发人员思考，改善开发人员的交流，表达软件开发的模型。 另外，“和客户沟通”的说法本身就有问题，因为“客户”不是一个人，而是一个组织，里面有不同角色和岗位的“涉众”。他们的学历职位有高有低，年龄有大有小，关注的利益更是各自不同，所以，和涉众交流的介质不是模型本身，而是模型的各种视图。面对大领导，我们可以给他放幻灯片交流愿景；中层干部喜欢看文档，我们可以按照他喜欢的格式给他炮制文档；一线操作工只关心他那一小块工作，我们可以制作界面原型和他交流；有时候甚至有的涉众根本不喜欢看任何东西，我们还可以通过“谈话”这种视图和他交流。涉众连谈话都不乐意，我们也可以通过观察来获取素材。许多伟大的创新需求正是有心人在涉众不作声的情况下，观察涉众的行为得到的。 涉众能提供的只是需求的素材，没有资格也没有责任直接提供需求。软件需求不是由涉众直接提供的，而是由需求工程师综合不同涉众的利益决定。就像电影剧本一样，剧本不是由观众直接提供的，而是由编剧根据不同观众的口味编出来的。
许多开源软件没有用UML建模 。许多流行起来的开源项目（Linux、Apache、MySQL...）确实没有使用UML建模，但是这些项目的核心领域多为基础设施领域。基础设施领域的"负载"（需要依赖的领域的数量）比较低，只需关注计算机的资源，不需关注医院、税务、物流....。因为负载低，基础设施级别的分解和复用相对容易，而且基础设施领域有大量的教材和先行例子，程序员在学校里已经受过这方面的教育，大脑比较容易把握基础设施领域问题的复杂性，所以对显式建模的要求没有那么高。 很多能够带来利润的系统"负载"比较高，除了核心领域（如医院）的知识，还要依赖于其他非核心域的知识，而且，核心域并没有那么多人去研究。很少有类似这样的书，把一家医院的流程，各种业务对象之间的关系，用某种方法（彩色UML建模也好，以前的数据流图＋ER图也好）研究得透透的。要在市场上获得竞争优势，有必要把复用的级别提升到核心域的复用（因为其他的好处，竞争对手也能获得），这确实很难，但再难也要做。这时，建模技能就必不可少了。 在这方面，不少媒体有误导。媒体会访问某些“知名程序员”对建模的看法，得到的回答可能是“对我来说不重要”。这里面的原因是：基础设施领域的程序员更容易得到媒体青睐成为“知名程序员”，因为“芯片”、“操作系统”等词汇上的光环会把媒体晃晕。更不客气地说，其中一些“知名程序员”实际上仅仅是“玩家”，不了解开发带来利润的软件需要付出的辛劳。
UML模型去和涉众交流，很容易导致“四不像”。不少开发团队十年如一日没有进步和积累，“交流影响开发”是原因之一。为了迁就不同涉众的知识水平，开发团队只好损害模型的严谨性，即使是这样，涉众也不一定接受，交流效果还是不好，而且还会因为涉众的交流形式多变而影响开发团队核心工作流的稳定─——双方都受害。客户的领导说，我不习惯看UML模型，就知道以前看的是××标准格式的文档，我只在这个格式的文档上签字，难道我们就不用UML建模了？下一个项目的客户领导喜欢另一种格式怎么办？下下个项目根本不需要签字怎么办？互联网网站没有“客户领导”签字确认需求怎么办？建模的目的是帮开发团队思考，它可以指引开发团队发现到底需要向涉众了解什么，但不是直接拿着模型和涉众交流。 开发人员有意无意把建模的目的理解成和涉众交流，有时背后的思想还是“懒”字，因为这样想，就有了推卸责任的机会：不是我不想建模，就算我建模了，客户不想看啊。