我的背景是物理而不是计算机科学，并且从未在大学学习过任何关于类/组件图等的类(class)，而且我从未发现有必要在工作中使用它们。
我不明白的主要问题是，如果代码仍在开发或维护中，您如何使它们保持最新？
例如是什么阻止我重构几个方法或类并使类图过时？
您是否必须不断地手动更新图表？
我见过从代码生成 UML 的工具，我想这些可以使它保持最新，但据我所见，自动生成的图表似乎不够有用。
项目的 UML 是否可能在开始时创建，然后留在文档文件夹中并逐渐变得越来越过时？
最佳答案
我在一家中等规模的政府机构工作，因此我们的大部分主要项目都属于“企业 Java”类别。这对我们有用:
- 架构师使用 UML 图对我们公司数据模型的任何更改和扩展进行建模。通常会有一个概念模型类图，以及一些说明系统各个部分如何交互的序列图，可能还有几个组件图。
- 我们与业务分析师、数据库管理员和首席开发人员进行了演练。这个想法是为了挑战新模型，并就变化达成一致(在这些 session 上有很多“激烈”的讨论)。有了优秀的架构师，变化就会很小。
- 高级开发人员创建技术规范，其中通常包括基于架构模型的物理数据库 ER 图。我们根据物理模型自动生成数据库创建脚本。
- DBA 升级创建脚本(例如添加表空间和索引空间信息)并创建/扩展数据库。
- 代码写好了。开发人员可以创建他们自己的迷你类层次结构(例如，用于携带数据的 POJO)。我们不会费心在 UML 中对这些进行建模，因为代码应该是自文档化的，并且随着代码的发展，更改是不可避免的。
- 在开发阶段经常会发生变化，尤其是在使用敏捷方法时。如果这些影响到企业数据模型，那么 UML 和 ER 图将被更新。
- 在项目结束时，更新文档以反射(reflect)“竣工”状态。
回到您的问题的要点，我不太相信自动化 UML <-> 代码生成。通常，UML 图的个人数据(注释、关系基数、序列图等)不会出现在代码中或很难提取。相反，代码包含不一定在逻辑 UML 模型中显示的内容(例如行为方法工作逻辑、数据结构和缓存)。然后是如何将逻辑模型类层次结构映射到数据库表的整个问题...
总而言之，我建议:
- 预先正确设计。对逻辑模型的更改成本高昂且难以实现。
- 使用可支持来自同一数据源的所有工件的建模工具。即初始UML逻辑模型、数据库ER图和数据库创建SQL DDL。我们使用 Enterprise Architect，但还有许多其他工具可以执行此操作。
- 使用 UML 为“大图”建模，忘记它来描述详细的编码。一个好的经验法则是，如果对模型的任何更改影响的不仅仅是您的团队，您就需要 UML。 (例如，一个新的数据库字段可能需要更改数据库、更改 Web 服务、更改 GUI 和更改大型机批处理过程。UML 在定义数据更改方面占有一席之地，多个团队可以通过这种方式定义数据更改)明白)
关于java - 您如何使 UML 图保持最新？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24474063/