uml - UML 实用吗？

Question

在大学里，我上过许多面向设计和UML的课程，并且我认识到 UML 可以使软件项目受益，尤其是用例映射，但它真的实用吗？我已经完成了一些合作工作术语，并且似乎 UML 在行业中没有大量使用。在项目期间创建 UML 图是否值得？另外，我发现类图通常没有用，因为查看类的头文件会更快。具体来说，哪些图表最有用？

编辑：我的经验仅限于 10 个以下的小型开发项目。

编辑：许多好的答案，虽然不是最冗长的，但我相信选择的答案是最平衡的。

score 91 · Accepted Answer

使用 UML 就像在走路时看着自己的脚。它使您通常可以无意识地做有意识和明确的事情。初学者需要仔细考虑他们在做什么，但专业的程序员已经知道他们在做什么。大多数时候，编写代码本身比编写代码更快、更有效，因为他们的编程直觉已针对任务进行了调整。

这不仅仅是关于你在做什么。那些在六个月后加入并需要跟上代码速度的新员工呢？五年后，当目前从事该项目的所有人都离开时会怎样？

为以后加入项目的任何人提供一些基本的最新文档非常有帮助。我不提倡带有方法名称和参数的完整 UML 图（太难维护了），但我确实认为系统中组件的基本图及其关系和基本行为是无价的。除非系统的设计发生巨大变化，否则即使对实施进行了调整，这些信息也不应该发生太大变化。

我发现文档的关键是适度。没有人会阅读 50 页带有设计文档的完整 UML 图而不睡几页。另一方面，大多数人都希望获得 5-10 页简单的类图，其中包含一些关于如何设计文档的基本描述系统放在一起。

我发现 UML 有用的另一种情况是高级开发人员负责设计组件，然后将设计交给初级开发人员来实现。

score 50 · Accepted Answer

在一个足够复杂的系统中，有些地方UML被认为是有用的。

系统的有用图表因适用性而异。
但最广泛使用的是：

类图
状态图
活动图
序列图

有许多企业对它们发誓，也有许多企业完全拒绝它们，认为它们完全是浪费时间和精力。

最好不要过分思考什么最适合您正在进行的项目，然后选择适用且有意义的东西。

score 36 · Accepted Answer

使用 UML 就像在走路时看着自己的脚。它使您通常可以无意识地做有意识和明确的事情。初学者需要仔细考虑他们在做什么，但专业的程序员已经知道他们在做什么。大多数时候，编写代码本身比编写代码更快、更有效，因为他们的编程直觉已针对任务进行了调整。

唯一的例外是为什么你发现自己在晚上没有手电筒在树林里并且开始下雨 - 然后你需要看看你的脚以避免跌倒。有时你所承担的任务比你的直觉更复杂，你需要放慢速度并明确说明程序的结构。然后，UML 是您可以使用的众多工具之一。其他包括伪代码、高级架构图和奇怪的隐喻。

score 19 · Accepted Answer

通用工作流程和 DFD 对于复杂的流程非常有用。根据我的经验，所有其他图表（特别是 UML）无一例外都是在浪费时间和精力。

score 16 · Accepted Answer

我不得不不同意，UML 到处都在使用——在设计 IT 项目的任何地方，UML 通常都会在那里。

现在能不能用好就是另外一回事了。

正如 Stu 所说，从开发人员的角度来看，我发现用例（连同用例描述）和活动图都是最有帮助的。

类图在尝试显示关系以及对象属性（例如持久性）时非常有用。当涉及到添加单个属性或属性时，它们通常是矫枉过正的，尤其是在编写代码后它们通常很快就会过时。

UML 的最大问题之一是在生成代码后保持其最新所需的工作量，因为很少有工具可以从代码中重新设计 UML，而且仍然很少有工具能很好地做到这一点。

score 13 · Accepted Answer

我将通过提及我没有大型（类似 IBM）企业开发环境的经验来限定我的回答。

我看待 UML 和Rational Unified Process的方式是，它更多地谈论你将要做的事情，而不是实际做你将要做的事情。

（换句话说，这在很大程度上是浪费时间）

score 13 · Accepted Answer

