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

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最有可能的选择。想想每次新人加入团队或公司时。什么是盒子的意思，箭头？这个箭头可以朝这个方向连接到这个三角形，它是什么意思？您基本上必须发明特定于域的语言/模型。因此，您需要一个培训演示，教程，示例，审查工作，安排培训课程，维护发明的文档方法等。当然，您可以切换出任务合作伙伴，或雇用一个新人，您必须重新做一遍。让人们专注于学习系统而不是你的文档方法，或者是否必须使它成为可转换的知识或技能，如UML。让专家专注于编码和设计，而不是发明文档/图表标准。

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

有效的其他问题：

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

Answer 2

思考是设计软件的唯一可行方式 UML有时被视为部分描述您想出的设计的可行方式。

Answer 3

UML只是表示设计的标准符号，它不是一个过程或方法。

Answer 4

IMO，UML失去了大部分形象，成为软件开发唯一且永远最好的解决方案。虽然一开始的爱好者（并且仍然有些人）认为UML将解决设计问题并且理想情况下应该使用UML绘制所有内容。现实证明它并没有比任何其他类型的图表好得多。

IMO，现在广泛认为UML实际上是：oo分析和设计中需要的许多图表的标准。它确实是最常用的图表标准。周围有更多工具，更多人了解UML，然后知道其他任何图表样式。

Answer 5

我更喜欢使用自动生成的UML（源代码 - ＆gt; UML）来可视化系统的实现。我发现静态文档通常是无用的，有时会产生误导。

Answer 6

UML是一种可视化呈现设计的方式，而不是实际的设计方法本身。它只是您在旅途中使用的工具。据我所知，它在软件工程领域仍然非常普遍，因为它是一个标准，可以用来有效地在两个人之间传达思想（这就是为什么它被称为语言）。

Answer 7

UML应该用作通信工具。它绝对是沟通设计的有效手段，并为开发人员提供了一种在实现之前讨论这些设计的通用语言。

记录您的设计的最佳方式是编写干净的代码。与所有其他文档一样，UML倾向于熵。

Here's the best reference I could find

Answer 8

UML可以成为设计和实施过程的一部分。 Enterprise Architect有一些很棒的初始设计工具。如果在自定义更新设计之后没有通过其他重新导入工具备份UML，那么UML就会失败。它确实可以很好地显示您当前的结构，并允许您根据其他UML图表（用例，状态图，用户界面模型等）添加详细信息。

可悲的是，UML确实不习惯它在实践中的全部潜力。

Answer 9

正如@John Topley所指出的那样，UML只是描述面向对象设计方面的标准符号，所以你的问题没有多大意义。

就个人而言，我发现类图是UML最有用的方面;我很少打扰其他大多数东西，因为我发现编写简短的描述性文档更容易解释交互和行为。但是，类图提供了对架构的合理概述。

要记住的一件事是，您不必过分担心编写“完美”（即规范）UML;最重要的是确保人们了解您的设计。也就是说，小心不小心滥用符号，因为这可能会使那些期望事物具有特定含义的人感到困惑。如果有疑问，请用文字注释，以明确发生了什么。

Answer 10

UML更像是一种可视化系统设计的方式，而不是实际设计的过程。虽然能够可视化确实有助于设计过程。

据说，在设计基本架构时，我确实喜欢并使用UML。

在设计时能够看到所有部件如何组合在一起非常有用。在任何编码开始之前，很多时候设计会在执行UML时显示架构缺点。

它可以让人们快速了解系统的工作方式，当您稍后再回到该代码并说“我是如何再次设计它？”时，它非常有用。

基本上回答你编辑过的问题，是的，记录系统设计很有用，因为很多人已经知道了，并且正如已经指出的那样，有很多工具支持它。

Answer 11

这个问题对我来说有些暗示......我不认为UML是一种设计软件的工具，而是一种记录设计（正在进行中）的工具。

在我看来，UML可以成为这种文档的一个有价值的工具，因为它标准化了许多关于设计的观点......但绝不是唯一有效的观点。任何足够清晰和编写良好的设计文档都可以完成工作，即使它没有UML。

Answer 12

Paulo Merson在JavaOne 2006上发表的演讲How to Represent the Architecture of Your Enterprise Application Using UML 2.0 and More描述了使用和不使用UML来记录架构的各种方法。有关Architecture Documentation, Views and Beyond (V&B) Approach的更多信息，描述了软件工程协会（SEI）倡导的方法。

Answer 13

UML只是一种可视化软件设计某些方面的方法。它不能单独用于记录设计。