使用UML最显着的缺点是什么？

Question

UML是一种很好的语言，可以根据业务需求为软件建模，但是有一个不断增长的社区为某些缺乏功能指出了一些缺点。

您认为对UML至关重要的最重要的缺点是什么？它可以成为解决这些缺乏功能的好方法？

Answer 1

最大的问题是，这是另一层繁文缛节，只会让$＃％$＃％编码并使其正常工作。

Answer 2

事实上，人们使用它来“为业务需求建模软件”，正如你所说，以及其他这样的面向过程的哗众取宠。 UML最初是作为程序员以图形形式向其他程序员传达软件的传统方式。从这个意义上讲，这只是正式的餐巾纸涂鸦 - 因此它非常有效。你可以在白板上绘制一个UML类图，我可以理解它而不需要用符号表示。

但在某个地方，有人认为绘图符号可能在某种程度上是一个独立的过程，或者至少是一个更大过程的正式部分。那太傻了。 UML图表是一种很好的方式来说明书籍，并且非常有用，可以让工程师来回地书写想法。但那就是应该结束的地方。

Answer 3

我至少可以说三个：

1. 保持图表合理并与实际代码同步需要花费大量时间。 UML图不运行，但需要很多时间。因此，只有当您的组织规模可以管理时，它们才是好的
2. 您不能代表序列图中的每个条件。如果你想交付，这是不可能的。所以状态图应该传达基本事实，而不是所有可能的结果。
3. 好的UML软件需要花钱，而且需要一段时间才能正确掌握。

所以，我认为UML作为一个补充文档角色很好，只有当你的组织规模允许时才会这样做。

解决方案......最后，图表只是一种将高级别信息传达给他人的方式，无论是在空间还是时间（例如，某些年份都可能是你）。极限编程将信息检索的负担从死树转移到活脑。当然，它假设活着的大脑永远不会忘记，永不退出。极限编程使用冗余来减少此类事件的影响。在一家大公司中，强大的裁员可以消灭整个团队，因此将信息存储到大脑中可能会有风险。另一方面，大公司有人力浪费，因此图表。

另外，正如WDuffy指出的那样，如果你是一名设计师，并且你必须与程序员团队沟通他们必须实现的东西，那么使用UML图会容易得多。当然，一个拥有小团队的小公司通常目标很小，你可以组织不同风格的人。一家小公司UMLing只生产其革命性产品的UML图表，然后就会破产。

UML不好也不坏。它可以是一个很好的工具，但必须在适当的环境中使用。

缺乏功能？

好吧，我发现UML强烈瞄准了面向对象的世界愿景。我们公司主要以python开发，重点关注模块级例程。对象是轻量级数据容器，但所有逻辑都是在模块级别完成的。除非你在术语中使用一些“黑客”，否则很难在UML级别正确建模这种实现方式。我想在UML中使用函数或过程语言进行建模很困难。

我觉得讨厌的另一件事是将用例建模假设为图表。我的经验是，传达用例的最佳方式是编写一个简短的故事或简短的代码，使您想传达的功能发生变化。故事应该简短，最多一页。 这种方法有两个优点：如果您的故事是书面散文，Q / A团队可以轻松阅读和测试。如果您的故事是代码，您可以将其作为功能测试并让它在夜间运行。图表不满足任何这些增值需求。

Answer 4

UML的一个问题是它的普遍性：UML中的东西不能总是直接用目标语言实现，或者某些语言​​具有无法用UML表达的功能。因此，事先了解实现语言会更好，这会限制其普遍性。

另见UML wikipedia page上的批评部分：

• 标准膨胀

• 学习和采用中的问题

• 累积阻抗/阻抗不匹配

• 功能失调的交换格式

Answer 5

不是 Agile

应该是什么 the last word on UML 是由沮丧的学生“Candide Smith”撰写的，嗯，真的是埃菲尔作家Bertrand Meyer.

Answer 6

UML的另一个缺点是它倾向于过分强调设计，这可能导致“分析瘫痪”（人们过度分析他们的问题）和特征蠕变（忽视实际问题）。 UML设计在解决问题方面只能带你到目前为止，你必须小心地尽快跳转到代码中（但不能更快; - ）。

Answer 7

UML不太适用于松散打字和NoSQL数据库这个勇敢的新世界。它有OO的类思想作为数据结构而不是嵌入其中的分类。

另一个缺点虽然不是自己造成的，但它并没有明确地促进抽象。我认识的每个人都使用UML工具进行更抽象的建模，但标准的编写方式并不明显。

Answer 8

UML的另一个问题（以及一般的大型设计）是，有时很难预测到您可能遇到的所有可能影响您的设计的实质性实现问题，直到您真正开始实现某些事情。当然，我是一名生物信息学研究程序员，致力于小型单人项目，但我甚至不相信任何设计，至少对于小型项目。我相信以下几点：

1. 让它发挥作用。 （只要得到一个具有所有基本功能的原型，无论它多么糟糕。这迫使你看到在正式分析中可能无法通过的所有细微的细节。实际实现你的想法这样可以更容易地看出这个想法是否真的值得做，或者是否应该完全取消。）

2. 做对了。 （只有现在，当你有一个工作原型并且你知道所有细节实现问题至少在原则上是可解决的时候你是否担心好的设计。重新考虑它以遵循良好的编程习惯，减少耦合，做正确的错误处理，yada yada yada。）

3. 快点。如果是应用程序代码，你最好有证据证明你找到了缓慢的部分。如果它是通用库代码，那么你最好有充分的理由相信这段代码可能合理地成为库的某些用例中的缓慢部分，即不优化没有人会在循环中调用的函数。

Answer 9

对于UML中的类图，只有在自动方式直接从图中生成代码时才使用它们。我已经实现了基于OMG（对象管理组）推荐的4层元级别的这种UML编辑器工具，并且我们在5个开发团队中使用UML超过2年进行大约20-30次架构迭代，取得了巨大的成功。该图是自动构建链的根工件，对数百个派生工件，API，生成的Docs，DDL，项目，测试等产生影响。

因此，如果你真的在其中进行编程，那么单独使用UML in Class Diagrams部分是很棒的“编程”语言。

对于UML中的类图，如果它不能以自动方式翻译，那么它就会失败。