只在我看来扔掉。UML 是一个很好的交流想法的工具，唯一的问题是当你存储和维护它时，因为你实际上是在创建相同信息的两个副本，而这通常是它的失败之处。在第一轮实现之后，大部分 UML 应该从源代码生成，否则它将很快过时或需要大量时间（有手动错误）才能保持最新。

score 10 · Accepted Answer

在学校的最后两个学期，我共同教授了一门高级开发项目课程。该项目旨在用于本地非营利组织作为付费客户的生产环境。我们必须确定代码完成了我们的预期，并且学生们正在捕获满足客户需求所需的所有数据。

上课时间是有限的，我在课外的时间也是如此。因此，我们必须在每次班级会议上进行代码审查，但有 25 名学生注册，个人审查时间非常短。我们在这些审查会议中发现最有价值的工具是 ERD、类图和序列图。ERD 和类图仅在 Visual Studio 中完成，因此创建它们所需的时间对学生来说是微不足道的。

这些图表非常迅速地传达了大量信息。通过快速了解学生的设计，我们可以快速隔离他们代码中的问题区域，并在现场进行更详细的审查。

如果不使用图表，我们将不得不花时间通过学生的代码文件一一寻找问题。

score 8 · Accepted Answer

我来这个话题有点晚了，只是尝试澄清几个小问题。询问 UML 是否过于广泛有用。大多数人似乎从典型/流行的 UML 作为绘图/通信工具的角度来回答这个问题。注意：Martin Fowler 和其他 UML 书籍作者认为 UML 最好仅用于交流。但是，UML 还有许多其他用途。最重要的是，UML 是一种建模语言，它具有映射到逻辑概念的符号和图表。以下是 UML 的一些用途：

沟通
标准化设计/解决方案文档
DSL（领域特定语言）定义
模型定义（UML 配置文件）
模式/资产使用
代码生成
模型到模型的转换

鉴于 Pascal 发布的上述用途列表是不够的，因为它只涉及图表创建。如果上述任何一项是关键的成功因素或者是需要标准化解决方案的问题领域，那么一个项目可以从 UML 中受益。

讨论应该从如何过度扼杀或将 UML 应用于小型项目来讨论 UML 何时有意义或将实际改进产品/解决方案，即何时应该使用 UML。在某些情况下，一位开发人员也可以感知 UML，例如模式应用程序或代码生成。

score 5 · Accepted Answer

UML 为我工作了多年。当我开始时，我阅读了 Fowler 的UML Distilled，他说“做足够的建模/架构/等等”。只需使用您需要的东西！

score 4 · Accepted Answer

从 QA 工程师的角度来看，UML 图指出了逻辑和思维中的潜在缺陷。让我的工作更轻松:)

score 4 · Accepted Answer

尽管这个讨论长期以来一直处于非活跃状态，但我有几个 - 在我看来很重要的 - 点要补充。

错误代码是一回事。任其顺流而下，设计错误确实会变得非常臃肿和丑陋。然而，UML 是自我验证的。我的意思是，允许您在多个、数学上封闭和相互检查的维度上探索您的模型，从而产生稳健的设计。

UML 还有另一个重要方面：它直接与我们最强大的能力“对话”，即可视化。例如，如果 ITIL V3（本质上很简单）以 UML 图的形式进行交流，它本可以在几十个 A3 折页上发布。取而代之的是，它以几部真正符合圣经的方式出版，催生了整个行业，惊人的成本和广泛的紧张症冲击。

score 3 · Accepted Answer

我认为 UML 很有用，我认为 2.0 规范使曾经清晰的规范变得有些臃肿和繁琐。我确实同意时序图等的版本，因为它们填补了空白……

学习有效地使用 UML 需要一些练习。最重要的一点是清晰地沟通，在需要时建模并作为一个团队建模。白板是我发现的最好的工具。我还没有看到任何“数字白板软件”能够捕捉到实际白板的效用。

话虽如此，我确实喜欢以下 UML 工具：

紫罗兰色——如果再简单一点，那就是一张纸
Altova UModel - Java 和 C# 建模的好工具
MagicDraw - 我最喜欢的商业建模工具
Poseidon - 物有所值的体面工具
StarUML - 最佳开源建模工具

