UML实用吗？
1
然而，问题不仅仅在于你当前正在做什么。那么将来六个月后加入项目的新雇员需要速成代码时该怎么办？那么将来所有目前参与项目的人都离开五年后该怎么办？
为加入项目的任何人提供一些基本的、最新的文档资料非常有帮助。我并不主张使用完全展开的 UML 图表，包括方法名称和参数（维护难度太高），但我认为系统中组件的基本图表、它们之间的关系以及基本行为的基本图表是非常有价值的。除非系统设计发生了巨大变化，这些信息不应该经常更改，即使实现被微调。
我发现文档的关键是适度，没有人会读50页完全展开的 UML 图表和设计文档而不在几页之内打瞌睡。另一方面，大多数人会喜欢得到5-10页简单类图的基本描述，了解系统是如何组成的。
我发现 UML 有用的另一个场景是，当高级开发人员负责设计组件，但将设计交给初级开发人员实现时。
7
在一个足够复杂的系统中，某些地方考虑使用一些UML是有用的。
对于一个系统来说，适用的有用图表是各不相同的。
但最常用的包括：
- 类图
- 状态图
- 活动图
- 序列图
有许多企业认为它们非常重要，也有很多企业认为它们是完全浪费时间和精力的。
最好不要过火，考虑你所在项目的最佳选择，选择适用且有意义的内容。
例外情况是当你发现自己在夜晚没有手电筒而且开始下雨，这时你需要看着自己的脚步避免跌倒。有时候你承担的任务比你的直觉更复杂，你需要放慢速度并明确陈述你的程序结构。然后，UML就是你可以使用的众多工具之一。其他工具包括伪代码、高层架构图和奇怪的隐喻。
2
通用工作流和数据流程图可以在处理复杂过程时非常有用。根据我的经验，所有其他的图表（特别是UML）无一例外都是浪费时间和精力的痛苦。
我不得不表示反对，UML被广泛应用 - 任何涉及IT项目设计的地方都通常会使用UML。
现在，它是否被使用得好是另一回事。
正如Stu所说，从开发人员的角度来看，我发现用例（包括用例描述）和活动图最有帮助。
类图在展示关系以及对象属性（如持久性）时非常有用。但是，当涉及添加每个属性或属性时，它们通常过于复杂，并且一旦代码编写完成，它们往往很快过时。
UML的最大问题之一是需要花费大量的工作来保持其与正在生成的代码同步，因为很少有工具可以从代码重新设计UML，并且很少有工具做得好。
我想强调一下，我没有在大型（类似IBM的）企业开发环境中的经验。
我认为UML和Rational Unified Process更多地是在谈论你要做什么，而不是实际做你要做的事情。
换句话说，这在很大程度上是浪费时间。
3
仅代表我的观点，应该只是丢弃。UML 是一个很好的沟通思想的工具，唯一的问题在于当你存储和维护它时，因为你实际上是创建了两个相同信息的副本，这通常会导致问题。
在最初的实现后，大部分 UML 应该从源代码中生成，否则它将很快过时或需要大量时间（并伴有手动错误）来保持更新。
3
我在学校的最后两个学期中共同教授了一门高级开发项目课程。该项目旨在与本地非营利组织合作，担任付费客户并用于生产环境。我们必须确保代码符合我们的预期，并且学生们收集了满足客户需求的所有数据。
课堂时间很有限，我的课外时间也很有限。因此，我们不得不在每次上课时进行代码审查，但由于有25名学生注册，个人审查时间非常短。我们发现在这些审查会议中最有价值的工具是ERD图、类图和顺序图。ERD图和类图仅在Visual Studio中完成，因此学生创建它们所需的时间微不足道。
这些图表可以非常快速地传达大量信息。通过快速概述学生的设计，我们可以快速确定他们代码中的问题区域，并立即进行更详细的审查。
如果没有使用这些图表，我们将不得不花费时间逐个查看学生代码文件以寻找问题。
1
- 沟通 - 标准化的设计/解决方案文档 - DSL（特定领域语言）定义 - 模型定义（UML配置文件） - 模式/资产使用 - 代码生成 - 模型到模型转换
考虑到上述用途列表，Pascal的帖子并不足够，因为它只涉及图表创建。如果上述任何一个是关键成功因素或需要标准化解决方案的问题领域，项目可以受益于UML。
应该从如何UML可能过度杀伤或适用于小型项目扩展到讨论何时使用UML会有意义或实际改进产品/解决方案，因为这是应该使用UML的时候。有些情况下，UML对于一个开发者也是有意义的，例如模式应用或代码生成。
原文链接