因此，当我上大学时，就接受了UML的好处及其在代码开发中的未来的教育。

但是从我的行业经验中，我发现虽然我们确实使用图（从ER图，类图，状态图到工作流程图），但它们都是出于通信目的。

也就是说，我从来没有从图表中自动生成过代码，从沟通的角度来看，我通常会尽量使图表尽可能简单易懂。

但是，当我查看Visio和Enterprise Architect时，似乎它们具有许多不同类型的图形，形状，属性对象，而其中大多数我都不使用。

人们是否使用UML做更多复杂的事情，例如代码或数据库生成？

是的，UML CASE工具是90年代的热门产品之一……但未能交付。

这样做的根本原因是，UML（或大多数其他类型的）图仅在该图抽象出实际代码的实现细节的情况下才有助于理解问题和/或解决该问题的程序。因此（对于任何不平凡的代码段），易于理解的图对于代码生成本来就没有用，因为它缺少必要的细节。反之亦然，直接可用于代码生成的图表并没有比代码本身更好地帮助您理解程序。如果您曾经见过从生产代码反向工程化的UML类图，那么您可能知道我的意思。

我知道的唯一可能的例外是实体关系图，它本身不包含代码，仅（如其名称所暗示的那样）包含数据和它们之间的关系。但是我从未听说过成功尝试使用任何类型的UML图进行真实代码生成[更新]的事实，即除类骨架和诸如getters / setters的琐碎代码之外，除了在经过验证的ORM之类的专用工具/领域外，由[/ Update]下面的Doc Brown撰写，我认为这并非偶然。

我个人并不讨厌UML-我认为UML图表可以成为一种很好的交流工具 -在设计讨论期间显示您的意图和想法，或可视化应用程序的体系结构。但是最好还是让他们坚持下去，而不要尝试将它们用于他们不擅长的事情。

因此，当我在uni时（现在是前一阵子），我被告知UML是未来，UML将取代编程，我们将仅从图等生成代码。

他们错了。这将在人们放弃演讲并回到洞穴绘画时发生。

实际问题以及解决这些问题的程序具有无法降低的基本复杂性。要生成一个工作程序，必须捕获这种复杂性并以某种可执行语言来表达。问题是某种图形化编程语言是否会比文本编程语言更有效。我们已经进行了大约30年的图形编程实验，到目前为止，绝大多数证据都支持文本编程。我不知道从图的代码生成所产生的任何重要应用程序。

没有

图例基于以下错误假设：

class ClassName extends SomeThing
{

}

...这很困难，需要自动化。

您仍然可能会发现偶尔的信徒或成群的信徒。
但是，宗教和邪教就是这样。

到过那里，觉得它没有太大用处。

通常，足够具体的图可以从其中生成一些代码，主要是类图，并不会增加实际理解程序的方式，并且您不能从概述图（如用例或概述级别的活动）生成代码。对于文档至关重要。状态图是一种有助于理解并且可以从中生成代码的图表，当您确实需要状态机时，它非常有用。但通常您应该尝试避免这些情况，因为它们天生就容易出错。

在一个项目中，我们需要在UML建模器（Rhapsody）中设计代码并从那里生成代码。与手动键入标头（它是C ++）和原型相比，这种方法行得通，并且可能稍微容易一些。自动保持这两个一致性的功能有些方便。

方法主体仍然必须手工填写，因为除了状态机框架之外，这些图无法真正表示出来。

另一方面，它相当复杂，因此您必须学习很多额外的东西，更重要的是，合并很痛苦。对文本文件进行了充分的研究，并且可以使用它们，但是还没有人发明出简单的方法来将更改合并到图表中。Rhapsody实际上将部分信息保留在生成的代码中并解析回去，因此它并不是完全不可用的，但仍然是很复杂的事情。

虽然当然可以直接从UML模型生成代码（甚至整个系统），但我从未遇到过以这种方式使用它。

以我的经验，大多数公司似乎都将其用作需求的交流工具，或称为“ MS Paint绘制图表”。

我要做出的一个重要区别是，大多数UML建模工具都允许您建立系统的单个模型。例如，Visio对UML的工作原理有很好的了解，您可以添加许多与图不直接相关的东西。实际的图只是模型各部分的不同观点，使您可以突出显示系统的不同方面。

所有这些（建模图）用于通信目的

建模在软件开发过程中有4个重要用途：

1. 集成设计工具

2. 通讯工具

3. 辅助软件生成

4. 一种减少实词问题复杂性的方法（我从上面的@kevin cline的响应中学到了这一点）

5. 建模过程使一些设计人员可以考虑编码时未考虑的细节（反之亦然）。在设计时进行建模使您可以考虑比用语言编码方法或类更大的画面。

我认为建模对于构建数据库（ER图），理解流程（活动图）和理解用户系统交互（用例图）至关重要。

人们是否使用UML做更多复杂的事情，例如代码或数据库生成？

确实是的。可以使用ERD（不是UML图）和类图（取决于工具的功能）来生成：