score 3 · Accepted Answer

UML 图对于捕获和交流需求以及确保系统满足这些需求很有用。它们可以在规划、设计、开发和测试的各个阶段反复使用。

来自主题：在开发过程中使用模型http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

模型可以帮助您可视化系统工作的世界、阐明用户需求、定义系统架构、分析代码并确保您的代码满足要求。

您可能还想阅读我对以下帖子的回复：

如何学习“好的软件设计/架构”？在https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

score 2 · Accepted Answer

我看到经常使用的序列图和活动图。我在与其他系统交互的“实时”和嵌入式系统上做了很多工作，序列图在可视化所有交互方面非常有帮助。

我喜欢做用例图，但我没有遇到太多认为它们有价值的人。

我经常想知道 Rational Rose 是否是您从基于 UML 模型的设计中获得的各种应用程序的一个很好的例子。它臃肿、笨拙、缓慢、丑陋……

score 2 · Accepted Answer

我发现 UML 对于非常小的项目并不是很有用，但确实适用于较大的项目。

本质上，你使用什么并不重要，你只需要记住两件事：

你想要某种架构规划
您希望确保团队中的每个人实际上都在使用相同的技术进行项目规划

所以 UML 就是这样：一个关于你如何计划你的项目的标准。如果您雇用新人，则更有可能了解任何现有的标准——无论是 UML、Flowchard、Nassi-Schneiderman 等等——而不是你现有的内部标准。

对单个开发人员和/或简单的软件项目使用 UML 对我来说似乎有点过头了，但是当在一个更大的团队中工作时，我肯定需要一些标准来规划软件。

score 2 · Accepted Answer

UML 很有用，确实如此！我使用它的主要用途是：

就一个软件的工作方式进行头脑风暴。交流您的想法很容易。
记录系统的架构、模式及其类的主要关系。当有人进入您的团队时，当您离开并希望确保您的继任者能够理解它时，以及当您最终忘记这个小班到底是为了什么时，它会有所帮助。
记录您在所有系统上使用的任何架构模式，原因与上面的点相同

我只是不同意Michael，当他说对单个开发人员和/或一个简单的软件项目使用 UML 对他来说似乎有点矫枉过正。我已经在我的小型个人项目中使用了它，当我七个月后回到他们那里时，使用 UML 记录它们为我节省了很多时间，并且完全忘记了我是如何构建和组合所有这些类的。

score 2 · Accepted Answer

我相信可能有一种方法可以利用 Fowler 在其“UML Distilled”一书中所描述的 Cockburn 风格的 UML 鱼、风筝和海平面用例。我的想法是使用 Cockburn 用例来帮助提高代码的可读性。

所以我做了一个实验，这里有一篇关于它的帖子，标签为“UML”或“FOWLER”。对于 c# 来说，这是一个简单的想法。找到一种方法将 Cockburn 用例嵌入到编程结构的命名空间中（例如类和内部类命名空间，或者通过使用命名空间进行枚举）。我相信这可能是一种可行且简单的技术，但仍有疑问，需要其他人来检查。对于需要一种伪域特定语言的简单程序可能会很好，这种语言可以直接存在于 c# 代码中间，而无需任何语言扩展。

如果您有兴趣，请查看帖子。去这里。

score 2 · Accepted Answer

我对 UML 的问题之一是规范的可理解性。当我试图真正理解特定图表的语义时，我很快就会迷失在元模型和元元模型的迷宫中。UML 的卖点之一是它不像自然语言那样模棱两可。但是，如果两个或更多工程师对图表的解释不同，那么它就无法实现目标。

此外，我尝试在几个 UML 论坛上向 OMG 本身的成员询问有关上层结构文档的具体问题，但几乎没有结果。我认为 UML 社区还不够成熟，无法支持自己。

score 2 · Accepted Answer

来自一个学生，我发现 UML 几乎没有用处。具有讽刺意味的是，PROGAMERS 还没有开发出能够自动生成您所说的必要内容的程序。在 Visual Studio 中设计一个可以提取数据片段、寻找定义和产品答案的功能将非常简单，这样任何人都可以查看它，无论大小，并理解程序。这也将使其保持最新，因为它将直接从代码中获取信息来生成信息。

