我希望我已经解决了这个问题，因为它不是基于意见的。我不是在问UML是好还是坏，因为我毫不怀疑它对那些专业工作的人有用。
我更愿意知道UML工具是否存在一种临界质量（例如，每周编码的小时数），对于一个孤独的业余爱好程序员来说是有用的。
当然，这假设我在UML方面缺乏成功主要是由于缺乏实践。如果保持练习意味着将90％的业余时间花在UML上，而没有获得太多的工作代码，那么我认为这是“低于临界质量”的一个例子。
业余爱好程序员我的意思是：我项目的典型源代码大小低于1 MB。有时我手工绘制继承树，但就是这样。我有35年的编程经验，所以只是在没有明确的设计过程的情况下写下代码（除了通常的OOP设计原则和模式），这是我对项目的自然方法，并且工作得很好。
在我过去的工作中，我与UML工具（Rhapsody，Enterprise Architect）有过一些肤浅的联系，这主要不是软件开发。例如，有人曾经问我一次在SYSML中建模机械概念。
我知道大多数语言结构，大概也是他们的意思，但说实话，我真的不知道如何使用它们对我有利。只需花费很多时间就感觉不到生产力。而且，与编码某些行并仅测试它们相比，没有更直接的反馈。此外，当尝试使用UML时，我发现自己处于一种情况下，问题似乎变得更加复杂和过度设计而不是变得更清晰。就好像使用抽象语言让我无法看到实际上真正必要和相关的东西。
另一方面，我有时觉得我可能因为不使用UML而遗漏了一些东西。
以下是我的故事：多年来，我作为UML顾问和建模师一直在业内工作。项目通常很大，需要各种UML语言来模拟这些项目。毫无疑问，UML是有效的，有助于发现用户/客户沟通中的问题以及解决编码问题。我也在爱好基础上编程（例如我已经建立了一个程序来管理我们的Shotokan俱乐部的会员资格和付款，并且曾经在AppStore上有一些程序）。这些程序有点左右7.5kloc Swift + - 东西。所有这些都是从头开始而没有太多设计。而且他们现在都处于这样一种状态，即没有适当的（UML）文档的维护开始变得棘手。
为什么不从一开始就使用UML？好吧，像大多数程序员一样，开始一些事情并快速看到投资回报率很有趣。而且因为您在处理它时手头有它，所以您可以在功能之后添加功能。过了一段时间之后，你开始想念你为什么以你的方式做事以及如何运作。啃咬牙齿片刻，稍后你会喝几杯咖啡，这会持续一段时间。但稍后一点也无济于事。在那里我开始重新记录（至少部分）代码。对于Swift来说，由于没有可用的RE工具而且我必须手动创建类图，因此更难。
所以我只是为复杂的部分做类图，以获得概述，并在我遇到麻烦的部分做更详细的部分。从那开始我通常会创建一些SD来控制这个问题 - 这真的有很大帮助。此外，有时即使在编码（！）期间，我也会在某些情况下使用状态图表。当谈到解析DSL或类似的东西时，它们非常方便。
我没有记录我的业余爱好项目的用例。仅仅因为只有极少数而你没有顾客可以处理。
这取决于我想你自己如何处理你的项目。
将可执行模型放在一边，UML用于分析和设计工作，主要用于软件架构和工程（您可能知道）。对于涉及多个人的项目来说，它是非常有用的，他们都可以从讲话和理解复杂软件构造的公共语言中受益：工程（在任何学科中）依赖于工程师交叉验证彼此逻辑的能力并且找到差距，UML是软件工程必须执行此操作的一种语言集。
在破解代码或记录您认为无法在代码中正确评论的想法之前，UML可能对您单独思考复杂问题也很有用。像你一样，我已经编写了一段时间（从80年代开始）并且从1998年开始使用UML。我现在的职业是软件架构（因此我大量使用UML）但我仍然做了很多编码 - 我经常构建概念验证，我有自己的产品，一个是大约250,000行代码（为此我有时使用UML，而其他代码根据需要不使用模型编写）。
您可能更熟悉UML的一件事是软件设计模式。这些通常使用UML进行记录（至少部分），因为实现可能因编程语言而异，而模式概念和结构很常见。
有点絮絮但我希望这有助于你的任务。