我是软件工程专业的学生。我的"软件架构与设计"讲师告诉我们，我们可以从所有UML图(或大多数)生成源代码。我已经可以/已经从类图生成代码。我无法从其他图生成代码。我需要把这些图和类图连接起来吗?
这简直是胡说八道。您根本不能从任何关系图生成代码。但是，您可以从UML模型生成代码。这可以(但不是必须)有一些图表来帮助人们可视化。
现在，代码与类相关。这意味着您至少需要在模型中定义一些类。用例有助于理解为什么类会做它们应该做的事情。但是在任何情况下你都不能从用例中创建代码。
还有其他模型元素可以帮助创建更详细的代码。例如，状态机可以转换成等效的代码段。
活动和序列图还有助于可视化某些代码段在执行期间的运行情况。但是你不会(认真地)使用它们来创建代码。
是的，你可以，但它不像你描述的那么简单。模型驱动架构目前是一个活跃的研究领域，但它还没有真正"流行起来"。它的支持者认为，它提供了更高层次的抽象，就像C语言提供了比汇编语言更高层次的抽象，Java提供了比C语言更高层次的抽象一样。我认为，如果他们能得到正确的工具，这个将在未来非常有用。
实际上，这甚至不是一个全新的想法——一般来说，图形化编程的想法(如果你仔细想想，它基本上是uml派生编程的一个泛化)至少在我所知道的20世纪80年代就已经存在了(可能更早)。事实上，Frederick Brooks Jr.在No Silver Bullet - Essence and Accident In Software Engineering(最初出版于1986年，出现在The myth Man-Month的当前版本中)中谈到了这一点:
软件工程博士学位论文最喜欢的主题是图形化或可视化编程，即计算机图形学在软件设计中的应用。有时，这种方法的前景是通过与VLSI芯片设计的类比来假设的，在VLSI芯片设计中，计算机图形学扮演着如此富有成效的角色。有时，考虑到流程图是理想的程序设计媒介，并为构建流程图提供了强大的工具，这种方法是合理的。
这些努力甚至没有令人信服的结果，更不用说令人兴奋的了。我相信没有什么会……
他的论点是，在写这篇文章的时候，工具还没有"到位";例如，屏幕尺寸非常小。此外，流程图实际上是一个非常糟糕的设计机制。另外,
更根本的是，正如我上面所说的，软件很难可视化。无论我们绘制控制流、变量作用域嵌套、变量交叉引用、数据流、分层数据结构，还是其他什么，我们都只感受到错综复杂的互锁软件大象的一个维度。如果我们叠加由许多相关视图生成的所有图，则很难提取任何全局概览。超大规模集成电路的类比从根本上是误导性的——芯片设计是一个分层的二维物体，其几何形状反映了其本质。软件系统不是。
我让你来判断你是否同意他的观点，或者这是否仍然适用。
所以，总结一下:是的，它至少在理论上是可能的，并且从UML图生成代码已经有了相当大的努力，但是您需要多个图来生成比基本类结构和方法存根更多的东西。这不像您可以编写一个用例图，按下一个按钮，然后神奇地拥有一个完整的软件系统。
我想我找到了答案。我们可以生成代码。假设我有一个"用例"。右键点击它。进入"advanced"，选择"instance classifier"。在那里，我可以把我的"用例"、"序列图对象"等作为已经创建的类的实例，或者我甚至可以在那里创建一个类。