1-数据定义语言（DDL）

2-用您首选的语言存储CRUD和类图的过程（因为ORM工具对此做了更多的工作，所以没什么用）

建模工具最有价值的功能包括：

1-保持模型完整性的能力。如果进行更改，它将在模型中传播

2-能够回答在哪里使用的问题（模型中的“帐户”在哪里使用？）

3-允许并发用户在模型上工作的能力

4-在图形表示中搜索

5-打印控制

6-分层（将图表元素分层组织），以便您一次可以专注于一层

7-几个数据库系统的数据库代码生成

8-模型验证（检查一致性，缺少键，周期等）

因此，建模工具（尤其是好的工具）比Paint的功能要强大得多。

我们使用Software Architect进行高级设计，并在我们的资料中记录一些更神秘的组件交互。有时我们会从图中生成应用程序的框架，但是一旦完成，我们将分别维护它们，因此，在完成代码后，我们不会尝试将代码反向工程回图中。我曾经使用过一个称为Rational XDE的工具，该工具在小型程序上运行得很好，但是当您开始添加Swing事件处理程序或尝试使用Struts时，它会丢失。

我认为人们不使用UML编写代码的很大一部分原因是，要在UML中完全指定所有内容，然后从图中生成代码，还需要进行大量工作。我知道美国国防部正在与OMG合作开发一些工具，这些工具将从已经被验证正确的图表中生成“经过验证的”代码，但是我的印象是，最终您将获得比实际代码多一个数量级的元数据。这可能很好（毕竟是文档），但是生成元数据并不比编写代码快，因此您成比例地花费了更多时间。

UML本身是一种符号系统，因此是进行通信和记录的原因。从UML模型生成代码的情况很少见，但是确实有人这样做。Rhapsody用户比Rose更经常这样做。困难的部分是保持模型和代码同步，对于大多数实际项目而言，成本太高了。

在我的最新项目中，我正在使用UML-Lab（https://www.uml-lab.com）。这是一个很好的工具，它还可以对模型进行逆向工程。该工具会生成相当准确的Java代码，甚至JPA批注。

挑战在于团队合作。该模型是静态的，并且位于单个资源中，这使其与多个开发人员更改保持同步有点困难。有一个可供试用1个月的试用版，如果您正在调查，则是探索和与他人比较的好时机。

这是我第一次看到一个产品同时进行代码生成和对象建模以及数据建模。

否则，在过去的项目中，我总是会看到过时的模型，这些模型不准确或过于详细。

在过去的项目中，有时会通过逆向工程生成图表。大多数情况下，我发现图表混乱不堪，我更喜欢手动绘制图表以过滤掉所有噪声。

我认为我们可以使用UML生成代码。不是业务逻辑，因为业务逻辑不是标准，并且会因应用程序而异。类图和ER图可用于生成接口，类，休眠实体，基本的dao方法等。其他样板代码（如外观实现，数据类型转换器（例如，用于传输对象的实体））也可以借助对象图来生成。 。

另外，如前面的评论中所述，可以使用模型来生成数据库模式，DDL脚本等。

使用OAW和诸如Enterprise Architect之类的建模工具，我们可以编写更强大的代码生成器，甚至可以帮助生成配置文件，使用原型和标记值的工厂代码。

我仍然不明白为什么带有Business Object之类的工具的商业智能能够分析并利用所有公司信息，而在技术级别上，我们仍然只在代码级别或在UML的抽象级别上工作！

问题不在于UML，而是UML和MOF之间的模型转换以及使用模板从clas图或xmi生成代码。据说UML提供了真实世界的抽象视图，因此您只会看到真正重要的东西。话虽这么说，如果UML图只是真实世界的视图，如何生成准确的代码？这是不可能的，因此将无法从模型生成代码的模型驱动开发失败。

解决方案是进行转换以映射现实世界，从而将所有项目代码映射到单个UML模型。具有单个模型和项目完整的逻辑，然后您就可以从模型而不是每次从代码生成视图。Omondo在Java / Jee技术中提出了一个勇敢的倡议。该概念是直接将MOF和UML与代码和ORM实时同步。UML图现在只是映射整个项目的模型的高级视图。您可以创建数百个视图，添加数百个便笺等...以更好地了解项目。仅当更改或创建元素时，才会生成代码。出色的技术，其中Java ID映射到UML id，而MOF和UML之间没有传统的转换桥。

能够在UML级别上对我的域进行建模并直接在代码中获取我的ORM注释也是一件很了不起的事，因此，使用Hibernate，我可以在永久的持续集成中创建，擦除，创建数据库，部署等... UML是所有体系结构的一部分，而不是项目体系结构本身。

如果与代码进行实时同步，UML不会让我感到失望，因为它可以与代码进行实时同步，但是对于传统的将MDA与模型驱动的开发模板代码生成结合使用，我绝对感到失望。从模型生成代码就像来自Word文档的HTML页面一样。生成后如何更改？只是不可能进行更新，而且比从头开始编写要花费更多的时间来清理代码！