5

我很难坐在 UML 面前并从中获得价值，因为它看起来几乎与编程一样多（如果您使用表达性语言）。我发现编写自然语言比创建复杂的图表更能告诉我有关软件项目的信息。虽然我是 UML 的新手，但我想知道其他熟悉 UML 的人：

  1. UML 是否值得花时间学习/做，即使对于中小型项目也是如此？
  2. 即使在团队中，精心设计的设计文档是否也足以让程序员保持目标以创建正确的代码？
4

4 回答 4

3

我认为 UML 本身是不够的。

我很难坐在 UML 面前并从中获得价值，因为它看起来几乎与编程一样多（如果您使用表达性语言）。

我同意这一点。UML 可以提供方法签名，但您不填写方法的内容。更糟糕的是，您无法使用 UML 做任何接近 TDD 的事情。如果可以选择，我宁愿使用 TDD 和功能代码而不是 UML 图。

我发现编写自然语言比创建复杂的图表更能告诉我有关软件项目的信息。

发现。图片可能会有所帮助，除非它们是糟糕的图片。除了琐碎的流程之外，序列图往往变得异常复杂。

UML 是否值得花时间学习/做，即使对于中小型项目也是如此？

供应商和架构师会告诉你 UML 是必不可少的，但我不同意。我属于UML 用户的“skecher”阵营。

即使在团队中，精心设计的设计文档是否也足以让程序员保持目标以创建正确的代码？

我不知道什么足以让程序员保持目标，但我猜 UML 并不是其中的重要部分。架构师往往喜欢它，因为 UML 工具让他们忙得不可开交，但大多数开发人员并不关心白板上的方框和箭头。

于 2010-02-28T23:56:10.220 回答
2

我会回答：

没有什么，绝对没有什么可以取代编程团队中的程序员和管理人员之间良好沟通的需求。

这意味着在一定程度上将任务分解为简单的“我们需要做什么”陈述，供管理者使用，并解释任何障碍。

我在一个小型项目中工作，其中程序的整个类结构是在编写任何代码之前由 UML 中的某个人设计的。很好，但是设计者没有预料到这些类的使用方式，或者需要更改某些结构以更好地适应程序逻辑。他们只是抛出了一个他们认为可行的设计。

我还没有遇到可以在头脑中设计程序并在编写非常简单的东西时准确地产生程序的人。这个过程是相当有机的，随着程序员意识到他们早期的错误并纠正它们，事情确实需要改变。我可以看到为什么功能蠕变开始发生，这就是管理层需要了解正在发生的事情、保持循环和更新的地方。优秀的管理者会倾听他们的程序员告诉他们的内容并相应地调整目标。

所以，在你的两个选项中，我会选择高级设计文档：我们希望软件能够做到这一点，在这个平台上运行，接受这种输入并吐出这种东西。如果上述内容保持不变，那就行得通。

就我而言，UML 不值得。

于 2010-02-28T23:54:37.937 回答
1

  1. 在我看来不是。作为计算机科学理学硕士的一部分，我曾经做过一个 OO 设计模块，而 UML 几乎没有被提及（尽管在我看来，鉴于它的影响，它应该被更多地讨论）。

  2. 在书面文本中减少歧义的余地比在 UML 图中要大，大多数 UML 图表留有很大的解释空间。话虽如此，我非常喜欢在软件设计文档中使用图表，而且很多 UML 图表都非常简洁：部署、状态、类和活动是我的最爱。当我创建 UML 图时，我会尽量遵守约定，但如果它们不能代表我试图传达的概念，我不会让它们妨碍我。

于 2010-02-28T23:53:39.880 回答
0

我们不能完全忽略 UML，因为某些图表在涉及复杂功能时很有帮助，或者说较长的工作流程和场景，开发人员可能会错过一些未绘制/设计场景的情况。UML 的另一个重要性是在未来记住系统如何工作以及它的模块如何相互通信，以确保项目是可扩展的，而不会产生可能是不定式和严重的巨大错误。因此，书面设计文档和 UML 对于任何中型或大型项目都很重要。

于 2014-05-27T22:05:17.940 回答