score 2 · Accepted Answer

只要您用它的字段和方法表示一个类，就会使用 UML，尽管它只是一种 UML 图。

UML 的问题是创始人的书太模糊了。

UML 只是一种语言，而不是真正的方法。

至于我，我真的觉得开源项目缺少 UML 模式很烦人。以 Wordpress 之类的东西为例，你只有一个数据库模式，没有别的。您必须在 codex api 周围徘徊以尝试了解全局。

score 1 · Accepted Answer

UML 有它的位置。随着项目规模的扩大，它变得越来越重要。如果您有一个长期运行的项目，那么最好用 UML 记录所有内容。

score 1 · Accepted Answer

UML 似乎适用于拥有大量人员的大型项目。但是，我曾在沟通更好的小团队中工作。

不过，使用 UML 式的图表很好，尤其是在规划阶段。我倾向于在代码中思考，所以我发现编写大型规范很难。我更喜欢写下输入和输出，让开发人员在中间设计位。

score 1 · Accepted Answer

我相信 UML 之所以有用，只是因为它能让人们思考他们的类之间的关系。开始考虑这种关系是一个很好的起点，但这绝对不是每个人的解决方案。

我的信念是，UML 的使用取决于开发团队的工作情况。

score 0 · Accepted Answer

在我的经验中：

对于任何正在开发新代码或试图理解现有代码的软件工程师来说，创建和传达有意义的代码图的能力是一项必要的技能。

了解 UML 的细节 - 何时使用虚线或圆形端点 - 并不十分必要，但仍然很好。

score 0 · Accepted Answer

UML 在两个方面很有用：

技术方面：很多人（经理和一些功能分析师）认为 UML 是一个奢侈的特性，因为代码就是文档：你开始编码，在你调试和修复之后。UML图与代码、分析的同步，让你更好地理解客户的需求；
管理方面：UML 图反映了客户不准确的需求：如果您在没有 UML 的情况下编写代码，经过大量工作后，您可能会在需求中发现错误。图表 UML 允许您在编码之前找到可能的争议点并解决=>帮助您的计划。

一般来说，所有没有UML图的项目都是肤浅的分析或规模较小。

如果您在linkedin 组系统工程师，请参阅我的旧讨论。

score -1 · Accepted Answer

UML 绝对有帮助，就像 junit 是必不可少的一样。这完全取决于你如何推销这个想法。你的程序可以在没有 UML 的情况下工作，就像在没有单元测试的情况下一样。话虽如此，您应该创建与您的代码相关联的 UML，即当您更新 UML 图时它会更新您的代码，或者当您更新代码时它会自动生成 UML。不要仅仅为了做它而做。

score -2 · Accepted Answer

UML 无疑在行业中占有一席之地。想象一下，您正在为波音飞机或其他一些复杂系统构建软件。UML 和 RUP 在这里会有很大的帮助。

score -2 · Accepted Answer

归根结底，UML 只是因为 RUP 而存在。我们需要 UML 或任何相关的东西来使用 Java/.Net 吗？实际的答案是他们有自己的文档（javadoc 等），这就足够了，可以让我们完成工作！

UML 没有thanx。

score -3 · Accepted Answer

-3

UML 只是人与人之间交流的一种方法。白板更好。

于 2008-08-20T21:02:43.767 回答

score -4 · Accepted Answer

不，不是。代码是最好的交流方式。其他一切都是为那些进入错误行业并决定改变它以适应他们的大脑的人准备的。

接口远远优于类图。用例图将用户需求混合成一种形式，破坏它们并告诉您如何设计产品。数据流图和 ER 图使创建数据库的过程复杂化。有时您可能想要绘制图表来传达您的观点，但没有理由它们必须是 UML 图或符合任何其他人可以理解的标准。

最后，这些都是为大型、无用、官僚“软件”公司提供的所有形式的文档，这些公司使用 XML 制作糟糕的产品。也就是说，如果他们完成了记录。真的，大部分员工都不在乎自己的工作，只是等着上级死了，才能升职。

uml - UML 实用吗？

31 回答 31

Related

Reference