代码通常是从UML生成的吗？

Question

因此，在我上大学的时候，我接受了关于UML的好处和它在代码开发方面的未来的教育。

但从我的行业经验来看，我发现虽然我们确实使用了图表--从ER图、类图、状态图到工作流程图--所有这些都是为了通信目的。

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

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

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

Answer 1

所以当我还在uni的时候(不久前)，我被告知UML是未来，UML将取代编程，我们只会从图表等生成代码。

他们错了。这将发生在人们放弃言论，回到山洞绘画的时候。

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

Answer 2

NO

这个传说是基于一个失败的假设，即写作：

class ClassName extends SomeThing
{

}

.很难，需要自动化.

你仍然可以找到偶尔的信徒，或成群的信徒。

但宗教和邪教都是这样的。

Answer 3

去过那里，发现它不太有用。

通常，特定于从它们生成一些代码的图表(主要是类图)不会增加太多实际理解程序的方式，而且您也无法从概览图(如对文档至关重要的用例或概述级活动)生成代码。一个有助于理解并可以从状态图中生成代码的图表是状态图，当您真正需要状态机时，它会派上用场。但一般来说，你应该尽量避免这些问题，因为它们本身就容易出错。

在一个项目中，我们需要在UML建模器(Rhapsody)中设计代码并从那里生成代码。它有点工作，而且可能比手工输入头(是C++)和原型稍微简单一些。保持这两种情况自动一致的能力在某种程度上很方便。

方法体仍然需要手工填充，因为除了状态机骨架之外，图表并不能真正地表示这一点。

另一方面，这是相当复杂的，所以你必须学习许多额外的东西，更重要的是，这是痛苦的合并。合并对于文本文件进行了很好的研究，并与它们一起工作，但是还没有人发明简单的方法来合并对图表的更改。Rhapsody实际上将部分信息保存在生成的代码中，并将其解析回来，因此它并非完全无法使用，但仍然非常复杂。