architecture - UML 仍然被视为记录软件设计的可行方法吗？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

UML 仍然被视为记录软件设计的可行方法吗？

支持任何主张的引用资料可加分:)

Answer 1

我正在回答问题的新版本，该问题将 UML 作为文档工具。我也会尝试将 UML 作为一种沟通工具，因为它们是一体的。

背景:这种观点是由我作为架构师的日常工作驱动的，我必须跨数百个系统/软件进行设计，花费 10,000 多个小时的工作，并维护系统组合的一致文档和实践。这意味着我不得不多次努力解决文档质量、一致性和定义问题。

摘要:还有什么？当然，您可以讨论文档的级别，UML 真的比阅读条件逻辑代码更好吗？可能不会，但总的来说，如果问题空间足够大，就没有真正的替代方案。

如果 UML 没有别的意义，那么它就是用于文档和通信的。 Martin Fowler 所著的《UML Distilled》几乎是 UML 书籍事实上的标准，它就持有这种观点。如果我没看错的话，Fowler 相信 UML 的主要用途是通信，而文档只是静态类型。没有那么多低级规范和代码生成。

IBM、Borland、Microsoft 和 Eclipse 通过大型复杂工具支持 UML。许多其他较小的或有针对性的供应商也提供 UML 工具。我不知道有更被接受/实现的图表/建模标准。

另外考虑替代方案，哪种图表表示法更常见？为什么不使用大多数人都知道的东西呢？大多数学院/大学在教授任何图表或建模时都使用 UML。除了一些流程或条件逻辑图样式之外，没有太多其他内容，有良好的文档记录和标准化。

标准表示法比大多数人所知道的更为重要。在大型项目中，您无法总是阅读代码、与编写代码的人交谈或再次询问业务合作伙伴他们想要什么。这就是标准的关键所在。不一致的用法会导致困惑，如果允许人们以非正式的方式发明或添加符号，情况确实会如此。此外，您不想创建文档并且总是必须解释您的意思。

永远不要发明，除非你也发明过，这是 UML 最有可能的替代方案。想想每次有新人加入团队或公司时。方框、箭头是什么意思？这个箭头能否在这个方向上连接到这个三角形，这意味着什么？您基本上必须发明一种特定于领域的语言/模型。因此，您需要培训演示、教程、示例、审查工作、安排培训类(class)、维护发明的文档方法等。当然，您会切换任务合作伙伴，或雇用一个新人，您必须重新开始。让人们专注于学习系统而不是文档方法，或者是否必须使其成为可转移的知识或技能(如 UML)。让专家专注于编码和设计，而不是发明文档/图表标准。

致所有 UML 批评者 我并不生活在象牙塔或玻璃泡沫中，我每天都必须忍受数百种不同的文档方法，因为人们发明了它们，或者我正在寻找下一个供应商技术。 UML并不完美，但它是最常见的，足够好，并且不可轻易替换。

有效的附加问题:

• 我应该使用 UML 直观地记录什么？代码注释可以在哪里接管？
• 哪些跨度或方面更重要？
• 适用于我的系统或应用程序类型的一致工件集可能是什么？ (如果您在拥有数百个应用程序/系统的企业中工作，这是一个关键问题)
• 我们在哪里存储文档并使其可供搜索和发现。