UML图对于成功的项目有多重要？[关闭]

我在一个项目的中间，被要求写UML图（用例，类图等）。该项目不是很复杂。

我想知道这是否浪费我的时间？我是否应该做其他有趣的事情，例如编写代码？在什么情况下不经过所有概念阶段就不能建造东西吗？一切都与复杂性有关吗？如果是这样，如何衡量呢？

前一段时间，我是UML的忠实拥护者。我什至获得OMG认证。我在参与的大型企业项目中广泛使用了它。

今天，我几乎完全停止了UML。有时，我使用顺序图，它对描述系统之间的交互非常有用，但没有其他图。

我现在更喜欢使用用户案例，并由产品所有者（或分析师）撰写的（仅）必要文档以及他（他们）对开发团队的奉献，以根据需要提供更多详细信息。

UML是您可以使用的工具，但它当然不是成功项目的关键因素。多年之后，我现在认为关键因素是开发团队，无论使用哪种工具。

规划至关重要，但正如著名战略家卡尔·冯·克劳塞维茨警告

没有任何战役计划能够在与敌人首次接触后幸存

因此，计划最初如何解决问题并不会浪费大量时间。但是可能会浪费时间为将来的程序员编写代码。要使用军事隐喻，您需要一个战役计划，但您不会将该计划交给历史学家以用作事后报告。

更具体地说，您可以使用这些图在团队之间传达您的意图，并在项目之前和项目期间考虑您的攻击计划。但是很奇怪的是，在编写代码并了解有关该问题的更多信息时，您需要对所提供的内容进行调整。几乎总是需要更改您的初始计划/设计，因为您可能不了解所有事情。

我认为UML图只有在以比您的代码更高的抽象水平表达某些内容时才有用。

仅出于编写UML的目的而编写UML成为不必要的官僚机构，并使项目和代码对适应性的适应性降低，毫无益处。

例如，一个UML类图显示了包中的所有类，以及它们的所有属性和方法（可以轻松自动生成的东西）根本没有任何价值：与您的代码处于相同的抽象级别。另外，代码肯定会是该信息的更好来源，因为它始终是最新的，并且有可能以更容易知道哪些方法/属性/事物更重要的方式进行记录和组织。

另一方面，如果您的抽象概念比代码中所表达的概念更高，那么在图表上进行记录是一个好主意。

例如，显示复杂系统上较高级别抽象模块的图，以及它们的依赖关系以及对它们的职责的一点描述，以及它们在源代码中映射到的包/名称空间，对于新的团队成员来说确实有用。需要引入到项目中，或者也可以用来确定应该在哪里抛出新的类/功能。

有用图的另一个示例可以是序列图，该序列图显示了在通信协议中要执行的高级步骤。也许这些步骤中的每一步都有一些古怪和复杂性，但是在代码本身中描述它们可能就足够了。更高级别的图表可以帮助程序员轻松地理解事物的“全局”，而无需担心每个交互的复杂性。

无论如何，这些仅仅是一些例子。在很多情况下，简单的图表可能会有所帮助。请记住，仅当您无法在代码本身中表达某些内容时，才应该这样做。如果您发现自己使用UML图来解释源代码本身，请改为使源代码更具自记录性。

最后，一些适用于代码的通用规则也可以适用于图表：避免重复自己，保持简单，不要害怕更改（只是因为UML图表中记录了某些内容并不意味着它不能进行更改），并在编写它们时始终考虑谁会在将来阅读/维护这些图（可能是您的未来自我）：）

如果团队成员共同理解并认为UML是汇总和传达设计决策的有用方法，则UML具有价值。您不需要全部了解，仅需要团队认为有用的那一部分即可。

另外，您无需绘制完美，优美的图表。根据上下文，在白板上粗略绘制的顺序图或类图（其中的类是粘贴在该白板上的便签纸）可能就足够了。

我曾经从事过演出，需要管理一个海外合同开发团队。

他们生产的一些东西太可怕了（远程合约编码员的常见症状-他们并不太在乎您的代码，他们只是想快速完成工作）。

为了管理该项目，我发现自己制作了UML图并将其交给他们进行编码。这是非常成功的-用UML编写程序花了我很长时间，比用Java编写程序要快得多，而且承包商可以遵循并加以反对。

一个警告：他们有时确实想变得有创意并且偏离我的模型，但是在那种情况下，它们实际上是正确的，并且总的来说，UML提高了最终产品的质量

