为什么使用UML图计划代码的组织方式不合适？

因此，是的，图表有时可能不合适。什么时候不合适？当您创建没有代码的代码来验证它们时，然后打算遵循它们。绘制图表探索想法没有错。

_{敏捷软件开发：原理，模式和实践 -Robert C. Martin}

他到底是什么意思？UML是否旨在帮助计划如何在 “切入” 之前构造代码？如果您不遵循自己想到的图，使用它有什么意义？

上下文：在本章中，鲍伯叔叔为保龄球比赛的得分保持者制作了一个UML图。然后，他继续以测试驱动的方式开发程序，而无需查阅UML图。生成的程序与UML图完全不同，鲍勃叔叔得出了上面引用的结论。

为了正确解释这一点，我们需要简短的历史课程。在软件工程的早期，经常使用的比喻是盖房子。建筑师和结构工程师与客户讨论计划并提出设计方案。然后，建造者按照该设计来建造实际房屋。编写代码被视为等同于建造实际房屋。因此，在构建之前就已经意识到需要先期设计。创建了各种图形设计工具，其中UML是其中之一。

最初使用UML的想法是，人们将使用UML完全设计一个系统，然后将其移交给编码人员以将该设计转换为代码。实际上，这根本行不通，并导致多年的程序员被视为“实施者”，而不是“设计师”，项目迟到，设计必须在完成后必须不断更改等。

原因很简单。编码是设计。与房屋类似，代码是建筑师的图纸。编译器是构建器，他们接受这些设计并从中构建程序。然后，这种认识导致了敏捷技术，TDD等的诞生：帮助提高该代码设计质量的工具。

就像架构师可能会生成初步草图来帮助她和她的团队可视化整个设计一样，开发人员可能会使用UML或其他工具来可视化所需的设计。正如这些草图不是盲目遵循的一样，UML也不应盲目遵循。代码设计应从敏捷迭代和使用TDD演变而来。同样，就像建筑师可以构建房屋模型来帮助她和她的团队可视化图纸一样，UML可以用于帮助可视化代码结构。

正如Bob叔叔所说的，您不能验证UML，只能验证代码。因此，该代码是主要的设计文档，而UML（如果使用）仅是辅助文档。

我想并不是每个编程习惯（或设计或代码）都适合UML（我承认我不太了解-只读了几本书，但我从未使用过，我可能不喜欢它）。

UML 可能无法完全建模纯C代码（例如Linux内核的源代码）。

Ocaml代码（及其模块和函子）甚至C ++ 11代码（具有lambda和模板）可能都不适合UML。

MetaOcaml的多阶段编程可能不适合UML。

Prolog代码或Common Lisp代码可能不适合UML。

另请参阅此答案和此问题。

阅读Scott的《Programming Language Pragmatics》和Van Roy的《计算机编程的概念，技术和模型》书籍，然后问问自己每个编程模型是否都适合UML。

另请参阅马丁·福勒（Martin Fowler）的《设计死了吗？博客。