如果有人要求您准备UML图并且有人在支付您的薪水，那实际上并没有浪费您的时间。这可能或可能不会浪费那个人的时间。

如果有人打算通过阅读UML图来理解您的项目，那么这可能不是在浪费他们的时间。

我发现在初始设计阶段将想法写在纸上或白板上很有用。我主要使用UML类图，而没有严格遵守标准。在您进行项目的过程中以及项目结束时，重新访问UML原始设计很有用。它帮助我从更高的层次上看了一个代码库，您只需阅读代码就可以做到，甚至还有助于发现潜在的错误。

ragu.pattabi在这里区分了两种UML 是有好处的...

我认为，UML 的敏捷风格（例如快速的白板草图）比UML 的瀑布风格（例如带有文档，代码生成等所有细节的详细图表，使精明的文档管理人员感到满意）更为成功。

当UML被视为“必备”技能（10年前或更早）时，由于当时许多支持者的观点，我可能对此表示反对。但是，既然它不再受到青睐，我发现自己是出于它的本质-一个有用的工具，虽然有其优点，但不是软件开发的灵丹妙药。

当我与朋友谈论我们将要做的事情时，我使用UML（或与UML类似的东西）。讨论想法。不准备要为我自动生成代码的UML项目。我无法想象在UML中创建类然后生成代码，以后再不对其进行调整。这永远不会发生。因此，您将不得不从代码到UML进行更改。当我使用UML时，我会在白板或纸上绘图。从来没有像Enterprise Architect这样的工具。

用UML记录我的整个代码的唯一原因是客户要求的合同。例如，当他希望在部分软件完成后可以选择更改软件商店时。

项目工作文档是专业项目的基本交付内容。多少钱够了？好吧，这当然取决于许多因素。但是，我认为用例，类图，过程流程图等根本不是浪费时间。它们在各个项目阶段都具有价值。文档的唯一问题通常是资源。

一些程序员认为文档是浪费时间。但是这是错误的。如果您以简洁明了的方式将文档视为设计和系统规则的显示，则可能会更欣赏它。同样，需要将自己置于需要维护系统的人们的位置。被抛出500个代码文件并被要求解决它们的问题有点不好，但并不罕见。

我建议您在项目中分配时间，并周期生成图表。第一个将涵盖您项目的高层次方面，而随后的层次将在细节上进行更多说明。

特别是用例很难从代码中推断出来（与系统的许多其他方面不同）。确保执行这些操作。

UML是一个工具，仅此而已，它是否有用还是至关重要，完全取决于您的开发和设计工作流程。前往罗马的方式有很多，其中一些涉及UML，而其他则没有。

如果您的工作流程依靠UML来记录或计划您的体系结构，那么将其删除将是很愚蠢的。如果UML是（与更广泛的意义上）与其他团队成员交流项目结构的最佳方式，那么请务必使用它。但是，如果在没有UML的情况下该项目可以很好地工作，那么仅仅为了它而制作UML图表是没有意义的。

我对此有一些想法。语言可以被使用和滥用，强迫和分散注意力，触发和停滞。UML只是另一种适用于特定问题的语言，就像其他任何语言一样，要学会流利地讲和正确理解它也需要花费时间和精力。

关于交流内容的决定比交流语言要重要得多。UML不会神奇地使您的不良设计易于理解。就像任何其他语言一样，很容易迷失细节或过多地留给想象力。

UML之所以臭名昭著，是因为它拥有众多糟糕的IDE，它允许进行双向原型设计，单击密集型图形操作以及更改任何内容的难度。UML 2.0可能足够复杂，无法满足某些学者的需求，但是其元模型似乎并不吸引许多实际应用。

不过，我仍会不时使用UML。评估高级设计（好的设计在边缘具有复杂性，而在中心则具有简单性）。与同事交流想法并接收反馈。查找隐藏的关系，进行规范化等。但这始终反映了我脑海中已有的事物。通常，我用笔和纸绘制UML，最好远离任何计算机。如有必要，当设计结晶时，我会在绘图程序中进行视觉呈现。

UML绝对很棒，可以使用类图获得体系结构的图形视图。使用序列图进行交互对我来说是神奇的。因此问题不是UML，而是我的MDD。

我的意思是，如果UML是代码的查看者，那么它对于文档目的确实很有帮助，但对于代码生成肯定没有帮助。项目应该以代码为中心，当然也不应该以模型驱动为中心。UML应该在实现阶段使用实时代码和模型同步来使用。我的意思不仅是在需求级别，这需要太多的投资才能获得较小的生产率和质量回报。

我发现他们被高估了。我认为它们是唯一不能画出一千个字的图片。

仅当设计系统的人员无法自己编写代码时，UML才有价值。也就是说，UML是一种将建筑概念传达给其他人的“语言”，现在，如果您是设计代码并实现代码的人，那么为什么需要展示自己的意图，为什么呢？ ？！继续前进，直接进行编码。您仍然需要记录以后的操作，但是整体效率更快。

但是，如果您是一名系统架构师，想告诉您的外包开发人员团队想要什么，那么您就必须以某种方式告诉他们，这就是UML的用武之地。但是，我认为，有很多其他的执行方法如今，坦白地说，UML图表的复杂性意味着每个人都必须了解如何阅读它，如果不阅读，这在某种程度上是自败的。

我从来都不是UML的忠实拥护者，但是我开始重视一个好的序列图来描述系统或任务之间的交互。

但是，类图在诞生之前就已经过时了。粗略的设计不需要UML，最好从代码库中自动提取（实时）完整的文档。Javadoc和Doxygen已完全淘汰了对手动类图的需求。

关于文档的问题是有两个级别：

• 高级别（建筑）决策应手动记录
• 低级（实体关系）事实应自动提取

我通常在代码和UML图之间进行迭代。我发现这些图有助于显示全局图和前进的坚实路径，并且在发现问题时可以快速更改它们。另外，当我有图表时，编码往往变得微不足道。

相反，当我在图片中绘制代码时，它会暴露出依赖性问题，并使设计改进的机会显而易见，如果我们只有代码可以工作的话，这可能不会被注意到。特别是，如果绘制很麻烦，那么编写代码和维护噩梦也会很麻烦。

我发现需要迭代，因为仅绘制图片总是会遗漏重要方面，而仅编码会导致有问题的设计。

但是，就像另一个海报所说的那样，一切都归结于人民。如果他们熟练使用“ UML图”，那么UML是无价的。如果不是，那么这些图就没有价值。

因此，您问题的答案实际上是“取决于”。在这种情况下，它取决于人员，项目的复杂性以及系统正常运行的重要性。

根据我的经验，UML对于开发人员之间关于代码模式的交流以及整个应用程序的体系结构都很重要。

我喜欢图表，但是如果要求我制作图表（尤其是UML！），我会问两个问题：

1. 是给谁用的？
2. 他们现在需要吗？

图表马上就过时了。因此，除非您现在正使用它与某人通信，否则它只会烂掉。并且，如果与您交流的人在文本说明，电话，白板上的非正式摘要方面会做得更好，则建议您这样做。

到目前为止，我对UML图的主要了解之一是，它们大多只倾向于在某人的墙上充当“漂亮的图片”，或者在某处的绑定中充当折叠页，而很少用作基线生产代码。

在这种情况下-从长远来看，UML图（或使用的建模语言风格）很少有用，因为随着时间的流逝和项目的发展，它们往往会失去相关性。这些最初的图纸在几年的时间里大部分是无用的和不正确的，并且随处携带它们是最有害的。

也就是说，如果模型为实际运行的代码提供了实时的和相关的输入，那么使用建模工具（不一定是UML）并不是完全无用的做法。如果模型描述是代码的有用工件，则应将其视为代码：

通过将其用作元数据的直接来源，以便基于建模的概念做出动态决策，或者使用代码生成来生成可在实际工作代码中使用的静态代码工件。

不知道问题是关于UML的优点，还是关于设计程序体系结构的优点。

关于UML。您通常只需要：用例，类图和序列图。简单易用，尽管您当然可以使用自己的图表类型来完成。在这方面，UML是每个人都会理解的标准。

关于设计程序。

1. 每个程序都有一个设计，即使您没有计划。编写代码后，只需对其进行反向工程。如果您没有计划，那肯定是个糟糕的设计。

2. 通过使用已知的重复出现问题的模式，设计将节省您的时间。

3. 如果您在团队中工作，则设计对于讨论解决方案，传达思想是必要的，而对于分发工作则是非常实际但必要的。